Vulnerability handling

How to Build a CRA-Compliant Coordinated Vulnerability Disclosure Policy

Last updated · June 18, 2026

If a security researcher finds a flaw in your product tomorrow, what happens? If the honest answer is "they'd probably email support and it would sit in a queue," you have a compliance gap - and a practical security problem.

Regulation (EU) 2024/2847 - the Cyber Resilience Act - requires manufacturers to put in place and enforce a coordinated vulnerability disclosure (CVD) policy and to provide a contact point that researchers and users can reach directly and rapidly. This is not a box-ticking exercise. It is the front door of your entire vulnerability-handling process.

This guide explains what a CRA-compliant CVD policy must contain, how to build one, and - critically - how to avoid the most common confusion: conflating your CVD policy with the separate mandatory incident-reporting obligations under Article 14.

This is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against Regulation (EU) 2024/2847 and seek qualified legal advice for your situation.

Key points

The CRA requires a published CVD policy and a reachable contact point as part of your technical documentation (Annex I, Part II).
Your CVD policy governs how you receive and handle researcher reports - there is no fixed legal clock on this process.
Article 14 reporting to ENISA is a separate, parallel obligation triggered only by active exploitation or a severe incident - with a hard 24h/72h/14-day clock.
Your triage runbook must include an exploitation-check gate that triggers Article 14 reporting when needed.
Article 14 reporting obligations apply from 11 September 2026; the broader CVD-policy and vulnerability-handling obligations apply from 11 December 2027 - but building the process now is strongly advisable.

What the CRA actually requires

Annex I, Part II: the vulnerability-handling obligations

The essential requirements for vulnerability handling sit in Annex I, Part II of the CRA. Among them, manufacturers must "put in place and enforce a policy on coordinated vulnerability disclosure" and provide a contact address so that vulnerabilities discovered in the product can be reported. The BSI's TR-03183-H mapping document confirms this directly: manufacturers must "put in place and enforce a policy on coordinated vulnerability disclosure" and "provide a contact address for the reporting of the vulnerabilities discovered in the product with digital elements."

Article 13: manufacturer obligations

Manufacturers must have appropriate policies and procedures, including coordinated vulnerability disclosure policies referred to in Part II, point (5), of Annex I, to process and remediate potential vulnerabilities in the product with digital elements reported from internal or external sources.

That phrase "internal or external sources" matters. Your CVD policy is not just for researchers - it also governs how your own team escalates internally discovered issues through the same documented process.

The contact point must actually work

A generic support inbox that routes to a first-line helpdesk is not enough. The contact must reach staff who can act on a security report. Many companies say they accept vulnerability reports, but the reporting path is hidden, unmanaged, or routed through a general support queue. Under CRA conditions, the reporting channel becomes the trigger point for legal awareness, severity assessment, and evidence capture.

The contact point - and evidence that it exists - must appear in the product information, in the user instructions, and on the public website. It also forms part of your technical documentation, alongside your SBOM and a description of your secure update distribution process.

CVD policy vs. Article 14 reporting: the distinction that matters

This is where most teams get confused. They are two different processes with different triggers and different timelines.

	CVD Policy (Art. 13 / Annex I, Part II)	Mandatory Reporting (Art. 14)
What it is	Your process for receiving, triaging, fixing, and coordinating disclosure of reported vulnerabilities	Mandatory notification to ENISA when a specific threshold is crossed
Trigger	Any vulnerability report from a researcher, user, or internal source	Active exploitation of a vulnerability OR a severe incident affecting product security
Clock	No fixed legal deadline — you set reasonable timelines in your policy	24h early warning → 72h notification → 14-day final report (1 month for severe incidents)
Where it goes	Stays internal until coordinated disclosure with the reporter	ENISA Single Reporting Platform (SRP) → your designated national CSIRT
Applies from	11 December 2027 (full application)	11 September 2026
In your tech docs?	Yes — policy + contact point evidence required	No — this is an operational reporting obligation

The key operational implication: your CVD triage runbook must include an exploitation-check gate. When a report comes in, one of the first questions is whether there is any evidence of active exploitation. If yes, that simultaneously triggers your Article 14 clock - you do not wait for the CVD process to conclude before filing the early warning.

From 11 September 2026, CRA Article 14 requires you to report actively exploited vulnerabilities and severe incidents within 24 hours, escalating to a 72-hour notification, a 14-day final report for vulnerabilities (from the date a corrective or mitigating measure is available), and a one-month final report for severe incidents.

The ENISA Single Reporting Platform allows manufacturers to report actively exploited vulnerabilities and severe incidents only once, rather than having to notify multiple national authorities individually. The platform is scheduled to be operational by 11 September 2026, coinciding with the date when the mandatory reporting obligations for manufacturers officially enter into application. A testing period is expected to take place before this date.

See the CRA reporting deadlines page for the full Article 14 timeline and what to prepare before September 2026.

What your CVD policy must contain

Germany's BSI has published TR-03183, a concrete technical guideline that many manufacturers use as a specification for CRA compliance. BSI TR-03183-1 covers general requirements for manufacturers and products and is a living document. Part 3 describes the handling of incoming vulnerability reports. It is a useful reference even if you are not a German manufacturer.

Here is what a compliant CVD policy needs to cover:

Scope

State which products and versions are covered. Be specific — a researcher needs to know whether the firmware version they found a bug in is in scope. Include a note on what is explicitly out of scope (e.g. third-party hosted infrastructure you do not control).

Reporting channel

Provide a dedicated, monitored channel — a security@ address or a web form that reaches competent security staff. Publish a security.txt file at /.well-known/security.txt on your website. RFC 9116 defines the format: it is machine-readable, links to your policy, and tells researchers exactly how to reach you. Keep the Expires: field current — a stale security.txt signals neglect.

What a reporter can expect

Set explicit commitments: an acknowledgement target (e.g. within 5 business days), regular status updates (e.g. every 30 days), and a named point of contact for follow-up questions. Vague promises erode researcher trust and reduce the quality of future reports.

Safe-harbour language

State clearly that good-faith security research conducted in accordance with your policy will not result in legal action. This is one of the most important sections for attracting quality reports. Researchers routinely skip companies that have no safe-harbour statement — fear of legal action is a primary reason vulnerabilities go unreported.

Expected timelines

Define your target remediation timelines (e.g. critical: 30 days, high: 90 days) and your default coordinated disclosure window (commonly 90 days from acknowledgement, with an option to extend by mutual agreement). These are your commitments, not legal deadlines — but they should be realistic and honoured.

Coordinated disclosure process

Explain how you and the reporter will agree on a public disclosure date, what happens if a patch is delayed, and how you will credit the reporter (if they wish). Consider a Hall of Fame page or a bug bounty programme — BSI TR-03183 recommends these as positive incentives for researchers.

Exploitation-check gate → Article 14

Document internally (in your triage runbook, not necessarily in the public policy) that if triage reveals evidence of active exploitation, the Article 14 clock starts immediately. The CVD process and the Article 14 notification run in parallel — one does not wait for the other.

Where the policy lives: technical documentation

Your CVD policy and the evidence that your contact point is reachable must be included in your technical documentation - the same package that contains your SBOM and your description of secure update distribution. This is not just a website page; it is a compliance artefact that market surveillance authorities can request.

Keep a dated snapshot of your published CVD policy in your technical documentation folder. If you update the policy, retain the previous version. Auditors will want to see that the policy was in place before a vulnerability was reported, not assembled after the fact.

For SBOM requirements and how they fit into the same technical documentation package, see the CRA SBOM guide.

The security.txt file: your machine-readable front door

The security.txt file is a proposed Internet standard (RFC 9116) that concisely advertises an entity's vulnerability disclosure process. Like robots.txt, this machine-readable file resides on a public-facing webserver, either in the root or /.well-known/ directory, where security professionals and researchers can quickly identify the entity's preferences for reporting vulnerabilities.

A minimal security.txt for a CRA-regulated manufacturer looks like this:

Contact: mailto:security@example.com
Policy: https://example.com/security/cvd-policy
Expires: 2026-12-31T23:59:59z
Preferred-Languages: en, de

The Policy: field indicates a link to where the vulnerability disclosure policy is located, helping security researchers understand the organisation's vulnerability reporting practices.

Set a calendar reminder to refresh the Expires: field before it lapses. An expired security.txt is a red flag to researchers and a gap in your technical documentation evidence.

A practical decision tool

Use this widget to check whether your current setup meets the key CRA CVD requirements and identify what still needs to be done.

Your action list

You do not need to wait until December 2027 to build this. The CVD contact point is your earliest warning system for active exploitation - which means it directly feeds your Article 14 readiness for September 2026.

Do these now:

Publish a security.txt at /.well-known/security.txt with a Contact: and Policy: field pointing to a monitored address and a real policy page.
Route the contact to people who can act. Not a support queue. A named security team member or a monitored alias with a defined SLA for first response.
Write and publish your CVD policy covering the seven elements above. Keep it plain and specific - a researcher should be able to read it in five minutes and know exactly what to do.
Add the policy and contact-point evidence to your technical documentation alongside your SBOM.
Write the triage runbook with an explicit exploitation-check gate that triggers the Article 14 clock.
Rehearse the 24h clock before September 2026. Run a tabletop exercise: a simulated report comes in, triage finds evidence of exploitation - who files the early warning, how, and within what time? See the CRA reporting deadlines page for what the Article 14 flow requires.

Want a digest of CRA implementation news, new guidance documents, and deadline reminders delivered to your inbox? Subscribe to The CRA Brief - a short, practical newsletter for product teams building for the EU market.