How to write a security.txt (RFC 9116), and why EU software makers now need one

A security.txt file tells security researchers how to reach you when they find a vulnerability. It is a plain text file at /.well-known/security.txt, defined by RFC 9116. Since 11 September 2026 it has an extra reason to exist in Europe: the Cyber Resilience Act expects software makers to publish a way for outsiders to report vulnerabilities, and security.txt is the common way to publish that contact (practitioners recommend it; the regulation does not name it).

The minimum

Contact: mailto:[e-mail]
Expires: 2027-10-09T00:00:00Z

Two fields are required:

• Contact: one or more mailto:, https: or tel: URIs. List the preferred channel first.
• Expires: an ISO 8601 date-time. RFC 9116 recommends less than a year ahead, so the file cannot go stale silently. An expired file is treated as untrustworthy.

Useful optional fields

Encryption: https://example.com/pgp-key.txt
Acknowledgments: https://example.com/hall-of-fame
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy
Hiring: https://example.com/jobs

• Canonical should be the file's own URL; if it does not match where the file is served, checkers warn.
• Policy points to your vulnerability disclosure policy: how reports are acknowledged, triaged and fixed, and when you publish.
• Encryption points to a key, not the key itself.
• Web URIs should be https.

Common mistakes

1. No Expires, or one that already passed.
2. Serving it only at /security.txt (the root location is a legacy fallback; use /.well-known/).
3. A Canonical that points elsewhere.
4. Unknown field names, usually typos (Contacts:).
5. A contact nobody reads. Under the CRA an actively exploited vulnerability starts a 24-hour reporting clock from the moment you become aware, so the inbox matters more than the file.

Tools

We put three free tools in the browser, nothing uploaded: a security.txt generator and checker (paste a file to check it against these rules), a vulnerability disclosure policy generator for the Policy: page, and a CRA 24-hour incident clock. The reporting deadlines are summarised in our CRA checklist for small software vendors. Not legal advice.