How to write a security.txt file that researchers can use

A security.txt file is a plain text file that tells researchers how to report a vulnerability to you. RFC 9116 makes two fields mandatory, Contact and Expires, and puts the file at /.well-known/security.txt on your domain. You can publish a working one in ten minutes.

The two required fields

RFC 9116 says the Contact field MUST always be present and may list several methods in order of preference. The Expires field MUST also be present and MUST NOT appear more than once. Its value is a date and time in the RFC 3339 format. The RFC recommends setting it less than a year ahead so the data does not go stale. Stale files should not be used.

The optional fields

Everything else is optional: Acknowledgments, Canonical, Encryption, Hiring, Policy and Preferred-Languages. Researchers are told to ignore fields they do not recognize.

A small example

Contact: mailto:security@example.com
Contact: https://example.com/report
Expires: 2027-06-30T23:59:00.000Z
Policy: https://example.com/vulnerability-disclosure-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

Where and how to serve it

• Place it at /.well-known/security.txt. A top level /security.txt or a redirect is allowed for legacy reasons, and the well-known path wins if both exist.
• Serve it over HTTPS as text/plain with charset utf-8.
• Use UTF-8 and either LF or CRLF line endings.

Signing

Signing with an OpenPGP cleartext signature is recommended but not required. If you sign, also add the Canonical field so the signature can confirm where the file belongs.

Keep it alive

The usual failure is an expired file. Put the Expires date on a calendar, or add a check to your pipeline that fails when the date is under 60 days away. Make sure the mailbox in Contact is monitored and that it can receive messages from outside. Test it by emailing it.

Link to a written policy. See what a vulnerability disclosure policy should include.

Mistakes seen most often

• The Contact address points to a mailbox that bounces outside mail or has no owner.
• The file is served as an HTML page by a catch-all route, so the content type is wrong.
• The Expires date is long past, because nobody owns renewal.
• The file exists only on the marketing site and not on the domains that run the product.
• The Policy link goes to a page that returns an error.

Check each of these once a quarter. For companies with many domains, decide which hostnames need their own file, or point researchers to a single Canonical location and keep the others aligned.

What to do when a report arrives

Reply within a few days, say thank you, and tell the person who will look at it. Keep the thread going until the issue is resolved. A short, human answer builds more goodwill than a long legal notice.

Quick check

Sources

• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure

Last reviewed: 19 October 2026.