Coordinated vulnerability disclosure under the CRA: policy, intake and security.txt

What the CRA requires

Annex I Part II(5) requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure; Part II(6) requires them to take measures to facilitate the sharing of information about potential vulnerabilities, including by providing a contact address; Part II(4) requires public disclosure of information about fixed vulnerabilities once a security update is available, including a description, affected products, impacts, severity and remediation guidance. Article 13(6) adds the upstream direction: when a manufacturer identifies a vulnerability in a component, including open source, it reports it to the component's maintainer and, where it fixes it, shares the fix. Recital and guidance also recognise the role of CSIRTs as intermediaries where a reporter and manufacturer cannot coordinate directly.

What a defensible policy contains

1. Scope: which products, versions and services are covered; what is out of scope (third-party services, social engineering, denial of service).
2. How to report: an e-mail address and/or web form, PGP key, what to include, preferred languages.
3. Safe harbour: a commitment not to pursue good-faith research that respects the scope, and what 'good faith' means.
4. Timelines: acknowledgement (two business days is common), triage (five business days), fix targets by severity, and a default public-disclosure window (90 days is the industry norm) with the conditions for extension.
5. Coordination: how you communicate progress, whether you support CVE assignment, how you coordinate with downstream manufacturers and CSIRTs.
6. Credit: how researchers are acknowledged, and an opt-out.
7. Ownership: who inside the company owns the process, and how reports become tickets, findings and — where exploitation is evidenced — Article 14 cases.

Publishing the contact: security.txt

RFC 9116 defines a machine-readable file at /.well-known/security.txt with at least Contact and Expires fields, and optionally Policy, Preferred-Languages, Acknowledgments, Canonical and Encryption. It is the first thing researchers and scanners look for. Generate one with the free tool on this site, publish it on every domain that hosts a product or its documentation, keep the expiry under a year and sign it if you can.

Running intake

A policy is only as good as the mailbox behind it. Route reports to a shared queue with an on-call owner, acknowledge within the promised time, record the report as a finding linked to the affected products and versions, and evaluate two questions immediately: severity, and whether the report contains evidence of exploitation in the wild. The second question matters because a researcher's report can be the awareness moment for Article 14 — record the time you received it and the time you confirmed the evidence.

Disclosure of fixed vulnerabilities

Once a security update is available, publish an advisory: identifier (CVE where assigned), affected products and versions, severity (CVSS), impact, fixed versions, workarounds, and credit. Where publication would harm security more than it helps — for example while exploitation is ongoing and the update is still rolling out — the CRA allows delaying publication; document the reasoning. Machine-readable formats (CSAF, CycloneDX VEX) let customers consume advisories automatically.

A policy outline you can adopt today

Aligning with ISO/IEC 29147 and 30111

29147 covers the external interface — receiving, coordinating and disclosing; 30111 covers the internal handling — triage, investigation, remediation and release. Together they map cleanly onto Annex I Part II and are the most likely basis for harmonised standards on vulnerability handling. If you already follow them, the CRA policy is largely a matter of writing down what you do and adding the Article 14 hand-off.