What the Cyber Resilience Act Changes for Software Vulnerability Management

The CRA is not a tooling question

If you have an EU-facing product and your first reaction to the Cyber Resilience Act was “which scanner do we need?”, you started in the wrong place. I’ve watched teams burn weeks evaluating SCASoftware Composition AnalysisA category of tools that identifies open-source components in a codebase and flags known vulnerabilities associated with them. tools while nobody had answered the more basic question: is the product in scope, who owns the vulnerability process, and can you produce evidence that the process actually works?

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRACyber Resilience ActEuropean Union legislation establishing cybersecurity requirements for products with digital elements.), sets horizontal cybersecurity requirements for products with digital elements. Its legal effect depends on product scope, role, classification, exemptions, and incident circumstances. This is an operational readiness guide, not legal advice.

I think the CRA’s real impact is organizational, not technical. It turns vulnerability management from a security-team activity into a product-level obligation. That shift changes who owns what, how fast decisions need to happen, and what evidence you need behind each one. A vulnerability that sat in a backlog for a quarter because “it’s not exploitable” now needs a documented rationale, an owner, and a reassessment trigger.

What changes when vulnerability handling becomes a product obligation

The CRA includes cybersecurity requirements for the vulnerability-handling processes manufacturers put in place while products are expected to be in use. The Regulation also addresses economic-operator obligations. The exact application depends on your product and your role, but the engineering consequence is straightforward: your vulnerability process needs to be demonstrable, not just described in a policy document.

For a product in scope, you should be able to locate evidence behind these questions:

• Who owns intake, assessment, remediation, and customer communication for a reported vulnerability?
• How do you identify the product, version, and components that a report concerns?
• What shows that a corrective or mitigating measure was selected, released, and communicated?
• How are vulnerability reports received and coordinated?
• Which support-period assumptions govern when a decision must be revisited?

If you need to open a wiki, search Slack, or ask three people to answer any of those, you have a gap. The CRA did not create that gap. It made the gap visible.

The official Regulation text has the detail. The Act does not turn every CVECommon Vulnerabilities and ExposuresA standardized identifier for a publicly disclosed cybersecurity vulnerability. into the same response, and no single security tool provides a complete answer.

Build an evidence record, not just an inventory

Recital 77 explains that manufacturers should identify and document product components, including by drawing up an SBOMSoftware Bill of MaterialsA machine-readable inventory of the components and dependencies included in a software product., to facilitate vulnerability analysis. An SBOM is useful evidence in a larger process: it helps correlate an advisory to a declared component and version.

But an SBOM alone does not demonstrate current deployment, reachability, exploitability, remedy, or legal compliance. You need to pair inventory with evidence that explains what is actually running and how you decided to respond:

• Advisory and vulnerability identifier, source, and date
• Product, version, component, and SBOM coverage boundary
• Build artifact and deployment observations
• Assessment rationale, owner, decision date, and reassessment trigger
• Remediation record, verification, and disclosure or reporting where applicable

What matters is that every step has an owner and produces a record that outlasts the person who made the call. Building a DevSecOps Evidence Chain walks through how to assemble this record for a single finding. This is consistent with the evidence-to-decision model from From SBOM to Actionable Signal, but the record itself is a local design choice. The CRA does not prescribe these fields, this sequence, or a review cadence.

Reporting readiness is not vulnerability triage

This distinction matters. The Commission states that CRA reporting obligations apply from 11 September 2026, while the Act’s main obligations apply from 11 December 2027. The Commission reporting page describes staged notifications for actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of awareness, a notification within 72 hours, and a final report under the conditions and timeframes stated in Article 14.

Article 14 and your product’s facts determine whether a notification duty applies and when the clock starts. This is not a “report every CVE” rule. In my experience, the organization that struggles with this is not the one missing a scanner. It is the one where nobody has tested the handoff between security triage, product ownership, incident response, legal/compliance, and the reporting channel. Responding to a Critical CVE provides a checklist for rehearsing that handoff. The 24-hour early warning, in particular, demands a process that has been rehearsed. Drafting a notification template during an active incident is not a plan.

Run that test before a time-sensitive case forces it.

The Commission’s implementation timeline and guidance can change. Recheck them before acting on any deadline.

A product readiness record

Pick one EU-facing product and use it as a rehearsal.

Field	Example
Product and assumption	Gateway 4.2; offered to EU customers; scope and operator role require legal confirmation
Security owner	Product security lead
Vulnerability evidence	Advisory intake record, component inventory boundary, service/artifact mapping, decision log
Handling evidence	Triage owner, remediation release record, verification observation, customer-advisory owner
Reporting readiness	Escalation contact, Article 14 applicability question, time-stamped decision log, channel test owner
Open questions	Classification, support-period interpretation, reporting trigger, applicable conformity route
Review date	Set by the named accountable lead with legal/compliance input

The result is modest: it tells you where the product assumptions sit, who owns each piece of evidence, which legal questions remain open, and what happens next. It is not a declaration of conformity. But if you cannot produce this for a single product today, you are not ready for the September 2026 reporting deadline, let alone the December 2027 full obligations.

Questions that need qualified review

Do not resolve these from a generic article or a scanner result:

• Whether your product with digital elements is in scope or excluded
• Who is the manufacturer, importer, distributor, or another economic operator
• Classification as important or critical, and the applicable conformity route
• The meaning of a support period for your product and its updates
• Whether an event meets the legal reporting threshold, and any enforcement, penalties, or certification conclusions

These are not edge cases. They are the questions that determine whether your readiness record means anything.

The Commission’s CRA summary and current implementation material are useful starting points. For a decision about a specific product, retain the current source version and involve qualified legal and compliance owners.

What to do this week

Pick one EU-facing product. Run a scoped readiness review: record the scope assumptions, evidence gaps, owners, escalation path, and a review date. If someone else on your team cannot reconstruct the process from your record alone, the record is not done. Do this before treating the CRA as a documentation exercise you can backfill later.