Do I need a vulnerability disclosure policy under the Cyber Resilience Act?
Yes, and it is one of the cheapest duties in the Regulation to meet properly — which makes it one of the worst to be caught without.
Manufacturers must have a coordinated vulnerability disclosure policy in place, together with a contact address for reporting vulnerabilities [1]. Separately, the manufacturer provides a single point of contact where users can report vulnerabilities and receive information about them [2]. Both sit inside the vulnerability-handling requirements of Annex I Part II, which apply to every in-scope product regardless of class [3].
What the policy actually says
A working disclosure policy is one page answering five questions: where to send reports, what a reporter can expect and on what rough timeline, what testing you consider in and out of bounds, how you handle credit, and whether you commit not to pursue good-faith researchers. The Regulation requires the policy to exist and the contact to work [1] [2]. It does not require bug bounties, payment, or a security team — a solo developer with a monitored address and a published page meets the floor.
The contact point also appears in your user-facing information: the Annex II user information names the single point of contact for vulnerability reporting alongside your identity and the product details, so the policy page and the product documentation must agree [4].
Disclosure after the fix
The policy governs intake; a second duty governs output. After a security update is available, the manufacturer publicly discloses information about the fixed vulnerability — a description, the affected products, the impacts, severity and remediation information [5]. In practice this is a security advisories page: dated entries, affected versions, the fix version. Silence about fixed vulnerabilities stops being a permissible style [5].
And when the vulnerability is actively exploited or the incident is severe, a third duty joins: the manufacturer informs the impacted users — and where appropriate all users — without undue delay, including corrective measures they can take [6].
The common failure modes
Three patterns account for most real-world gaps. A security@ address that goes to a departed employee — the duty is a working contact, not a historical one [2]. A policy PDF nobody can find from the product — the point of the policy is that a researcher holding a vulnerability can locate it in under a minute [1]. And fixes shipped silently in release notes titled "bug fixes and improvements" — which fails the public disclosure duty however good the fix was [5].
When
These duties arrive with full application on 11 December 2027, but nothing about them rewards waiting: the policy page, the working contact and the advisories page are an afternoon of work, and researchers are already looking [7].
Check where you stand
The checker confirms which vulnerability-handling duties apply to your product, and CEMarque hosts the security page — policy, contact and advisories — as one always-current URL.
What to do next
Run your own product through the checker — it takes under a minute and gives you a dated, citable result you can send to a customer.
Sources
- Manufacturers have a coordinated vulnerability disclosure policy in place and a contact address for reporting. Annex I Part II(5)–(6) — EUR-Lex ↩
- The manufacturer provides a single point of contact for users to report vulnerabilities and to receive information about vulnerabilities. Art. 13(17), Annex I Part II(6) — EUR-Lex ↩
- Annex I Part II — vulnerability handling requirements (checklist items II.1–II.8). Annex I Part II — EUR-Lex ↩
- User information and instructions (Annex II): manufacturer identity and contact; single point of contact for vulnerability reporting; product identification; intended purpose and security environment; circumstances that may lead to significant cybersecurity risks; where fixed-vulnerability information is published; support period end date; update installation and opt-out; secure decommissioning; access to the SBOM where relevant. Annex II, Art. 13(18) — EUR-Lex ↩
- Manufacturers publicly disclose information about fixed vulnerabilities after a security update is available, including a description, affected products, impacts, severity and remediation information. Annex I Part II(4) — EUR-Lex ↩
- After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer informs impacted users, and where appropriate all users, without undue delay, including risk-mitigating and corrective measures. Art. 14(8) — EUR-Lex ↩
- The Regulation applies in full from 11 December 2027. Art. 71(2) — EUR-Lex ↩
Related
- What are the CRA rules on security updates?
Security updates must be free, timely, securely distributed and accompanied by advisories; consumer products install them automatically by default with an easy opt-out; and the duty runs for the whole declared support period.
- What goes in the CRA technical file?
A technical file in the Annex VII structure — product description, design and vulnerability-handling documentation, risk assessment, SBOM, test reports — drawn up before market placement and kept for ten years or the support period.
- What are the fines and penalties under the Cyber Resilience Act?
Fines reach EUR 15 million or 2.5% of worldwide annual turnover for breaching the essential requirements or the core manufacturer obligations, and market surveillance authorities can order withdrawal or recall.
- How long is the support period under the CRA?
You set the support period yourself, but it has a floor: it must reflect the time the product is expected to be in use, and at least five years unless the product is expected to be used for less.
CEMarque encodes Regulation (EU) 2024/2847 and the European Commission's published guidance as of 10 September 2026 (Facts v2026.09.4). It is not legal advice. Verify obligations for your product with qualified counsel where the stakes require it.