security.txt and vulnerability disclosure policy generator
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy, provide a contact address for reporting vulnerabilities, and tell users where both can be found. A security.txt file, defined in RFC 9116 and served at /.well-known/security.txt, is the standard machine-readable way to publish that contact and link to the policy. This tool writes both from one form.
A drafting aid, not legal advice. The generated policy is a starting point to adapt, and the CRA requirements below are summarised from the regulation, with short quotes: Official text on EUR-Lex.
Your details
Everything runs in your browser. Nothing you type is sent anywhere.
security.txt
Save as security.txt in the /.well-known/ directory of the domain it describes. A file applies only to its own domain, so generate one per domain, each with its own Canonical. The RFC recommends signing it with OpenPGP.
Vulnerability disclosure policy
Markdown. Publish it at your Policy URL and edit anything that doesn't match how you work.
# [Organisation] vulnerability disclosure policy [Organisation] welcomes reports of security vulnerabilities in our products. This policy explains what is covered, how to report a vulnerability to us, and what you can expect from us in return. ## Scope This policy covers all products and services we make available. - Out of scope: denial-of-service testing, social engineering, physical attacks, accessing more data than you need to demonstrate a vulnerability, and changing or deleting data that is not yours. ## How to report a vulnerability Report vulnerabilities to us through any of these routes, most preferred first: - [contact] ## What to include - The product and version affected. - A description of the vulnerability and its potential impact. - Steps to reproduce it, and a proof of concept if you have one. - Whether you know or suspect it is being actively exploited. - How you would like to be credited, if at all. ## What happens next - We will acknowledge your report within 3 business days. - We will give you an initial assessment, including whether we can reproduce the issue and how severe we consider it, within 10 business days. - We will keep you informed as we work on a fix, and tell you when a security update is available. ## Coordinated disclosure Please keep the vulnerability confidential until a fix has been available for 14 days, so users have had the chance to apply it, or until 90 days have passed since your report, whichever comes first. Within that window we will agree the exact publication date with you; any extension is yours to grant. Once a security update is available, we will publish information about the fixed vulnerability: what it is, which products are affected, its severity and impact, and how to remediate it. ## EU Cyber Resilience Act As a manufacturer of products with digital elements, we are subject to the EU Cyber Resilience Act (Regulation (EU) 2024/2847), which requires manufacturers to notify actively exploited vulnerabilities in their products to the CSIRT designated as coordinator and to ENISA, starting with an early warning within 24 hours of becoming aware of one. If you have evidence that a vulnerability is being exploited, tell us in your report so that we can act on it straight away. When we find a vulnerability in a third-party or open-source component of our products, we report it to whoever maintains that component. You may also report a vulnerability voluntarily to a CSIRT designated as coordinator or to ENISA (Article 15 of the Cyber Resilience Act). Doing so does not place obligations on you under the Cyber Resilience Act that you would not otherwise have had.
When a report turns out to be an actively exploited vulnerability, the CRA’s reporting clocks start. FOSSA’s guide to the 24-hour reporting workflow (on fossa.com, opens in a new tab) covers what to send and when.
What the CRA asks for
The regulation never mentions security.txt. What it requires is a route for reports and a policy for handling them, in four places:
- Manufacturers must “put in place and enforce a policy on coordinated vulnerability disclosure” (Annex I, Part II, point 5). See coordinated vulnerability disclosure.
- They must facilitate the sharing of information about potential vulnerabilities, “including by providing a contact address for the reporting of the vulnerabilities discovered in the product” (Annex I, Part II, point 6).
- They must designate a single point of contact that lets users communicate “directly and rapidly” with them, including to report vulnerabilities. It must be easily identifiable, let users choose their means of communication, and not be limited to automated tools (Article 13(17)).
- The information accompanying the product must include that single point of contact and “where the manufacturer’s policy on coordinated vulnerability disclosure can be found” (Annex II, point 2).
A security.txt file does not replace the user information in Annex II, but it puts the same contact and policy link where researchers and scanners already look. Because the single point of contact must not rely only on automated tools, list a contact that reaches a person, such as a monitored email address or phone number.
security.txt fields
RFC 9116 defines the format: one “Name: value” field per line in UTF-8, served as text/plain; charset=utf-8 over https from /.well-known/security.txt. A file applies only to the domain it is served from, so each domain gets its own copy with its own Canonical. Only Contact and Expires are required, and any web link in a field must begin with https://. Signing the file with an OpenPGP cleartext signature is recommended.
| Field | Required | What it holds |
|---|---|---|
| Contact | Yes | How to report a vulnerability: a mailto:, tel: or https:// URI, most preferred first. |
| Expires | Yes | When the file goes stale, as an RFC 3339 date and time. Recommended less than a year ahead. At most once. |
| Encryption | No | A link to the key researchers should encrypt reports with. Never the key itself. |
| Policy | No | A link to your vulnerability disclosure policy. |
| Acknowledgments | No | A link to the page crediting researchers. |
| Preferred-Languages | No | Language tags for reports, comma-separated. English is assumed if absent. At most once. |
| Canonical | No | The URL the file is served from. Recommended when the file is signed. |
| Hiring | No | A link to security job openings. |
| CSAF | No | A link to a CSAF provider-metadata.json, for machine-readable security advisories. |
| Bug-Bounty | No | True or False: whether you may financially reward reporters. At most once. |
CSAF and Bug-Bounty were added to the IANA field registry after the RFC; the rest are defined in RFC 9116 itself. Researchers are expected to ignore fields they do not support.
Vulnerability disclosure policy template
A disclosure policy tells a researcher what you want reported, how to reach you, and what to expect in return. The parts that matter most are the ones you can actually keep: a monitored contact, response times your team can meet, and a disclosure window.
The CRA adds two things to plan for. Once a security update is available, manufacturers must publicly disclose information about the fixed vulnerability, including its severity, the products affected and how to remediate it; publication may be delayed in duly justified cases until users have had the chance to patch (Annex I, Part II, point 4). And a vulnerability found in an integrated component, open-source included, must be reported to whoever maintains it (Article 13(6)).
Anyone can also report a vulnerability to a CSIRT designated as coordinator or to ENISA voluntarily (Article 15(1)). Doing so places no obligations on the reporter under the CRA that they would not otherwise have had (Article 15(5)). The generated policy says so when the CRA section is included.
Common questions
Does the Cyber Resilience Act require a security.txt file?
No. It requires a contact address for vulnerability reports, a single point of contact and a coordinated vulnerability disclosure policy. security.txt is a widely used, standard way to publish the contact and point to the policy, so it supports those requirements without being one of them.
Where does the security.txt file go?
At /.well-known/security.txt on the domain it describes, served over https as text/plain; charset=utf-8. A file only applies to the domain it is served from, so generate one per domain, each with that domain’s Canonical.
How far ahead should Expires be?
Less than a year, as the RFC recommends. An expired file tells researchers the information may be stale, so put the renewal in a calendar.
What if a report is about an actively exploited vulnerability?
Then the CRA’s reporting clocks apply to the manufacturer: an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. These obligations have applied since 11 September 2026; see the CRA timeline.
Disclosure covered? Check the rest
A free assessment that runs in your browser and scores a product against the Annex I requirements, vulnerability handling included, with a 30/60/90-day plan at the end.
Assess CRA readiness (on fossa.com, opens in a new tab)How do others handle reports?
Ask practitioners how they run disclosure programmes, set response times and handle the CRA reporting deadlines.
Ask the community