The idea is deliberately unglamorous. Put a plain text file at a predictable location on your web server, list the ways to reach your security team, and let anyone who finds a problem read it. It borrows its shape from robots.txt, the file that tells search crawlers where they may go, and from humans.txt, the file that credits a site's authors. security.txt does the same thing for the person holding a bug report.
It was proposed by Ed Foudil in 2017 and standardized in April 2022 as RFC 9116, published by the Internet Engineering Task Force. It is an informational, community-driven convention rather than a mandate, but it has been adopted by Google, GitHub, and a long list of governments and large organizations.
Where the file lives
The canonical location is /.well-known/security.txt, served over HTTPS. The .well-known directory is a reserved path (defined in RFC 8615) used by many standards to place machine-discoverable metadata at a predictable spot. A legacy location at the site root, /security.txt, is also permitted for older tooling, but the well-known path is the one researchers and scanners check first.
The value of the standard is entirely in the predictability. A researcher does not have to guess or dig through a footer. They append one known path to your domain and get a machine-readable answer. Tools and vulnerability platforms can check it automatically, which is why placement is not negotiable.
What goes inside
The file is a set of fields, one per line, each a name followed by a colon and a value. Two of them are required and the rest are optional.
| Field | Required | Purpose |
|---|---|---|
| Contact | Yes | How to reach you: a mailto, an https reporting form, or a tel. Can appear multiple times, in order of preference. |
| Expires | Yes | A date after which the file should be considered stale. Forces you to review it periodically. |
| Encryption | No | A link to your PGP key or key fingerprint so reports can be sent encrypted. |
| Policy | No | A link to your vulnerability disclosure policy, including scope and safe-harbor terms. |
| Acknowledgments | No | A page thanking researchers who have reported valid issues. |
| Preferred-Languages | No | The languages your team reads, as a comma-separated list. |
| Canonical | No | The URI where this file officially lives, which helps a signature bind to a location. |
A minimal but complete file is short:
Contact: mailto:security@example.com
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, fr
Canonical: https://example.com/.well-known/security.txt A working security.txt
Signing the file
Because the file is served over plain HTTP request-response, an attacker who can tamper with your site could in principle alter it, redirecting reports to themselves. RFC 9116 allows the file to be signed with an OpenPGP cleartext signature, and the Canonical field lets that signature bind to a specific URI. For a high-value target this closes a real gap: a researcher can verify that the contact details they are about to trust actually came from you. It reuses the same PGP signing machinery that already protects email and software releases.
The Expires field is the clever part
Most metadata files rot. Someone sets them up once, the security contact leaves the company, and two years later the address bounces. The Expires field is a small piece of forcing function against exactly that. A file past its expiry date is meant to be treated as invalid, which means keeping it current is not optional maintenance but a hard requirement if you want it to keep working. It is a rare example of a standard that builds its own freshness check into the format.
A vulnerability disclosure channel that quietly stopped working is worse than none at all, because a researcher who reasonably believed they had reported the bug will move on, and the flaw stays open. Expires exists to make silent decay loud. Why the date is mandatory
What security.txt is not
It is worth being precise about scope. security.txt is a directory listing, not a security control. It does not patch anything, does not run a bug bounty, and does not obligate a researcher to follow any particular process. What it does is remove the single most common reason good-faith reports never arrive: the reporter could not figure out where to send them.
It pairs naturally with a written coordinated vulnerability disclosure policy. The Policy field points to that document, which is where you set expectations about scope, response times, and legal safe harbor. The security.txt file is the sign on the door; the policy is what happens once someone walks in.
Setting one up
- Decide on a monitored contact. A dedicated address like security@ that reaches a human who can triage reports is the standard choice.
- Write a short disclosure policy page covering scope and safe harbor, and link it from the Policy field.
- Publish a PGP key if you want encrypted reports, and reference it in the Encryption field.
- Set an Expires date you will actually review, commonly six to twelve months out.
- Place the file at /.well-known/security.txt over HTTPS, and optionally sign it.
Where Haven fits
For a company building encrypted communication, a clear reporting channel is part of the security posture, not a nicety on top of it. The people most likely to find a flaw in an encryption product are the researchers who study encryption for a living, and the worst outcome is one of them giving up because they could not reach us. Publishing a signed security.txt, backed by a real disclosure policy and a PGP key, is a low-cost way to keep that channel open. It is the kind of small, verifiable commitment that says more than a marketing claim about taking security seriously ever could.