A security.txt file is a small text file, defined in RFC 9116, that tells researchers and customers how to report a security problem to your organization. It must contain a contact method and an expiry date. Publishing one is cheap, and reviewers often check for it, but only if you keep it current.
What the standard actually says
RFC 9116 defines a machine-parsable format called security.txt. Its stated purpose is to help organizations describe their vulnerability disclosure practices so researchers can find the right reporting channel. The RFC is informational, not an Internet Standards Track document, so no one is forced to publish one.
Two fields are mandatory. The Contact field says where to send reports, such as an email address or a web page. The Expires field says when the file should be treated as stale, and the RFC recommends a date less than a year ahead. The RFC also warns that not having a file may be preferable to having stale information in it.
Why customers care during a security review
A customer reviewer is asking, in part, what happens when someone finds a flaw in your product. A published contact and a policy link are a quick, visible answer. They show that a report has somewhere to go, which is easier to confirm than a sentence in a questionnaire.
It also helps the other direction. If a customer finds an issue while using your product, they know who to tell without guessing at a support queue.
What to put in the file
| Field | Required | What to put there |
|---|---|---|
| Contact | Yes | A monitored mailbox or a web form, not a person's inbox |
| Expires | Yes | A date under a year out, with a calendar reminder |
| Policy | No | A link to your disclosure policy page |
| Canonical | No | The URL where the file lives, so copies can be verified |
| Preferred-Languages | No | Languages your team can handle |
Steps to publish one
- Decide who monitors the contact address and what the expected first reply time is.
- Write a short disclosure policy page and link it with the Policy field.
- Create the file with Contact and Expires, then serve it over HTTPS from your main domain.
- Add the expiry date to a team calendar with a reminder a month earlier.
- Test it: send a message to the contact address and confirm a person receives it.
- Reference the file from your trust page so reviewers can find it.
The part people skip
The RFC says the information in the file, and any pages or addresses it points to, should be kept current, accessible and controlled by the organization. An expired file or a bounced email is worse than no file, because it tells a reviewer that nobody owns the process.
Give the file an owner by name in your internal evidence register. The same owner should confirm each quarter that the mailbox still works. If your team has no disclosure policy yet, write the policy first and publish the file second.
Do not say in a questionnaire that you "run a bug bounty" or "have a disclosure program" just because the file exists. A file is a contact channel. A program is a contact channel plus triage, response times and a record of handled reports.
Where Safeguard fits
Safeguard's compliance and evidence automation can hold the owner, the review date and the supporting links for items like this in one place, so the answer you give a customer matches what you can show. You can also run a free scan of your own project at https://gold.safeguard.sh/scan.
Quick check
Is security.txt required by law or by RFC 9116?
No. RFC 9116 is informational and describes a format. Publishing the file is voluntary, though it makes disclosure easier for others.
What happens if the Expires date passes?
The RFC says data after that date is considered stale and should not be used. Renew it on a schedule, or reviewers may see a dead channel.
Sources
Last reviewed: 19 October 2026.
