Annex I Part II point 5 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires every manufacturer to put in place and enforce a coordinated vulnerability disclosure (CVD) policy, and Article 13(17) requires a single, human-reachable 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 Article 14 reporting and the broader Annex I Part II framework.
Summary
- CVD policy is mandatory under Annex I Part II point 5: written, published, enforced, no size threshold.
- Article 13(17) requires a single point of contact for users to report vulnerabilities; 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 Article 14 reporting: CVD governs your relationship with reporters; Article 14 is the regulatory clock to ENISA and the coordinator CSIRT once a vulnerability is actively exploited.
- Public disclosure of fixed vulnerabilities is required under Annex I Part II point 4, with a narrow delay carve-out where the security risk of publication outweighs the benefit until users have had the opportunity to patch.
- Top-tier fines apply: up to €15,000,000 or 2.5% of total worldwide annual turnover under Article 64(2), whichever is higher.
The four anchors that define a CRA-compliant CVD posture: the policy mandate, the contact duty, the publication convention, and the penalty ceiling.
What the CRA actually requires for CVD
Annex I Part II point 5 is short. Verbatim from Regulation (EU) 2024/2847:
(5) put in place and enforce a policy on coordinated vulnerability disclosure;
That single sentence carries four operational components, each of which fails differently in practice:
Means a written, accessible policy exists. An undocumented internal habit of triaging security@ emails does not qualify.
Means the policy is operated, not just published. Acknowledgement timelines, triage commitments, and disclosure conditions written in the document must be honoured in practice. A policy promising 72-hour acknowledgement that routinely takes three weeks is not enforced.
Is the implied direction the policy must serve. Annex I Part II point 6 makes it explicit: manufacturers must "facilitate the sharing of information about potential vulnerabilities", "including by providing a contact address".
Not in the CRA text. Recital 76 frames CVD as a structured reporting process and notes that bug-bounty programmes may incentivise reports. Industry practice (ISO/IEC 29147, ENISA good-practice guidance) treats safe-harbour for good-faith research as a CVD-policy norm; the CRA itself does not codify it.
For the broader Annex I Part II framework (the eight numbered duties of which CVD is one), see CRA vulnerability handling.
The Single Point of Contact (Article 13(17))
Article 13(17) sits alongside Annex I Part II point 5 and gives it operational shape. Verbatim:
- For the purposes of this Regulation, manufacturers shall designate a single point of contact to enable users to communicate directly and rapidly with them, including in order to facilitate reporting on vulnerabilities of the product with digital elements.
Manufacturers shall ensure that the single point of contact is easily identifiable by the users. They shall also include the single point of contact in the information and instructions to the user set out in Annex II.
The single point of contact shall allow users to choose their preferred means of communication and shall not limit such means to automated tools.
Three rules to internalise:
- Easily identifiable. The contact must be visible in the product information, in the Annex II accompanying instructions, 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 Annex II accompanying instructions, 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 (Annex I Part II point 6) and the "not limited to automated tools" duty (Article 13(17)) 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 is the gate to Article 14), 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 Article 14 ENISA reporting are different obligations with different audiences. The CVD policy governs your relationship with the reporter. Article 14 governs your regulatory notification to ENISA and the coordinator CSIRT. They run in parallel and they trigger differently.
When a CVD report becomes an Article 14 trigger. Article 14(1) requires manufacturers to notify "any actively exploited vulnerability" via the SRP. Article 14(2) sets the cadence: 24-hour early warning, 72-hour notification, and a final report within 14 days of a corrective measure becoming available. The trigger is "actively exploited", not "reported". A CVD intake with a working proof-of-concept is not by itself an Article 14 trigger; it becomes one when there is reasonable belief that a malicious actor has used the flaw against a real target. For severe incidents under Article 14(3) and 14(4), the cadence is 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 CRA Article 14 reporting.
ENISA and CSIRTs designated as coordinators. Article 14(7) requires submission via the SRP using the electronic end-point of the CSIRT designated as coordinator in the Member State of the manufacturer's main establishment. Recital 76 anchors the broader framing: manufacturers may receive reports directly, or indirectly via a CSIRT designated as coordinator under Article 12(1) of Directive (EU) 2022/2555 (NIS2). 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. Annex I Part II point 4 requires manufacturers, "once a security update has been made available", to "share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities". The same point allows a delay "in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security 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 Article 14(2)(c) requires a final report 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 in point 4 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 point 4 regardless of intent.
Common pitfalls
| Pitfall | Why it fails the CRA |
|---|---|
| Legal threats against good-faith researchers | Breaks "enforce a policy on coordinated vulnerability disclosure" (Annex I Part II point 5) and chills the intake channel point 6 requires. |
| No public contact channel, only an internal portal login | Fails Article 13(17) "easily identifiable" and Annex I Part II point 6 "providing a contact address". |
security-noreply@ autoresponder with no human triage |
Article 13(17) bars limiting communication to automated tools. |
| Acknowledging receipt and never responding again | The policy is "in place" but not "enforced". Annex I Part II point 5 requires both. |
| 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 | Breaches Annex I Part II point 2: security updates must be separable from functionality updates "where technically feasible". |
| Silently patching with no advisory | Breaches Annex I Part II point 4 public-disclosure duty. |
| Treating CVD intake as the Article 14 ENISA submission | Different audiences, different obligations. CVD does not relieve Article 14, and Article 14 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 Article 14 early-warning deadlines under Article 64(10)(a), which covers both Article 14(2)(a) for actively exploited vulnerabilities and Article 14(4)(a) for severe incidents. 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. (Annex I Part II point 5; Article 64(10)(a); Article 3(19).)
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 Annex II instructions is also compliant. The hard requirement is a published, working, human-reachable channel; the format is a choice. (Article 13(17); Annex I Part II point 6; RFC 9116.)
Can the CVD intake be the same channel as the ENISA Article 14 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 Article 14 submission is the manufacturer's regulatory notification to ENISA and the coordinator CSIRT, made through the ENISA 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 (top-tier fine exposure). (Article 14(1) and 14(7); Article 16; Article 64(2).)
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 Article 14 process governs the regulator relationship: a 24-hour early warning to ENISA and the coordinator CSIRT, 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. (Article 14(1) and 14(2); Annex I Part II point 5.)
Does the CVD policy need to offer legal safe harbour to researchers?
No, the CRA does not require an explicit safe-harbour clause. Recital 76 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 Annex I Part II point 5 in practice. (Recital 76; ISO/IEC 29147; ENISA CVD good-practice guidance.)