security.txt: Why the BSI Now Recommends a Tiny Text File for Every Website

Only 1.8 percent of German websites tell attackers and security researchers alike whom to contact in an emergency. A single text file, the security.txt, would be enough to change that, and the German Federal Office for Information Security (BSI) now explicitly recommends it.

Why a simple text file is suddenly getting attention

Imagine an independent security researcher accidentally discovers a vulnerability on your website. They want to report it responsibly before it falls into the wrong hands. But where to? The legal notice rarely helps, the general support address is often the wrong contact, and valuable time passes while the gap stays open.

This is exactly the problem the so-called security.txt solves. It is a standardized, machine-readable text file that can be placed on any website at a fixed, predictable location. It answers within seconds the question that matters in an emergency: who is responsible, and how do I reach them securely?

What sounds like a niche recommendation for large corporations has now gained official weight. On 6 August 2026, the BSI, together with the Alliance for Cyber Security (ACS), called for the security.txt to be introduced across the board. The reason: measurements within the BSI project Cyberdome showed that only 1.8 percent of German website operators provide this file so far, even though the effort is minimal.

The purpose: a reliable reporting channel instead of chance

The security.txt is not a BSI invention but an international technical standard, defined in RFC 9116 of the Internet Engineering Task Force (IETF). The core idea is simple: instead of every organization inventing its own, often hard-to-find way to report security vulnerabilities, everyone follows a common format in a common place.

Without this standard, one of three things regularly happens in practice:

• The report reaches nobody because no official contact exists.
• It lands with the wrong department and is delayed unnecessarily.
• Security researchers give up in frustration and disclose the vulnerability publicly before it is fixed, with all the risks that brings for visitors and customers of the website.

A correctly set up security.txt prevents exactly that. It creates a clear, documented channel for so-called Coordinated Vulnerability Disclosure: the coordinated, responsible disclosure of vulnerabilities, in which operators are given time to fix them before details become public.

What goes into the security.txt file

Technically, the security.txt always sits at the fixed path https://your-domain.com/.well-known/security.txt and consists of simple lines of text. Two of them are mandatory according to RFC 9116:

• Contact – states how security experts can reach you, usually by email address, sometimes complemented by a phone number or contact form.
• Expires – an expiry date that signals until when the information is considered current. This indirectly forces operators to maintain the file regularly instead of creating it once and forgetting about it.

Beyond that, there are several recommended and optional fields that can add considerable value: a link to your own vulnerability disclosure policy, a PGP key for encrypted reports, a hall-of-fame page for security researchers, or preferred languages for communication. The file can also be digitally signed to further secure its authenticity.

How to set up the file in a few minutes

The technical implementation is deliberately low-threshold. A minimal, valid security.txt consists of just two lines:

Contact: mailto:security@your-domain.com
Expires: 2027-08-25T00:00:00Z

You save this file as plain text and upload it to your web server under the path /.well-known/security.txt. On most hosting environments, ordinary FTP or file manager access is enough. No content management system or programming knowledge is required.

What matters is that the web server delivers the file correctly: it should be served as text/plain with UTF-8 encoding. In most standard configurations this already happens automatically, as long as the file was simply saved as a .txt file. If you want to be extra careful, add a link to your own vulnerability disclosure policy and set the expiry date realistically. Six to twelve months in the future is common, so that the file is actually reviewed and updated regularly instead of being created once and then forgotten.

Why this matters more right now

The security.txt is no longer just a voluntary nicety. The EU Cyber Resilience Act (CRA) sets binding requirements for handling vulnerability reports and becomes fully mandatory from December 2027. Reporting duties for actively exploited vulnerabilities and severe security incidents already apply from 11 September 2026. Anyone who establishes a working reporting channel now gains a comfortable head start in meeting these regulatory requirements instead of having to catch up later under time pressure.

The BSI also stresses in its statement how small the effort is compared to the benefit. Anyone who sets the two mandatory fields correctly and provides the file at the right path has already met the most important requirements, one of the lowest-threshold IT security measures there is, as the press release puts it.

In practice, however, small but consequential mistakes often happen during implementation: a wrong HTTP content type, an expiry date too far in the future that undermines actual maintenance, or a file that exists but sits at the wrong path and is therefore simply not found by automated checks. Exactly such details can be reliably uncovered with an automated security check, which, besides the mere presence of the file, also checks the structure of the security.txt according to RFC 9116 and provides understandable, concrete guidance for every problem found on how it should look.

Examples of such guidance are given in the next section. The help pages of the web security check mentioned above are even more extensive and contain illustrative examples for webmasters.

Technical notes for implementation

Beyond the pure field syntax, there are a few technical details that are often overlooked in practice but have a significant effect on whether the security.txt works correctly.

The file must be retrievable via the encrypted HTTPS protocol. Retrieval over unencrypted HTTP is not conformant under RFC 9116, because the content could otherwise be manipulated in transit. The specification also recommends keeping the file compact: guideline values are a total size under 32 kilobytes, individual field values under 2,048 characters and fewer than 1,000 lines overall. This makes it easier for automated analysis tools to process the file reliably.

If you run the file on Apache, you can control the content type and a redirect from the outdated root path centrally via the .htaccess file:

AddType text/plain .txt
Redirect 301 /security.txt /.well-known/security.txt

This ensures that both the correct, binding path under /.well-known/ and a possible legacy path in the root directory point to the same target. If both variants exist at the same time with different content, the standard says the version under /.well-known/ always takes precedence.

A common stumbling block: HTTP response headers such as Content-Type belong exclusively in the server configuration, not as a line in the file content itself. A line like "Content-Type: text/plain; charset=utf-8" inside the security.txt is not a valid field under RFC 9116 and is simply ignored by evaluating systems. The scope also deserves attention: a security.txt applies only to exactly the domain or subdomain it was retrieved from. shop.your-domain.com needs its own file if required, independent of the version stored on your-domain.com.

If you want to signal additional trustworthiness, you can digitally sign the entire file with OpenPGP. This is not a separate line but a cryptographic wrapper around the complete content, proving that the file really comes from the domain owner and has not been altered afterwards. In this case, a Canonical field is also recommended, so that the official storage location of the file is secured by the signature as well.

Conclusion: small effort, noticeable difference

The security.txt is one of the rare examples where a few minutes of work can make a real difference to the security of a website. It costs no license fee, requires no new infrastructure and can be done with a simple text editor. At the same time, it signals to the outside world that an organization takes security seriously and welcomes reports instead of making them difficult.

Given the BSI recommendation, the upcoming regulatory requirements of the Cyber Resilience Act and the modest adoption of currently only 1.8 percent, every website operator should take a quick look at their own /.well-known/ directory. If you do not have the file yet, you can create it in a few minutes. If you are unsure whether your implementation is correct, an automated check quickly provides clarity.