CRA Vulnerability Management: Requirements, Deadlines & Tools

TL;DR: CRA vulnerability management is the continuous work of finding, reporting, and fixing vulnerabilities in connected products throughout their supported life. The EU Cyber Resilience Act makes it mandatory. Reporting obligations start on 11 September 2026, and full compliance is due 11 December 2027. You can't report a vulnerability in 24 hours if you don't already know what's inside your product, so ground-truth software inventory comes first, not last.

Most guidance treats CRA vulnerability management as a legal and reporting exercise you prepare for. That framing misses the hard part. The reporting clock, the patch obligations, and the audit evidence all depend on one thing: knowing exactly what shipped inside your product. Get that wrong, and every downstream obligation breaks.

This page walks through what the CRA actually requires for vulnerability handling and long-term security updates, when each obligation kicks in, and how to build a program that holds up under a real deadline instead of a last-minute scramble.

What is CRA vulnerability management?

CRA vulnerability management is the ongoing work of finding, reporting, and fixing product vulnerabilities, as the EU Cyber Resilience Act requires across a connected product's supported lifecycle.

It applies to "products with digital elements," a broad category that covers software and any hardware that connects to a device or network. That includes IoT devices, embedded systems, and operational technology. The requirement follows the product wherever it's sold in the EU, no matter where it was built. So a manufacturer in the US or Asia selling into Europe carries the same obligations as one in Berlin.

The CRA splits vulnerability management into two connected duties. First, handle vulnerabilities in the product itself: find them, fix them without delay, and ship security updates. Second, report the serious ones to regulators on a fixed clock. Both duties run for the life of the product, not just at launch. For the wider picture, see the EU Cyber Resilience Act explained.

What are the CRA requirements for vulnerability handling and long-term security updates?

The CRA requires manufacturers to ship products with no known exploitable vulnerabilities, fix new ones without undue delay through free security updates, and support each product for at least five years.

These duties live in Annex I, Part II of the regulation. In plain terms, they break down like this:

• No known exploitable vulnerabilities at release. You can't knowingly ship a product with an exploitable hole in it.
• Fix without delay. When a vulnerability is found, you address it through a security update and disclose it once the fix is available.
• Free, timely security updates. Updates that fix security issues must be provided to users at no cost and, where feasible, separately from feature updates.
• A defined support period. The support period must reflect how long users can reasonably expect to use the product, with a floor of five years unless the product's expected use is shorter. Security updates must remain available to users for at least ten years, or for the support period if that's longer. [verify before publishing: confirm the exact update-availability duration against the final Annex I / Article text, as this figure shifted during negotiation.]
• A vulnerability handling process. You need a documented, repeatable process for identifying, documenting, and remediating vulnerabilities, including those in third-party and open source components.

That last point is where most programs quietly fail. A modern connected product is mostly software you didn't write. If you can't see the open source and third-party components inside your firmware, you can't know whether a newly disclosed vulnerability affects you. Building that visibility is the foundation, which is why the CRA also ties vulnerability handling to an SBOM. See our guide to the SBOM and technical documentation requirements under the CRA for how that fits together.

When do CRA vulnerability management obligations start?

The CRA entered into force on 10 December 2024. Vulnerability and incident reporting obligations apply from 11 September 2026, and full compliance is required by 11 December 2027.

The reporting date is the one to circle. It arrives more than a year before full compliance, and it applies to products already on the EU market, including legacy products you shipped years ago. So "we'll handle the CRA when we build our next release" is not a plan. If a product you sold in 2023 is still on the market and has an actively exploited vulnerability in September 2026, you have to report it.

Here are the dates that matter for vulnerability management:

• 10 December 2024: CRA entered into force. The transition clocks started.
• 11 June 2026: Rules for notifying conformity assessment bodies begin to apply.
• 11 September 2026: Vulnerability and incident reporting obligations (Article 14) apply, including for legacy products already on the market.
• 11 December 2027: Full application. Conformity assessment, CE marking, and the complete set of essential requirements are due.

If you're mapping these deadlines to concrete steps, a CRA readiness assessment is a practical way to find the gaps before the reporting clock starts.

What are the CRA vulnerability reporting deadlines?

Under CRA vulnerability reporting rules, manufacturers must submit an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a fix being available.

Reporting is triggered by two things: an actively exploited vulnerability, or a severe incident affecting the security of your product. The clock starts the moment you become aware. You report through a single channel, the EU Single Reporting Platform operated by ENISA, addressed to the national CSIRT where you have your main establishment.

Twenty-four hours is not much time to decide whether a report is required, scope the affected products, and draft an accurate notice. That's the operational squeeze the CRA creates, and it's why reporting has to be wired into an existing process rather than assembled on the day. For the response side of this workflow, see how a PSIRT handles rapid vulnerability response.

One note for smaller manufacturers: microenterprises and small enterprises may not be fined specifically for missing the 24-hour deadline, though the underlying obligation still stands. [verify before publishing against the final Article 64 penalty provisions.]

How does CRA vulnerability reporting and incident response automation work?

CRA vulnerability reporting and incident response automation connects continuous product monitoring to your reporting workflow, so a new exploited vulnerability triggers assessment, evidence, and a draft notification automatically.

The 24-hour clock is the reason automation matters here. Manual triage across a large product portfolio doesn't move fast enough. A workable automated flow looks like this:

1. Monitor continuously. New vulnerabilities are matched against a live inventory of what's actually in each product, including third-party and open source components.
2. Assess exploitability fast. The system flags whether a vulnerability is reachable and exploitable in a specific product, so you know within hours whether it crosses the reporting threshold.
3. Assemble the evidence. Affected products, versions, component details, and mitigation status are pulled together automatically.
4. Draft the notification. The 24-hour early warning and 72-hour notification are pre-populated from that evidence, ready for a human to review and submit.

The point isn't to remove people from the loop. It's to make sure that when the clock starts, your team is reviewing a draft instead of starting from a blank page. Prioritization is central to this, because reporting only applies to vulnerabilities that are actually exploited or exploitable. Our approach to reachability analysis for CRA vulnerability prioritization explains how to cut the noise down to what genuinely matters.

What are the Cyber Resilience Act vulnerability assessment requirements?

Cyber Resilience Act vulnerability assessment requirements call for a documented, risk-based process to identify, evaluate, and remediate vulnerabilities, backed by an SBOM and a coordinated vulnerability disclosure policy.

Under Annex I, the assessment side of the CRA has a few concrete parts:

• An SBOM covering at least the top-level dependencies. Regulators can request it. You don't have to publish it, but you do have to maintain it.
• A coordinated vulnerability disclosure (CVD) policy. You need a clear channel for third parties to report vulnerabilities, plus a single point of contact. Widely used standards like ISO/IEC 29147 (disclosure) and ISO/IEC 30111 (handling) give you a proven starting structure.
• Upstream notification. When you find a vulnerability in a third-party or open source component, you have to notify whoever maintains that component.
• Public disclosure once a fix exists. After a security update is available, the vulnerability is disclosed, including relevant details users need.

Doing this well means your assessment is grounded in what actually ships, not in a spreadsheet of components you think are in the build. Binary-level analysis of the shipped firmware is how you close the gap between the bill of materials on paper and the software running on the device. For the certification angle, see the CRA conformity assessment requirements.

How is CRA vulnerability management different from traditional compliance programs?

CRA vulnerability management is continuous and product-specific, tied to what actually ships. Traditional compliance programs are periodic and policy-based, tied to audits and point-in-time checklists.

This is the shift that catches teams off guard. A traditional compliance program is built around an audit calendar: you prepare, you pass, you move on until next year. The CRA doesn't work that way. Vulnerabilities appear on their own schedule, the reporting clock can start any day, and the obligation follows the product for its whole life. Compliance becomes a property of the product, not an annual event.

The practical takeaway: a program designed to pass an annual audit will not survive a 24-hour reporting obligation on a product you shipped three years ago. You need continuous inventory, continuous assessment, and evidence that's ready before anyone asks. Getting there is easier when security by design is built into the CRA workflow from the start rather than retrofitted.

What should you look for in CRA vulnerability management software tools in 2026?

The right CRA vulnerability management software tools in 2026 build a ground-truth SBOM from the shipped binary, prioritize by real exploitability, and generate audit-ready reporting evidence automatically.

Category names vary, but the capabilities that map directly to CRA obligations are consistent. When you evaluate tools, check for these:

• Binary and firmware analysis, not just source scanning. The CRA cares about what shipped. Source-only tools miss components introduced during the build and can't see what's actually in the device. Binary analysis gives you the real inventory.
• A living SBOM as a system of record. Not a one-time export, but an inventory that updates as products and components change, and that you can hand to a market surveillance authority on request.
• Exploitability-based prioritization. Reachability and exploit context so you spend the 24-hour window on vulnerabilities that are genuinely exploitable, not a wall of theoretical findings.
• Reporting and incident response automation. Pre-populated early warning and notification drafts pulled from your evidence, tied to the SRP workflow.
• Continuous, audit-ready evidence. Traceable proof mapped to CRA requirements, generated as you work rather than reconstructed before an audit.
• Coverage for legacy products. The reporting obligation covers products already on the market, so the tool has to handle products you're no longer actively developing.

No single tool removes the obligation, and any vendor claiming a one-click CRA button is overselling. What good tooling does is make continuous compliance sustainable at portfolio scale. When you're ready to map these capabilities to your own products, prepare for the EU Cyber Resilience Act with a structured plan, and see how Finite State supports CRA compliance end to end.

How do you prepare for CRA vulnerability management before September 2026?

Start by inventorying every in-scope product, including legacy ones, then build ground-truth SBOMs, stand up a reporting process, and wire prioritization and evidence into your release workflow.

A practical sequence:

1. Build a product inventory. List every product you sell, import, or distribute in the EU that could qualify, including legacy versions still on the market and products with third-party components. Identify which legal entity is the manufacturer for each.
2. Generate ground-truth SBOMs. Analyze the shipped binaries and firmware so your component inventory reflects reality, not assumptions.
3. Stand up the reporting process now. Determine your main establishment and national CSIRT, register for the ENISA Single Reporting Platform when it opens, and rehearse the 24 / 72 / 14 workflow before you need it.
4. Set up coordinated vulnerability disclosure. Publish a policy and a single point of contact, aligned to ISO/IEC 29147 and ISO/IEC 30111.
5. Prioritize by exploitability. Put reachability and exploit context in place so triage is fast and defensible under the clock.
6. Make evidence continuous. Generate audit-ready documentation as part of the workflow, so it's there for both the 2026 reporting duty and the 2027 conformity assessment.

Design, verify, prove. That's the shape of a program that lasts. The manufacturers who treat the September 2026 date as the real deadline, not December 2027, are the ones who won't be scrambling.