The CRA Vulnerability-Handling Process: What ‘Free Security Updates for the Support Period’ Forces You to Build

The Cyber Resilience Act’s vulnerability-handling requirements read like a policy statement. They are a build spec — for a pipeline that has to keep running for years after a product ships.

Most of the CRA readiness work I see treats Annex I, Part II as something to write down. A team drafts a vulnerability-handling policy, gets it signed, files it against the technical documentation, and moves on. That satisfies an auditor reading a binder. It does not satisfy the regulation, because Part II does not describe a document — it describes a set of capabilities that have to operate continuously across every product you have placed on the market, for as long as you have committed to support it. The phrase everyone underweights is “free of charge, across the support period.” That is not a compliance clause. It is a multi-year operational liability you are choosing to take on at the moment you ship.

The obligation is a pipeline, not a paragraph

Regulation (EU) 2024/2847 entered into force in December 2024. The vulnerability and incident reporting duties under Article 14 apply from 11 September 2026; the main obligations, including the essential requirements in Annex I, apply from 11 December 2027. Annex I, Part II sets out what “handling vulnerabilities effectively” actually means, and read as an engineer rather than a lawyer, it is a flow. You identify and document vulnerabilities in the product and its components. You address them without delay, including by issuing security updates. You test. Once a fix is out, you disclose information about the vulnerability. You run a coordinated disclosure policy, distribute updates through a secure mechanism, and disseminate those updates without delay and free of charge.

Every verb in that list is a system that has to exist, take inputs, produce outputs and leave evidence. Treat it as prose and you will discover, some months after a researcher emails you, that you have no intake queue, no severity rubric, no way to back-port a patch to the version a customer actually deployed, and a reporting clock already running against you.

Intake: two sources you do not control

Vulnerabilities reach you through two channels, and the CRA obliges you to be ready for both. The first is external: a security researcher, a customer, a national CSIRT. Article 13 requires a coordinated vulnerability disclosure policy and a single point of contact through which people can report to you directly. That contact has to be published, monitored, and wired to a triage process — not a shared inbox someone checks between other duties. The second channel is your own monitoring. You cannot report on components you cannot see, which is why the software bill of materials stops being a nice-to-have and becomes intake infrastructure: it is the list you match new CVEs against every day. If your SBOM is a spreadsheet generated once at release, it is already wrong. It has to be produced and refreshed by the build, which is the argument for treating living SBOMs as a pipeline output rather than a release artefact.

Most of what you monitor will be other people’s code. The manufacturer duty does not stop at your own source, so the vulnerabilities you inherit from third-party and open-source dependencies are yours to handle — which is the same reason the CRA pushes secure-by-design obligations down the chain, a point worth reading alongside due diligence on your suppliers.

Triage runs against a reporting clock, not an internal SLA

Once something is in the queue, you assess it — severity, exploitability, affected versions, whether it is being exploited in the wild. This is ordinary security engineering with one difference: the clock is statutory, not one you negotiated. Article 14 requires that when you become aware of an actively exploited vulnerability, you notify the CSIRT designated as coordinator and ENISA, through the CRA single reporting platform, on a fixed schedule: an early warning without undue delay and within 24 hours, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. Severe incidents affecting product security carry a parallel set of deadlines.

The design consequence is blunt. Your triage step has to reliably answer, fast, one question that starts the 24-hour timer: is this being actively exploited? If that determination depends on a person happening to read a report, you will miss the window. The classification has to be an explicit, evidenced gate in the process, and the evidence has to land in the same place you assemble the rest of your technical file, because a market surveillance authority will later ask you to show that the process ran, not merely that it existed on paper.

Delivery is where the support period gets expensive

Developing a fix is the part every team already knows how to do. Getting it onto fielded products, for years, free of charge, is the part that reshapes your architecture. Article 13 requires you to set a support period reflecting how long the product is reasonably expected to be in use — at least five years unless the expected use is genuinely shorter — and to state its end date, at least the month and year, at the point of sale. Security updates you issue during that period must then remain available for a further ten years, or the remainder of the support period, whichever is longer. Annex I requires a secure distribution mechanism and, where applicable, automatic updates.

Say those numbers out loud against your release model. If you ship a new major version every year and support each for five, you are maintaining and patching five concurrent lines at any moment. Every fix has to be assessed for, and potentially back-ported to, each supported branch — with signing, an authenticated update channel, and a rollback story so a security patch does not itself brick a device or break a deployment. For connected products this is firmware and an over-the-air path; for a hosted backend it is your live estate, which is why the support-period commitment lands differently when your product is SaaS or remote data processing and there is no “customer’s device” to reason about at all.

Size the commitment before you make it

The single most consequential CRA decision is not written in your policy — it is the support period you print at the point of sale, because it silently fixes how many product lines your engineering function will be patching, in parallel, for the next several years. Choose it by counting the concurrent branches it implies and the back-porting load each new vulnerability will generate, then decide whether your release cadence and your team can carry that number. Firms that set the period first and discover the operational cost later end up doing the one thing the regulation is built to prevent: quietly narrowing what they actually patch. The obligation is not to write that you will handle vulnerabilities. It is to still be able to, on the day someone finds one in a product you shipped four years ago.