Most of the CRA is a programme. This part is a file. Of all the obligations, publishing a vulnerability-reporting contact is the one you can genuinely finish today — and it's worth doing precisely because it's so cheap relative to the credit it earns you with researchers and auditors alike.
Why it matters for the CRA
The CRA's coordinated-vulnerability-disclosure requirements include providing a contact address where vulnerabilities can be reported. The regulation doesn't mandate security.txt by name, but security.txt — defined by RFC 9116 — is the standard, machine-readable, universally-expected way to publish that contact. A researcher's first move, often automated, is to fetch it. Not having one reads as "no route in."
The fields
| Field | Required? | Purpose |
|---|---|---|
| Contact | required | How to reach you — a mailto:, a form URL, or both. Listed in order of preference. |
| Expires | required | When this file should no longer be trusted. Keep it near-future and refresh it. |
| Policy | recommended | Link to your published disclosure policy. |
| Encryption | recommended | Link to a public key for encrypted reports. |
| Preferred-Languages | optional | Languages you can handle reports in. |
| Canonical | optional | The canonical URL of this file. |
| Acknowledgments | optional | A page thanking reporters. |
A working example
# Report a security issue in our products Contact: mailto:security@example.com Contact: https://example.com/security/report Policy: https://example.com/security/disclosure-policy Encryption: https://example.com/pgp-key.txt Acknowledgments: https://example.com/security/thanks Preferred-Languages: en, cs Canonical: https://example.com/.well-known/security.txt Expires: 2027-01-01T00:00:00.000Z
That's a complete, RFC 9116-valid file. For a production file you'd ideally sign it with the PGP key referenced in Encryption, but an unsigned file still satisfies the standard.
Where to host it
Serve it at /.well-known/security.txt over HTTPS, as text/plain. That well-known location is the canonical one; a copy at the legacy /security.txt is permitted but the well-known path is what tooling checks. On a static site — like this one, if you're running the Next.js build — it's just a file in public/.well-known/.
Mistakes that quietly void it
- A lapsed
Expires. An expired file is, by the spec, no longer to be trusted — and it signals a neglected process. Set a reminder to refresh it. - A contact nobody monitors. The file is a promise that reports will be seen. An unwatched inbox behind it is worse than no file.
- A
Policylink to nothing. Point it at a real, published disclosure policy — the substance security.txt advertises. - Treating the file as the whole obligation. security.txt is the front door. The CVD obligation is the process behind it — intake, triage, and a route into your vulnerability handling.
Frequently asked
Is security.txt required by the CRA?
The CRA requires a contact address for reporting vulnerabilities; it does not name security.txt specifically. But security.txt (RFC 9116) is the standard, widely-expected way to publish that contact in machine-readable form, which makes it the obvious way to meet the requirement.
Where does security.txt go?
At /.well-known/security.txt on your domain, served over HTTPS as plain text. A legacy copy at /security.txt is allowed, but the /.well-known/ location is the canonical one researchers and tooling check.
What fields does security.txt need?
Contact and Expires are the only required fields. Recommended additions include Policy (a link to your disclosure policy), Encryption, Acknowledgments, Preferred-Languages and Canonical. Keep Expires in the near future and refresh it before it lapses.