CRA File / guide, updated 2026-10-05

Vulnerability disclosure policy template for the Cyber Resilience Act

The Cyber Resilience Act expects manufacturers of products with digital elements to handle vulnerabilities as a process, not an afterthought. Annex I, Part II lists the vulnerability handling requirements. Two of them are small and concrete: put in place and enforce a policy on coordinated vulnerability disclosure, and facilitate sharing information about potential vulnerabilities, including by providing a contact address for reporting them.

This page gives you a template for the policy and shows how to publish the contact as a security.txt file. You can fill both in with the security.txt and policy generator, which runs in your browser.

What the policy should say

A short policy can cover these points; the Regulation does not prescribe a format:

Scope. Which product and which versions the policy covers.
How to report. One contact address (an e-mail address or a web form) and what to include: the affected version, steps to reproduce, the impact.
What the reporter can expect. A confirmation within a stated number of working days, regular updates and a target time for a fix or mitigation.
Disclosure. That you ask for coordinated disclosure: the reporter gives you the stated time before publishing details, and you publish an advisory once a fix is available.
Good-faith research. What testing you welcome and what you do not (other people's data, service disruption).
Your own duties. If you are the manufacturer, you must report actively exploited vulnerabilities and severe incidents to the CSIRT of your main establishment and to ENISA (Article 14). A report to you does not replace any duty the reporter may have.

Template

# Vulnerability disclosure policy: <product>

<Organisation>. Generated from your inputs; review before publishing.

## Scope
<Product and versions covered.>

## How to report
Send the report to <security contact>. Include the affected version, steps to
reproduce and the impact you see. Please do not include other people's personal data.

## What you can expect
- We confirm receipt within <3> working days.
- We assess the report and keep you informed.
- We aim to release a fix or a mitigation within <90> days and publish an
  advisory describing the fixed vulnerability once an update is available.
- We ask for coordinated disclosure: please give us that time before you
  publish details.

## Good-faith research
Test only against your own accounts or installations; do not access, change or
destroy data that is not yours; do not disrupt services; report promptly.

Publish the contact as security.txt

security.txt (RFC 9116) is a small text file that tells researchers where to report. Publish it at https://your-domain/.well-known/security.txt, over HTTPS, as text/plain. Two fields are required:

Contact: an e-mail address (mailto:), a phone number (tel:) or an HTTPS link. You can list several.
Expires: a date and time after which the file should be considered stale. It appears exactly once. RFC 9116 recommends less than a year ahead, so put a reminder in your calendar.

Useful optional fields: Policy: (an HTTPS link to your policy), Preferred-Languages: (once), Canonical:, Acknowledgments: and Encryption: (a link to your public key, usually https, never the key itself).

Contact: mailto:[email protected]
Expires: 2027-06-30T00:00:00Z
Policy: https://example.com/security-policy
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

Next steps

Generate both files from your own details.
Check what your GitHub repository already shows: a SECURITY.md with a contact is a common way to publish a contact address; it is not named in the Regulation.
Classify your product to see which other obligations apply.

This page is general information, not legal advice; check the Regulation for your product.

Free tools

Product classifier: Is your product in scope, and in which category?
SBOM checker: Check a CycloneDX or SPDX file in your browser.
security.txt and disclosure policy: The contact file and policy the Regulation expects.
Repository check: what a GitHub repository already shows.

Information generated from your inputs, with article references to Regulation (EU) 2024/2847. It is not legal advice and does not replace your own assessment; check the references against the Official Journal.