Coordinated vulnerability disclosure under the CRA

A researcher finds a flaw in your product and wants to tell you. Can they find out how? Does the report reach someone who'll act on it? Will the researcher be thanked, or threatened with a lawyer? Coordinated vulnerability disclosure is the answer to those questions, and under the CRA it isn't optional.

What the CRA requires

The CRA's vulnerability-handling requirements, in Annex I, oblige a manufacturer to put in place and enforce a policy on coordinated vulnerability disclosure, and to provide a contact address for reporting vulnerabilities found in the product. It also expects you to facilitate the sharing of information about vulnerabilities, including with the people who report them.

Two words carry weight. Enforce means a policy on a shelf isn't enough — you have to run the process it describes. And coordinated is deliberate: the CRA uses the modern term, in line with ISO/IEC 29147 on vulnerability disclosure, rather than the older "responsible disclosure," which is now discouraged for implying a reporter is irresponsible if they don't play along.

What a CVD policy actually contains

A workable policy is short and specific. It answers, in plain language, everything a would-be reporter needs to know before they contact you:

• Scope. Which products, versions and domains the policy covers — and anything explicitly out of scope.
• How to report. The channel, the contact address, and what to include. An encryption key if you accept encrypted reports.
• Good-faith safe harbour. A commitment that you won't pursue legal action against researchers acting in good faith within the policy. This is the clause that decides whether serious researchers engage with you at all.
• What to expect. Acknowledgement timeframe, how you'll keep the reporter updated, and your approach to disclosure timing once a fix exists.
• Recognition. Whether you credit reporters, and how.

Publish it at a stable URL, version it, and — the part the CRA underlines — actually follow it.

security.txt: the machine-readable front door

A policy that nobody can find doesn't help. security.txt, defined by RFC 9116, is the standard, expected way to advertise the contact address the CRA requires. It's a plain text file at a fixed location — /.well-known/security.txt — that a researcher (or their tooling) checks first. It takes minutes to add:

# Our security disclosure contacts and policy
Contact: mailto:security@example.com
Contact: https://example.com/security/report
Policy: https://example.com/security/disclosure-policy
Encryption: https://example.com/pgp-key.txt
Preferred-Languages: en, cs
Expires: 2027-01-01T00:00:00.000Z

Only Contact and Expires are required; the rest are recommended. Keep the Expires date current — an expired file signals a neglected process, which is the opposite of what you want a researcher, or an auditor, to conclude.

Researcher intake: a channel, not a black hole

The contact address is the front door; intake is what happens behind it. A report has to land somewhere monitored, get acknowledged, and enter your vulnerability handling — not sit in an inbox nobody reads. In practice that means a defined path: report received, triaged, assessed, and either actioned or closed with a reason, with the reporter kept informed along the way.

The point worth internalising is that an inbound report is an input to the same process as a CVE you found yourself. It shouldn't run on a separate, manual track. It should flow into the same triage, the same evidence trail, and — if it turns out to matter — the same reporting pipeline.

From a report to a determination

Here's where coordinated disclosure connects to the rest of your CRA programme. A researcher's report is a claim: "your product is vulnerable to X." Before you act, you have to answer the same question you'd ask of any finding — is it actually exploitable in our product?

An inbound report tells you where to look. It doesn't tell you what you're obliged to do about it.

That determination is the evidence-backed VEX question again: reachability and, where warranted, an exploitation attempt, producing a status backed by proof rather than a hurried judgement made under the pressure of an external report. And if the reported vulnerability turns out to be exploitable — and it's being actively exploited — the same report can start the 24 / 72 / 14 reporting clock. Wiring intake into that pipeline is what turns a disclosure inbox from a compliance box-tick into part of a working programme.

Common mistakes

• No policy at all. The most common gap, and a straightforward CRA failure.
• A policy with no process. Published boilerplate that no one is resourced to act on — which the "enforce" requirement specifically targets.
• No security.txt, or an expired one. Reachability for researchers is the whole point; an expired file reads as neglect.
• No safe harbour. Without a good-faith commitment, capable researchers won't risk reporting to you — they'll disclose elsewhere, or not at all.
• A separate, manual track. Intake that doesn't feed your normal triage and evidence trail duplicates work and loses reports.

Frequently asked