What is security.txt?
security.txt is a plain-text file published at /.well-known/security.txt that tells security researchers how to report a vulnerability. RFC 9116 defines the format, and Contact and Expires are the two mandatory fields.
Key takeaways
- The file location is /.well-known/security.txt, served over HTTPS as text/plain with the charset utf-8.
- Contact and Expires are the only mandatory fields, and a file without Expires fails RFC 9116.
- RFC 9116 is an Informational IETF document from April 2022, not a law and not a certification.
- The Cyber Resilience Act names no file format, and Annex I Part II point 6 requires the contact address that security.txt publishes.
- Only 9.9% of the 342 EU manufacturers measured in the CRA Exposure Study published a security.txt at all, and 7% published one that meets RFC 9116.
Which fields does RFC 9116 define?
Nine fields, of which two are mandatory. Each field is a name, a colon and a value on its own line. A line starting with a hash is a comment.
| Field | Status | What it carries |
|---|---|---|
| Contact | Required | Where to send a report. A mailto:, https: or tel: URI. The field may repeat, most preferred first. |
| Expires | Required | The date and time after which the file should no longer be considered current, as an ISO 8601 timestamp. Exactly one Expires field is allowed. |
| Encryption | Optional | A link to a public key a researcher can use to encrypt the report. Never the key itself. |
| Acknowledgments | Optional | A link to a page thanking researchers whose reports have been resolved. |
| Preferred-Languages | Optional | A comma-separated list of RFC 5646 language tags, in no order of preference. One field only. |
| Canonical | Optional | The URI where this file is located. Lets a reader confirm the file was not copied from elsewhere. |
| Policy | Optional | A link to the vulnerability disclosure policy, including any safe-harbour terms. |
| Hiring | Optional | A link to security-related job openings. |
| CSAF | Optional | A link to the provider-metadata.json of a CSAF provider, so advisories can be found automatically. |
What does a security.txt file look like?
A complete file for a manufacturer that also publishes CSAF advisories. Replace the domain, set an Expires date under a year out, and keep the file under version control so the renewal is somebody’s job rather than nobody’s.
Contact: https://example.com/vulnerability-report
Contact: mailto:security@example.com
Expires: 2027-09-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/disclosure-policy
Acknowledgments: https://example.com/hall-of-fame
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
CSAF: https://example.com/.well-known/csaf/provider-metadata.jsonGenerate the same file for your own domain with the free security.txt generator, or check what a domain publishes today with the CRA exposure scanner.
Why do security.txt files fail validation?
Four faults account for most invalid files. In the CRA Exposure Study, 34 of the 342 manufacturers scanned published a file and only 24 of those files met RFC 9116.
| Mistake | Effect |
|---|---|
| No Expires field | The file fails RFC 9116. Expires is one of only two mandatory fields, and a parser that follows the specification rejects the file. |
| An Expires date in the past | The file is stale by its own declaration and a researcher is told to disregard it. Set a reminder rather than a distant date, because the RFC advises a value less than a year out. |
| The file at the domain root only | The location is /.well-known/security.txt. The top-level /security.txt is a legacy fallback for web servers only, and scanners looking in the well-known directory find nothing. |
| Served over plain HTTP, or as HTML | The file must be served over HTTPS with the media type text/plain and the charset utf-8. A 200 response carrying an HTML error page is a common silent failure. |
The full measurement, its method and the dataset under CC BY 4.0 are published in the CRA Exposure Study 2026.
Does the Cyber Resilience Act require security.txt?
The Cyber Resilience Act requires the contact, not the file. Regulation (EU) 2024/2847 Annex I Part II point 6 obliges a manufacturer to facilitate the sharing of information about potential vulnerabilities, including by providing a contact address for reporting them. Annex II then obliges the manufacturer to give users the single point of contact where vulnerability information can be reported and received. Neither names a format.
security.txt is how a machine finds that contact. A researcher, a scanner or an automated triage agent looks in one well-known location instead of reading a website. Publishing the file costs nothing and is the cheapest evidence a manufacturer can put in the technical file against that requirement.
The contact alone is not the whole obligation. Annex I Part II point 5 separately requires a coordinated vulnerability disclosure policy, which is the document the Policy field should point at.
Questions about security.txt
What is security.txt?
security.txt is a plain-text file published at /.well-known/security.txt that tells security researchers how to report a vulnerability. RFC 9116 defines the format. Contact and Expires are the two mandatory fields, and everything else is optional.
Where should the security.txt file be placed?
At https://your-domain/.well-known/security.txt, served over HTTPS with the media type text/plain and the charset utf-8. A copy at the top level is permitted as a legacy fallback for web servers, and the well-known location is the one that counts.
Is security.txt a standard?
security.txt is defined by RFC 9116, an Informational document published by the IETF in April 2022. It is a published specification rather than a legal requirement, and no regulation names it by name.
Does the Cyber Resilience Act require security.txt?
No. Regulation (EU) 2024/2847 names no file format. Annex I Part II point 6 requires a contact address for reporting vulnerabilities, and Annex II requires the single point of contact to be given to users. security.txt is the machine-readable way to satisfy both.
What must a security.txt file contain?
A Contact field and an Expires field. Contact carries a mailto:, https: or tel: URI and may repeat in order of preference. Expires carries one ISO 8601 timestamp after which the file should no longer be considered current.
Should security.txt be signed?
RFC 9116 recommends signing the file with an OpenPGP cleartext signature so a reader can verify it was published by the organisation that owns the domain. Signing is optional and unsigned files remain valid.
Sources
- RFC 9116, A File Format to Aid in Security Vulnerability Disclosure IETF, April 2022. The specification.
- RFC 8615, Well-Known Uniform Resource Identifiers IETF, May 2019. Defines the /.well-known/ directory.
- Regulation (EU) 2024/2847, the Cyber Resilience Act, EUR-Lex CELEX:32024R2847. Annex I Part II point 6 and Annex II.
- CRA Exposure Study 2026 342 EU manufacturers scanned on 2026-07-29. Method and dataset published under CC BY 4.0.
- The security.txt this site publishes A live example on a production domain.
Last updated on 2026-09-04.
Publish a security.txt and the policy behind it
A CVD Portal account hosts the disclosure policy, the intake form and the reporting contact under your own brand, so the Contact and Policy fields point at something that works.