Anyone who finds a vulnerability in your product needs a clear, human-reachable way to report it, and your team needs a written policy for how that report is acknowledged, triaged, fixed, and disclosed. Under the EU Cyber Resilience Act (Regulation (EU) 2024/2847), that means putting in place and enforcing a coordinated vulnerability disclosure (CVD) policy, plus publishing a single point of contact for vulnerability reports. There is no SME exemption. This page covers what the policy must contain, how to publish the contact channel, and how CVD interacts with vulnerability reporting and the broader vulnerability handling framework.
Summary
- CVD policy is mandatory. Written, published, enforced, with no size threshold. Detailed in What the CRA actually requires below.
- A single point of contact is required. Users must be able to reach a human; the channel cannot be limited to automated tools.
security.txt(RFC 9116) is the de facto convention for publishing the contact, but the CRA does not mandate a specific format.- CVD is not the same as ENISA reporting. CVD governs your relationship with the reporter; the regulatory clock to ENISA and the coordinator CSIRT runs in parallel. See Coordination with ENISA below.
- Public disclosure of fixed vulnerabilities is required, with a narrow delay carve-out where the security risk of publication outweighs the benefit until users have had the opportunity to patch.
- Penalty details belong in the enforcement guide. See penalties and enforcement for the fine ladder and market-measure powers.
The four anchors that define a CRA-compliant CVD posture: the policy mandate, the contact duty, the publication convention, and the enforcement handoff.
What the CRA actually requires for CVD
The CVD requirement is short: manufacturers must "put in place and enforce a policy on coordinated vulnerability disclosure". That single sentence carries four operational components, each of which fails differently:
| Requirement | What it means in practice | Common failure |
|---|---|---|
| Put in placeDocumented policy | A written, accessible policy exists. It tells reporters what is in scope, how to report, what response to expect, and when disclosure happens. | An undocumented internal habit of triaging security@ emails does not qualify. |
| EnforceOperated process | The policy is operated, not just published. Acknowledgement timelines, triage commitments, and disclosure conditions written in the document are honoured in practice. | A policy promising 72-hour acknowledgement that routinely takes three weeks is not enforced. |
| Facilitate reportingAccessible channel | The policy makes sharing vulnerability information easy for external reporters: a contact address, a published process, and a human-reachable channel that is not gated behind a login or chatbot. | A login-only portal, bot-only intake, or buried contact path fails the direction of the duty. |
| Do not penalise reportersGood-faith research norm | Not a literal CRA clause. The CRA frames CVD as structured reporting and notes bug-bounty programmes may incentivise reports. ISO/IEC 29147 and ENISA good-practice guidance treat safe harbour for good-faith research as a normal CVD-policy feature. | Reserving legal action against in-scope, good-faith research collapses the reporting channel even if a contact address exists. |
For the broader framework (the eight numbered duties of which CVD is one), see vulnerability handling. For the combined Article 14 overview, see vulnerability handling and reporting.
The single point of contact
The CVD policy only works if reporters can find a real contact and get a human route into the manufacturer. The CRA's single-point-of-contact duty turns that into three concrete requirements:
- Easily identifiable. The contact must be visible in the product information, in the user instructions accompanying the product, and on the public-facing website. A contact reachable only by reading the privacy policy fails this test.
- Multiple channels. "Choose their preferred means of communication" means at least two. A working
security@mailbox plus a web form, with a PGP key available for sensitive submissions, is the realistic baseline. - No bot-only intake. "Shall not limit such means to automated tools" rules out a posture where the only reachable address is
security-noreply@or a chatbot that closes tickets without human review.
The CRA does not require separating consumer support and vulnerability intake, but most manufacturers operate a dedicated security inbox routed to the product security team to keep CVD distinct from general support.
Publishing your CVD policy: security.txt and beyond
The CRA does not name security.txt, RFC 9116, or any specific publication format. It requires a contact channel that is "easily identifiable" and a CVD policy that is "in place and enforced". Within those constraints, the industry has converged on security.txt as the de facto convention.
RFC 9116 fields worth publishing:
| Field | Purpose |
|---|---|
Contact: |
One or more reporting channels. At least one is required. |
Expires: |
Date after which the file is stale. Required by RFC 9116. |
Encryption: |
Public key (PGP, S/MIME) for confidential reports. |
Acknowledgments: |
Page crediting researchers for past disclosures. |
Policy: |
Link to the full CVD policy document. |
Preferred-Languages: |
Languages your triage team operates in. |
Canonical: |
URL where the file is expected to live. |
Where to host it. The conventional location is https://example.com/.well-known/security.txt, served over HTTPS. RFC 9116 also accepts https://example.com/security.txt as a fallback, but well-known is preferred.
Beyond security.txt. The "easily identifiable" standard means the contact should also appear on the product support or contact page, in the user instructions accompanying the product, on developer documentation for API products, and on a public CVD policy page that researchers can link to.
Manufacturers running bug bounties typically add HackerOne, Bugcrowd, or Intigriti as additional intake channels. These satisfy the "facilitate reporting" duty and the "not limited to automated tools" duty only if open to external reporters with human response. A private, invite-only bounty does not by itself satisfy the public-contact requirement and must coexist with a public channel.
Receiving and triaging vulnerability reports
A CVD policy is enforced through a documented intake-and-triage workflow. The mechanics below are not prescribed by the CRA, but they are how an enforceable policy looks in practice.
| Stage | What an enforceable policy does | Common failure |
|---|---|---|
| Acknowledgement | Confirm receipt within the published SLA. Industry baseline is 72 hours; many policies commit to 24 or 48 hours for high-severity reports. What you publish is what you do. | "We will respond promptly" is unenforceable on its face. |
| Triage | Validate (reproducible on a supported version), score severity (CVSS v3.1 or v4.0 with environmental adjustments, see severity scoring), assess exploitability (known exploit, public PoC, or in-the-wild evidence, which gates regulatory escalation), and scope to affected versions via the SBOM. | Closing as "won't reproduce" without naming the version range tested. |
| Researcher relationship | Publish three things: a safe-harbour statement for good-faith research in scope; out-of-scope items (production data, social engineering, denial-of-service against live infrastructure); and disclosure expectations (embargo window, fix conditions, credit). Typical embargo: until the patch ships, hard backstop 90 days. | Reserving the right to take legal action against in-scope research, which collapses the channel. |
| Closing the loop | Every report gets a final response: fixed (with advisory and CVE), duplicate, won't fix (with reasoning), or out of scope. | Acknowledging once and going silent, the most common reason CVD policies fail to look enforced from the outside. |
Coordination with ENISA and external researchers
CVD intake and ENISA reporting are different obligations with different audiences. The CVD policy governs your relationship with the reporter. The regulatory notification governs your duty to ENISA and the coordinator CSIRT. They run in parallel and they trigger differently.
When a CVD report becomes a regulatory trigger. Manufacturers must notify "any actively exploited vulnerability" through the SRP on a 24-hour, 72-hour, and 14-day cadence. The trigger is "actively exploited", not "reported". A CVD intake with a working proof-of-concept is not by itself a regulatory trigger; it becomes one when there is reasonable belief that a malicious actor has used the flaw against a real target.
Severe incidents follow a different cadence: 24 hours, 72 hours, then a final report within one month of the 72-hour notification. The two streams share the early stages and diverge on the final-report leg. Do not collapse them into a single "24h/72h/14d" framing. See vulnerability reporting.
ENISA and CSIRTs designated as coordinators. Submission goes through the SRP using the electronic end-point of the CSIRT designated as coordinator in the Member State of the manufacturer's main establishment. Manufacturers may receive reports directly, or indirectly via a CSIRT designated as coordinator under the NIS2 Directive. For SRP onboarding mechanics, see ENISA SRP onboarding.
Researcher coordination. Where a researcher offers an embargo while you ship a fix, document the agreed window and respect it. Where the researcher refuses or publishes early, your CVD policy should state how you respond, typically by accelerating the advisory and the patch.
Public disclosure timing
Public disclosure of a fixed vulnerability is not optional under the CRA. Once a security update has been made available, manufacturers must share and publicly disclose a description of the vulnerability, information allowing users to identify the affected product, the impact, the severity, and clear remediation guidance. A delay is permitted "in duly justified cases" where the security risks of publication outweigh the benefits, but only "until after users have been given the possibility to apply the relevant patch".
Embargo windows. The de facto industry standard is 90 days from report to public disclosure, measured from the date the manufacturer was first notified. Project Zero, CERT/CC, and most national CSIRTs operate on or near that anchor. For actively exploited vulnerabilities the window typically collapses to days, because the regulatory final report is due within 14 days of a corrective measure becoming available.
Format of public disclosure. A CRA-aligned advisory should carry, at minimum, a CVE ID, a clear description, affected product and version range, severity (CVSS base score), impact, remediation, and credit where the reporter has agreed to be named. CSAF (Common Security Advisory Framework) is the machine-readable carrier most national CSIRTs and ENISA's vulnerability database expect.
The "duly justified" delay is narrow. It permits holding public detail until users can patch; it does not permit silent fixes that never publish. A manufacturer who ships a patch and never describes what it fixed is in breach of the public-disclosure duty regardless of intent.
Common Pitfalls
| Pitfall | Why it fails the CRA |
|---|---|
| Legal threats against good-faith researchers | Breaks the "enforce a policy on coordinated vulnerability disclosure" duty and chills the required intake channel. |
| No public contact channel, only an internal portal login | Fails the easily identifiable contact route and the contact-address duty. |
security-noreply@ autoresponder with no human triage |
The single point of contact cannot be limited to automated tools. |
| Acknowledging receipt and never responding again | The policy is in place but not enforced; both are required. |
| Closing reports as "won't fix" with no reasoning | Externally indistinguishable from ignoring the report; researchers escalate by publishing. |
| Bundling security fixes into feature releases that users defer | Security updates must be separable from functionality updates where technically feasible. |
| Silently patching with no advisory | Breaches the public-disclosure duty. |
| Treating CVD intake as the ENISA submission | Different audiences, different obligations. CVD does not relieve regulatory reporting, and regulatory reporting does not relieve CVD. |
Frequently Asked Questions
Do small manufacturers need a CVD policy under the CRA?
Yes. The CVD-policy duty carries no size threshold. It applies to every manufacturer placing a product with digital elements on the EU market, regardless of headcount or turnover. Microenterprises and small enterprises benefit from narrow penalty relief on the 24-hour early-warning deadlines, but the relief touches only those fines, not the underlying obligation, and does not extend to medium-sized enterprises. A two-person firmware vendor needs a published CVD policy, a contact channel, and a triage process the same way a large vendor does.
Is `security.txt` mandatory under the CRA?
No. The CRA does not name security.txt or RFC 9116. It mandates an "easily identifiable" single point of contact and a contact address for vulnerability reporting. security.txt is the de facto convention used to satisfy those duties because it is what automated scanners and most researchers check first, but a contact published prominently on a public security page and in the user instructions accompanying the product is also compliant. The hard requirement is a published, working, human-reachable channel; the format is a choice.
Can the CVD intake be the same channel as the ENISA submission?
No. They are different audiences and different obligations. CVD intake is the channel through which external researchers and users report vulnerabilities to the manufacturer. The ENISA submission is the manufacturer's regulatory notification to ENISA and the coordinator CSIRT, made through the Single Reporting Platform. A researcher does not file to the SRP; the manufacturer does. Conflating the two leads to either failing to acknowledge a researcher (CVD breach) or failing to notify ENISA when exploitation is confirmed (serious enforcement exposure).
What happens when an external researcher reports an actively exploited vulnerability?
Two clocks start in parallel. The CVD process governs the researcher relationship: acknowledge receipt, triage, agree on an embargo, ship a fix, publish an advisory, credit the reporter. The regulatory process governs the relationship with ENISA and the coordinator CSIRT: a 24-hour early warning, a 72-hour notification, and a final report within 14 days of a corrective measure becoming available. The 24-hour clock starts when the manufacturer becomes aware that exploitation is active, which can be the moment the researcher's evidence makes that conclusion credible. Waiting for forensic certainty will miss the deadline. The two processes run in parallel and finish on different surfaces.
Does the CVD policy need to offer legal safe harbour to researchers?
No, the CRA does not require an explicit safe-harbour clause. The CRA frames CVD as a structured reporting process and notes bug-bounty programmes as a way to incentivise reports; it does not codify safe harbour or legal-risk relief for researchers. The norm comes from industry practice rather than the regulation: ISO/IEC 29147, ENISA good-practice guidance, and most national CSIRT recommendations converge on a written safe-harbour clause covering good-faith research within the published scope. A policy that reserves the right to take legal action against in-scope research collapses the channel and fails the "enforce" half of the CVD-policy duty in practice.