How to set up security.txt: required fields and checklist

A predictable place to report a concern

Someone notices a potential issue on your website and wants to report it. Having to navigate sales, support and several suppliers adds avoidable delay. A clear reporting route helps both sides: the finder has a destination, and your business receives a report it can assess.

RFC 9116 describes security.txt. For web services, the file is served over HTTPS at /.well-known/security.txt. Contact and Expires are required fields.

Start with a simple inventory: which public domains belong to your business, who operates them, and where should reports about each one go? Agree the published contact with the people who will actually handle the reports. [1]

Give the inbox an owner

Name an owner and a backup. Agree who checks incoming messages, who assesses technical questions and who covers absences. Where several suppliers are involved, record which provider is responsible for each service.

Arrange an explicitly agreed, harmless delivery test with a clearly identifiable subject line. Check more than whether sending succeeds: does the message reach the intended inbox, enter the handling process, and allow the owner to reply? An accessible file alone does not answer these questions.

A shared ticket or internal reference can be enough. Record when the report arrived, the affected service, its owner and the next action. Avoid forwarding sensitive information to unnecessarily large distribution lists.

The reporting route at a glance

The illustration separates four jobs. The published file identifies the contact. Intake receives the report. An assigned person checks whether it concerns the organisation's systems. A response keeps the conversation open.

A small team can use the same approach. Make each handover explicit: who has the report now, what question remains, and when will the next action be reviewed? If a supplier operates the affected service, include the handover to that supplier.

Publish the contact alongside clear rules

A published contact address is not, by itself, an instruction to conduct a security assessment. Keep reporting an observation separate from permission to carry out further testing.

The NCSC recommends a clear disclosure policy covering contact routes, the information to include, what response to expect and the boundaries of permitted investigation.

For an initial report, we recommend the affected address, a brief description and the observation time. Passwords and extensive personal datasets are unnecessary for that first contact. If additional evidence is needed, agree a suitable transfer method. Publish only response targets your team can reliably meet. [2]

Review it when responsibilities change

Treat the security contact as operational contact information. Add it to your checklist for domain migrations, supplier changes and staff departures. Schedule a review before the published details expire.

A short repeatable check is a useful starting point: retrieve the public file, compare the details with internal ownership and check the agreed reporting route. Record the result and date. This turns a file uploaded once into a maintained channel for actionable security reports.

Check the fields and the HTTP response

For web services, serve the file over HTTPS at /.well-known/security.txt as UTF-8 text with the text/plain media type. An HTML error page returning status 200 is not a valid security.txt file. Check the body and response headers together.

Scope is specific: a file on example.com does not automatically cover its subdomains. Inventory each intended host. The fields below are a selection, not a complete RFC 9116 conformance check. [1]

Swipe or scroll sideways to read the table.

Record the check and assign ownership

The editable checklist connects the public file to the internal reporting process. Use one copy per domain, enter observed results and schedule another review. It is not an automated scanner and does not, by itself, certify a secure configuration.

Download the security.txt review checklist