security.txt: provide a reliable reporting channel

What the file defines

RFC 9116 describes a machine-readable format for contacts and information about vulnerability reporting. The RFC was published in April 2022 as Informational; it is not an Internet Standard in the formal IETF sense. Its format requirements nevertheless provide the authoritative basis for a file conforming to RFC 9116. RFC 9116, status and § 1

For web services, the location is https://example.com/.well-known/security.txt. A file or redirect at /security.txt provides legacy compatibility. It does not replace availability at the required /.well-known/ path. If files exist in both places, the one at the well-known path takes precedence.

A file initially applies to the host or IP address of the URI used to retrieve it, not automatically to every parent domain and subdomain. Consider www.example.com, example.com and shop.example.com separately. The published process may additionally cover an organisation's products and services; the policy describes that scope. This wider responsibility cannot be inferred from a contact file alone. RFC 9116, § 3

Complete the required fields correctly

A bare email address such as security@example.com is not sufficient as a Contact value: it needs the mailto: scheme. Use tel: for telephone contacts and an HTTPS URI for web contacts. Do not simply join several contacts with commas on one Contact line. A form should actually be accessible to external reporters and provide a secure way to submit the necessary information.

Expires identifies the time after which the file is considered stale. A date without a time, or a time without an offset, does not meet the required format. Z means UTC; a suitable numeric offset is also possible, for example. The RFC recommends less than one year into the future, rather than requiring a universal one-year validity period. Choose a date that your maintenance arrangements can support. RFC 9116, §§ 2.5.3 and 2.5.5, RFC 3339, § 5.6

A checking tool that can somehow parse a string as a date has not necessarily validated RFC 3339. Equally, a future date does not prove that the inbox is monitored. Expiry warnings and regular checks of the actual reporting channel complement each other.

Add optional fields as needed

Web URIs in these fields must use HTTPS. An Encryption URI does not prove that the key is correctly attributed or current. The encryption key referenced there need not be the key used to sign the file. If Preferred-Languages is absent, RFC 9116 allows reporters to assume English.

The field list is extensible. The current IANA registry additionally includes, for example, CSAF for a corresponding security advisory directory and Bug-Bounty with a true/false value. This implies neither an obligation to offer a bounty programme nor any particular payment. Readers must ignore unknown fields; additional fields do not make a file valid when required fields are missing. IANA registry

A manageable example file

The domains, addresses and date are placeholders for this example. Use only accessible destinations managed by your organisation; check the expiry time before every publication:

# Security reports for example.com
Contact: mailto:security@example.com
Contact: https://example.com/security/contact
Expires: 2027-01-31T23:59:59Z
Preferred-Languages: de, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy
Encryption: https://example.com/security/pgp-key.asc

The file is UTF-8 plain text, not HTML. Each field occupies its own line, with a space after the field's colon in this example. The final line also ends with a line break. LF or CRLF are specified for ordinary text lines. Comments start with #. Field names are defined without regard to letter case; consistent spelling makes maintenance easier.

Keep the file small. The RFC allows readers to impose size and line-length limits to protect their parsers; it does not require a lengthy description of the whole security organisation in this file. Longer rules belong on the linked policy page.

Check availability through the actual delivery path

The public response needs HTTPS with a valid certificate and Content-Type: text/plain; charset=utf-8. A 200 response containing your ordinary HTML error page is not a security.txt file. A login, bot challenge form or SPA fallback pointing to the home page can also prevent discovery.

On a web server, the public path must lead to the correct file or route. Check rules that generally block hidden directories, along with the order of rewrite, access protection and fallback rules. In Nginx, for example, the specific path can be mapped through an exact-match location block; in Apache, a targeted exception must fit the actual directory and rewrite configuration. A general rewrite exception for the whole of /.well-known/ neither automatically grants file access nor sets the MIME type.

The CDN and WAF belong in the same verification path. Correcting the origin document does not help while a cache still serves the old file. Choose a cache lifetime that does not undermine updates, revocation or Expires, and provide for targeted replacement. Monitor availability, expiry and changes to Contact, Canonical or key references.

For your own domain, a GET request can make status, headers, content and redirects visible:

curl --proto '=https' --proto-redir '=https' \
  --location --max-redirs 3 --max-time 15 --dump-header - \
  'https://example.com/.well-known/security.txt'

The command does not bypass certificate checks. It does not, on its own, validate the RFC grammar or establish that the inbox can be reached. Document unexpected changes of destination and the final path. Redirects are possible, but need a separate assessment of trust, particularly when moving to a different domain. RFC 9116, §§ 3 and 5.2

Distinguish signatures, integrity and trust

RFC 9116 recommends an OpenPGP cleartext signature together with a Canonical field. The signature protects the signed text against unnoticed changes when verified using the correct public key with a trustworthy owner association. It does not by itself prove that the key belongs to your organisation.

A visible BEGIN PGP SIGNED MESSAGE or BEGIN PGP SIGNATURE block is not enough. Cryptographic verification must actually confirm the signature. Without the public key, it remains unverified; an invalid signature is a different finding. The documented local test confirmed precisely these distinctions: the original was valid, a changed Contact line was invalid, and an unknown key prevented verification.

Canonical adds a location reference. If a correctly signed file is copied unchanged to another host, its signature may remain mathematically valid. Where a Canonical field is present but does not contain the retrieval URI, RFC 9116 says the contents should not be trusted. Conversely, a list of Canonical URIs does not on its own authorise every external address it names. RFC 9116, §§ 2.3, 2.5.2 and 5.1

Arrange key maintenance, signing after changes, and an independent way to verify the key's association with its owner. Someone who has already altered your website could also replace the file and a key linked from it. Reports of an intrusion already in progress therefore need particular care. The vulnerability reporting contact and the crisis communication channel need not be the same.

Provide a managed process behind the contact

Assign a responsible role and cover for absence. The inbox needs triage, safe handling of attachments and links, and a way to ask follow-up questions confidentially. Incoming reports are untrusted data and may contain spam or harmful content. Publish only response commitments that you can meet during holidays and periods of increased demand.

A useful policy describes the covered scope, reporting channel, requested information, handling of sensitive data and subsequent communication. If you want to grant explicit permission for security testing, set out its conditions separately and clearly. Under RFC 9116, neither the presence nor absence of the file should be interpreted as general permission for testing or its refusal. The RFC also does not prescribe a universal response within 24–48 hours or triage within five working days.

Check the published information at least before expiry and after changes to the organisation, domains or keys. Do not simply extend Expires automatically without reviewing the information. Outdated contacts can direct confidential reports to recipients who are no longer responsible.

Statutory reporting is a separate process

The file is not a universal prerequisite for ‘NIS2 compliance’. Article 12 of NIS2 concerns national coordination of vulnerability disclosure. Reporting obligations for significant security incidents are a separate matter; for entities within scope in Germany, § 32 BSIG is particularly relevant. A report to the published Contact inbox is not such a notification to an authority. NIS2, Articles 12 and 23, § 32 BSIG

For the Cyber Resilience Act, the product, manufacturer role and scope of application are decisive; not every website is automatically a product within scope. The manufacturer reporting obligations under Article 14 have applied since 11 September 2026, including to relevant existing products under Article 69(3). The general vulnerability handling requirements, including a disclosure policy and contact address, apply in principle from 11 December 2027. A security.txt file can make a contact discoverable, but replaces neither these processes nor the required notifications. CRA, Articles 13–14, 69, 71 and Annex I, Part II

An audit likewise depends on the agreed assessment framework and actual evidence. A Contact or Policy field is not certification. The existing compliance guide explores the legal context further.

What the scanner actually examines

In the reviewed implementation, the Web Security Check retrieves the well-known path over HTTPS for the requested host and tries the older root path under certain conditions. This additional request is distinct from the final host of an earlier web page redirect. It has size, time and redirect limits. A transport failure therefore does not establish that the file is absent.

The analyser recognises selected fields, assesses Expires and examines the structure of a cleartext signature block. It does not verify a cryptographic signature, a genuinely monitored inbox or a complete disclosure policy. It checks Contact URIs and the Expires date for the required form; significant errors there prevent a good quality level and bonus points. It does not conclusively assess other URI fields, contact availability or special cases such as leap seconds. A quality value that suggests validity, or additional points, must therefore not be read as proof of a conforming, trustworthy file.