A researcher discovers a problem in a website. Before the team can investigate, the report needs to reach the right people. Searching through a general contact page, guessing email addresses and waiting for a support ticket to be forwarded all add friction.

security.txt provides a predictable place to publish that contact route. The project’s purpose is to make vulnerability reporting easier. For an engineering team, its value comes from connecting a public contact to people who can assess and resolve an issue.

Publish the essentials

RFC 9116, published in April 2022 as an Informational RFC, documents the format. For websites, serve UTF-8 plain text over HTTPS at:

https://example.com/.well-known/security.txt

Use Content-Type: text/plain; charset=utf-8. Include at least one Contact and exactly one Expires, expressed as an RFC 3339 timestamp. Scope follows the host where the file is retrieved; subdomains do not automatically inherit it.

A compact starting point

Contact: mailto:[email protected]
Expires: 2027-09-30T23:59:59Z
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

This is an illustrative example prepared in October 2026. Choose a future expiry date when deploying it and replace the domain and contact with values you control. IANA reserves example.com for documentation; the address above is not a destination for real reports.

The official field guide explains the optional entries: Preferred-Languages describes supported communication languages, while Canonical identifies the file’s location. Add Policy once you have a published disclosure policy to link to. Encryption can point to a public key for confidential reports. That serves a different purpose from signing the file to help establish its authenticity.

Assign an owner before announcing the address

A useful operational approach is to give one team responsibility for the reporting channel and name a backup owner internally. Document who checks incoming messages, who can assess a suspected vulnerability and who can contact the relevant developers.

Test the complete route from an external mailbox. Confirm that the message arrives, survives filtering and reaches somebody who knows what to do with it. If a ticketing system sits behind the address, check that sensitive attachments and report details are restricted to the people handling the case.

For a small team, the process can remain simple: acknowledge receipt, record the affected component, investigate the evidence and agree on the next update. Avoid publishing response promises that your staffing cannot support. A short, realistic commitment is easier to maintain than an ambitious deadline forgotten during holidays.

Consider a second monitored contact route if your primary channel has a single point of failure. Before listing it, test that route too. Adding more destinations creates more maintenance work, so each should have an identifiable purpose.

Make expiry part of routine maintenance

The RFC recommends an expiry less than a year in the future. After expiry, the information is stale and should not be used.

A practical schedule is a quarterly review plus two reminders: one 30 days before expiry and another seven days before. Those intervals are an operational suggestion, not an RFC requirement. During review, confirm the contact owner, test delivery, open every linked resource and then choose a new date. Merely extending the timestamp misses the purpose of the review.

Keep the file in the same version-controlled deployment process as other public assets where possible. Include it in handover notes when ownership, hosting or mail providers change.

Check the public result

After deployment, fetch the exact public URL without signing in. Inspect both the response headers and the body. A successful status code is only part of the check: an application fallback could return a normal HTML page where you expected a text file.

Also check the date, the contact spelling and the optional links. Repeat the check after changing routing or caching rules. For several hostnames, keep an explicit inventory so that each deployment has an owner and a review date.

Keep expectations clear

Publishing security.txt does not grant permission for security testing, and its presence alone does not promise a bounty. Those terms need explicit policies. Its absence alone does not establish an exploitable vulnerability.

The worthwhile outcome is a working path from discovery to response: a clear contact, somebody responsible for it and a small maintenance habit that keeps the information useful.

Sources and further reading