CRA topic guide

Coordinated vulnerability disclosure (CVD) under the CRA

Last updated · 8 Jun 2026

The CRA requires every manufacturer to run coordinated vulnerability disclosure (CVD): a published, private channel for security researchers to report flaws, plus a process to fix and disclose them responsibly. Separately, actively exploited vulnerabilities and severe incidents must be reported to authorities on a strict 24h/72h timeline through ENISA's Single Reporting Platform - live from 11 September 2026.

TL;DR

  • A coordinated vulnerability disclosure policy is a mandatory CRA requirement (Annex I, Part II).
  • You must provide a contact point for reporting vulnerabilities in your product.
  • Actively exploited vulnerabilities & severe incidents must be reported via ENISA's Single Reporting Platform.
  • The reporting clock is 24h early warning → 72h notification → 14-day final report.
  • These reporting duties start 11 September 2026, ahead of full CRA application.
Get the CRA ChecklistCheck if you are in scope

Overview

What it is

Coordinated vulnerability disclosure (CVD) is the agreed, good-faith process by which a security researcher reports a vulnerability privately to a manufacturer, who then fixes it and discloses it in a coordinated way - protecting users in the window before a fix exists. The CRA has two distinct strands: (1) a standing duty to operate a CVD policy and contact point for your product, and (2) a separate mandatory reporting duty to public authorities when a vulnerability is actively exploited or a severe incident occurs.

The regulation

What the CRA requires

  • Annex I, Part II(5) requires manufacturers to put in place and enforce a policy on coordinated vulnerability disclosure.
  • Manufacturers must provide a contact address for reporting vulnerabilities and facilitate reporting by third parties.
  • Art. 14 requires reporting of actively exploited vulnerabilities and severe incidents via the Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours, and a final report (14 days for vulnerabilities; one month for incidents).
  • You report once; the notification reaches the relevant national CSIRT and ENISA. Micro/small enterprises and open-source stewards have carve-outs from some penalties.

How to comply

How to comply

  1. Publish a CVD policy and a clear "report a vulnerability" contact (e.g. security.txt + a monitored inbox).
  2. Define internal SLAs to triage, fix and disclose reported vulnerabilities.
  3. Prepare for mandatory reporting: know your national CSIRT and register for the Single Reporting Platform.
  4. Build a 24h/72h/14-day playbook so an actively-exploited finding triggers the right reports on time.
  5. Coordinate disclosure with reporters and downstream users once a fix is available.
  6. Keep records of reports, decisions and timelines for your technical documentation.

Watch out

Common mistakes

  • Having no public way for researchers to report - so they go public instead.
  • Confusing the standing CVD policy with the separate mandatory incident reporting duty.
  • Missing the 24-hour early-warning window because there is no rehearsed playbook.
  • Treating disclosure as PR risk rather than a security obligation, and punishing good-faith reporters.

FAQ

Common questions

Is a CVD policy mandatory under the CRA?
Yes. Annex I, Part II requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy and to provide a contact point for reports.
What is the 24-hour rule?
For an actively exploited vulnerability or a severe incident, you must submit an early warning to the Single Reporting Platform within 24 hours of becoming aware, followed by a fuller notification within 72 hours and a final report later.
Where do I report?
Through ENISA's Single Reporting Platform, which routes your single report to the relevant national CSIRT and ENISA. It becomes operational on 11 September 2026.
Do small companies get any relief?
Micro and small enterprises may not be fined for missing the 24-hour reporting deadline, and open-source software stewards are not subject to fines - but the duty to act responsibly still applies.

Related guides

More CRA topic guides

SBOM

SBOM (Software Bill of Materials) under the CRA

An SBOM is an "ingredients label" for your software: a machine-readable inventory of components and dependencies.

Security by design

Security by design under the CRA

Security by design means building in security from the first design decision, proportionate to the product's risk.

Secure by default

Secure by default under the CRA

Secure by default means the out-of-the-box configuration is the safe configuration.

Back to the CRA overview or see all guides.

This is guidance, not legal advice

This guide explains how the Cyber Resilience Act approaches coordinated vulnerability disclosure, but it is not legal advice. For decisions specific to your business or product, confirm with the official sources we link or a qualified adviser.

Sources

  1. [1]European Commission - CRA reporting obligationsretrieved 8 Jun 2026
  2. [2]ENISA - Single Reporting Platformretrieved 8 Jun 2026
  3. [3]European Commission - CRA legislative summaryretrieved 8 Jun 2026
  4. [4]Regulation (EU) 2024/2847 - full text (EUR-Lex)retrieved 8 Jun 2026

The CRA Brief

Stay current on CRA guidance

We watch Brussels so you don't. Plain-English CRA updates, free.

No spam. Unsubscribe anytime.