The CRA vulnerability handling requirements
Short answer. Annex I Part II is eight process obligations, and unlike Part I they carry no risk-assessment qualifier and no “where applicable”. All eight apply to every manufacturer.
They begin when you place the product on the market and run for the whole support period — at least five years, under Article 13(8).
Part I of Annex I is something a product can be. Part II is something a company has to do, every week, for years. Of the two lists, this is the one that changes how a business runs, and it is the one that quietly rules out some business models.
The eight requirements
Part II opens “Manufacturers of products with digital elements shall”, then lists eight numbered items.
| The requirement | What it means in practice | |
|---|---|---|
| 1 | Identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies | An SBOM is required, its floor is top-level dependencies, and it must be machine-readable. See the SBOM requirements |
| 2 | Address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, provided separately from functionality updates | No fixed deadline, but “without delay” is a standard you have to be able to evidence |
| 3 | Apply effective and regular tests and reviews of the security of the product | Both words are load-bearing. Ad hoc testing is not regular; a scan nobody acts on is not effective |
| 4 | Once a security update is available, share and publicly disclose information about fixed vulnerabilities — description, affected-product identification, impacts, severity, remediation guidance | A public advisory, not a changelog line. With a limited right to delay in duly justified cases |
| 5 | Put in place and enforce a policy on coordinated vulnerability disclosure | Two verbs. A published policy nobody follows fails on the second. See writing the policy |
| 6 | Facilitate information sharing about potential vulnerabilities in your product and in third-party components it contains, including by providing a contact address for reports | A monitored address, and it extends to components you did not write |
| 7 | Provide mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically | Signed, authenticated delivery. The automatic limb ties back to Part I (c) |
| 8 | Where security updates are available, disseminate them without delay and free of charge, with advisory messages telling users what to do | The requirement with the most commercial consequence. See below |
Why there is no “where applicable” here
This is the structural point that a flat twenty-one-item checklist hides. Part I point 2 is introduced by “On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable”. Part II has no such opening. It says manufacturers shall, and then lists the eight.
So the argument that is available to you on Part I — that a given requirement is not relevant to your product, reasoned and documented — is not available on Part II. There is no product for which a coordinated vulnerability disclosure policy is inapplicable, and no product for which regular security testing is beside the point.
Article 13(8) then attaches these obligations to a period rather than to a moment:
Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I.
Note “including its components”. Vulnerabilities in dependencies are your vulnerabilities for the whole support period, which is a number you choose and then live with.
Point 8: free of charge, and what that rules out
The exact wording is worth having in front of you:
… ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken.
Three things follow, and the first one has teeth.
- Security updates are free. The single exception is narrow on two axes at once: it needs a business user and a tailor-made product, and agreement between them. A consumer product cannot use it, and neither can an off-the-shelf commercial product sold to businesses.
- A support contract cannot be the only route to a security fix. If your paid tier is what gets a customer the patch, point 8 is the requirement to read closely. Charging for functionality updates, for new versions, for professional services or for a support SLA is untouched — what cannot be gated is the security update itself.
- Advisory messages are part of the requirement, not a courtesy. Shipping a silent patch satisfies the dissemination limb and fails the advisory limb.
This is the clearest example in the regulation of a compliance requirement that reaches into pricing. It is worth resolving deliberately and early, because the alternative is discovering it during a conformity assessment after the pricing page has been live for two years.
Point 2: separating security from features
Point 2 asks for remediation without delay, and adds: “where technically feasible, new security updates shall be provided separately from functionality updates”.
The qualifier is real — some architectures genuinely cannot ship a fix without shipping the branch it sits on. But “technically feasible” is about the technology, not about the release process you happen to have. A customer being told they must accept a redesigned interface in order to receive a security fix is exactly the outcome this requirement exists to prevent.
If your answer is that separation is infeasible, write down why, in the technical documentation, in terms an engineer at an authority would accept. That is a much better position than having no answer, and it is the same discipline the rest of the technical file demands.
Point 4: publishing what you fixed
Point 4 requires that once a security update has been made available, you share and publicly disclose information about the fixed vulnerabilities, including a description, information allowing users to identify the affected product, the impacts, their severity, and clear and accessible information helping users remediate.
That is an advisory with five components. A line in a changelog saying “security fixes” has none of them.
There is a carve-out, and it is narrower than it is usually quoted as being: in duly justified cases, where the manufacturer considers the security risks of publication to outweigh the security benefits, publication may be delayed until after users have been given the possibility to apply the relevant patch. So it is a delay, tied to patch availability — not a discretion to stay quiet.
What the evidence looks like
Part II is about processes, and processes are proved by records. For each of the eight, ask what you would put in front of an authority.
| Requirement | The evidence |
|---|---|
| 1 — SBOM and vulnerability identification | An SBOM per release, retained, in CycloneDX or SPDX; a record of how you monitor components for new vulnerabilities |
| 2 — remediation without delay | Dated triage and fix records per vulnerability, and your own stated targets to compare them against |
| 3 — regular tests and reviews | The testing regime described, plus dated evidence that it ran — scan output, review notes, pen-test reports |
| 4 — public disclosure | The published advisories themselves, each with the five prescribed components |
| 5 — disclosure policy | The published policy, its version history, and evidence of reports handled under it |
| 6 — information sharing | The contact address, and that it demonstrably receives and answers reports |
| 7 — secure distribution | How updates are signed and verified; how automatic updates are delivered where applicable |
| 8 — free dissemination with advisories | That every security update reached every user without a paywall, and the advisory that accompanied it |
Two of these are the ones that fail in practice, and neither fails because of a technical shortcoming. Requirement 3 fails because the testing was real but nobody kept dated evidence of it. Requirement 6 fails because the address exists on a page and nobody watches the inbox.
How this connects to the reporting duties
Annex I Part II and Article 14 are separate obligations that people merge. Part II is your standing process. Article 14 is what you do within 24 hours when a vulnerability in your product is being actively exploited, or a severe incident happens — and it has applied since 11 September 2026, whereas Annex I applies from 11 December 2027.
That gap runs the wrong way round from most people's intuition: the emergency duty landed first. Worse, under Article 69(3) the Article 14 obligations reach products placed on the market before 11 December 2027 — so your existing fleet is inside the reporting regime now and outside Annex I until it is substantially modified.
The practical link between the two is point 6 of Part II. The contact address you provide is how a researcher tells you about a vulnerability, and being told is very likely the moment you “become aware” — which is the event that starts the 24-hour clock. An unmonitored inbox is therefore not only a Part II failure; it is the most likely way to miss a reporting deadline you never knew had started.
An honest note on our own confidence. The wording of the eight requirements, and of Article 13(8), we have read directly in the Official Journal. The consequences we draw — that point 8 is incompatible with gating security patches behind a paid tier, that “technically feasible” in point 2 will not cover an inconvenient release process, and that a report to your point 6 address starts the Article 14 clock — are our reading. No authority has stated them in those terms, and on the last one in particular we have found no source that joins the two provisions explicitly. Treat it as a risk worth managing rather than as settled law. Nothing here is legal advice.
The eight requirements, with the evidence attached
A disclosure policy and a reporting readiness pack generated from your answers, an SBOM validated against the accepted formats, and every version of every document kept and dated for the full ten years — with a one-button export, unconditionally.
Start with the free check: does the regulation apply to your product?