Someone outside your company may one day find a weakness in your product. What happens next depends on a small question: can they find out who to tell? If the answer is a general support form, a sales inbox or nothing at all, the report may sit in the wrong queue, or never arrive.
This essay covers two answers to that question: a file that tells people where to write, and a policy that tells them what happens once they do. It is not legal advice, and nothing here tells you whether your product meets any law. That judgement belongs to you and your advisers.
A file in a place anyone can look
RFC 9116, published in April 2022, describes a plain text file called security.txt. For a website, it lives at /.well-known/security.txt, and the RFC asks for it to be served over HTTPS. Anyone who wants to report a problem can look in the same place on every site.
RFC 9116 makes two fields required:
- Contact: where reports should go, written as a URI, such as an email address or a web page. It must appear at least once and may appear more than once.
- Expires: the date and time after which the file should be treated as stale. It must appear exactly once, and the RFC recommends a date less than a year ahead.
Everything else is optional. RFC 9116 names the other fields Acknowledgments (a page that thanks those who reported issues), Canonical (where the file officially lives), Encryption (a key for sending a report privately), Hiring (security roles you are recruiting for), Policy (a link to your disclosure policy) and Preferred-Languages (the languages your team reads). The RFC also recommends signing the file with an OpenPGP cleartext signature.
The Expires field is the one that turns a file into a habit. It forces someone to look at the contact again, which is the point: a contact that nobody reads is worse than none, because it looks like an answer.
A policy that says what happens next
A file tells people where to write. A coordinated disclosure policy tells them what happens after they do. In plain terms, it is a published page that says what you want reported and how, what the person reporting can count on from you, and how you and they agree on when a weakness and its fix become public. The word “coordinated” carries the idea: the finder and the maker agree on the timing, rather than either side deciding alone.
The Policy field in security.txt is where the two meet. The file points to the policy, and the policy explains the process.
Where the Cyber Resilience Act comes in
In Europe, this is moving from good practice towards a legal requirement for some products. Regulation (EU) 2024/2847, the Cyber Resilience Act, sets vulnerability handling requirements in Annex I, Part II. Among them, a manufacturer is asked to put in place and enforce a policy on coordinated vulnerability disclosure, and to make it easier to share information about potential vulnerabilities, including by providing a contact address for reporting them.
Under Article 71, those requirements apply from 11 December 2027. The Regulation does not name security.txt, and whether your product falls within its scope at all is a question for your advisers. Our essay The Cyber Resilience Act, for product leaders sets out the scope, the dates and the rest of what the text asks.
What to decide
It comes down to a handful of decisions that someone should own:
- Who receives reports, and which address they arrive at. Choose one you are willing to keep.
- Who renews the file before its Expires date, and how they are reminded.
- What your policy says, in words your own team can stand behind.
- Who decides when a reported weakness is serious, and who talks to the person who reported it.
Settle these once, keep them current, and you can lift your eyes from the inbox to the product your customers rely on.
Where we come in
We do not give legal advice, we never promise compliance, and we do not tell you when you will be ready. Your security contact, your policy and the reports you receive stay yours.
What we can do is the security work on your product that you choose. We work within the access you grant, and nothing more. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval. It starts with a conversation, with no obligation, and the work itself is described in Harden security before the questionnaire arrives.
