What the Cyber Resilience Act asks of vulnerability handling

The EU Cyber Resilience Act expects manufacturers of products with digital elements to handle vulnerabilities continuously, not just at release time. Article 13 is the operational core of this expectation, and it is unambiguous: vulnerabilities must be identified, addressed, and documented across the entire support period of the product.

For SaaS and software vendor teams, that translates into needing four things in place: a current inventory of components, continuous re-checking against new vulnerabilities, ownership and triage history, and audit-ready evidence on demand. This article walks through what the regulation actually asks for and what a workable response looks like.

This article is a practical summary, not legal advice. For obligations specific to your products and markets, consult qualified counsel.

What does Article 13 actually ask for?

Article 13 is the part of the CRA most teams will operationalize. The relevant expectations, in plain language:

• Identify and document vulnerabilities and components. This is the SBOM requirement. You need a record of what is in each release.
• Address vulnerabilities without delay during the support period. This is the continuous handling requirement. It is not enough to scan at release time; you need to keep monitoring.
• Apply security updates throughout the support period. This is the patch obligation. You need to be able to ship fixes for releases you have already shipped.
• Have a coordinated vulnerability disclosure policy. This is the process obligation. Triage decisions, contact paths, and timelines need to exist as documented practice.
• Keep records sufficient to demonstrate compliance. This is the evidence requirement. When asked, you need to be able to produce the history.

Article 14 then layers on reporting: actively exploited vulnerabilities and severe incidents must be reported to the relevant authority within tight timelines (24 hours for an early warning, 72 hours for a notification, one month for a final report — exact wording to consult the regulation).

The two articles together effectively define a workflow: detect, triage, fix, document, report.

How does this differ from periodic scanning?

Periodic scanning satisfies neither the “without delay” obligation in Article 13 nor the tight reporting timelines in Article 14. The clock for both starts when a vulnerability becomes known publicly, not when your next scheduled scan happens to run.

In practice that means:

• You need detection that is closer to “as new advisories are published” than to “weekly cron job.”
• You need the chain from new advisory to affected release to responsible team to be short enough that triage can start within hours, not days.
• You need a written record of when you detected it, what you decided to do, and when the decision was acted on.

A monitoring layer that re-evaluates existing SBOMs against fresh vulnerability data continuously, then routes findings to owners, is essentially the operational shape Article 13 expects.

What does an audit-ready workflow look like?

If an EU regulator asked you to demonstrate compliance with Article 13 for a specific product, you would need to be able to produce, on demand:

1. The SBOM of every release in scope during the audit period.
2. The vulnerability findings against each of those releases, including ones that were closed.
3. The triage decisions for each finding: was it exploitable, was a fix applied, was it accepted as not relevant, with the reasoning.
4. The activity history: who took which decision, when.
5. The point-in-time view of what was deployed, so that “as of last March” questions are answerable.

That list is the working definition of an audit-ready workflow. Quaze produces this as scheduled evidence packs; other tools have similar capabilities. The format matters less than the fact that the workflow generates the evidence as a by-product of doing the work, rather than requiring a sprint to reconstruct it later.

A worked example

A new high-severity CVE is published against a component used in a SaaS product that ships into the EU.

A workflow aligned with Article 13 would:

• Detect the new advisory and match it against existing SBOMs within hours.
• Identify that release 2.4.1, currently deployed in production-eu, references the affected component.
• Route the finding to the platform team that owns the component.
• Capture the triage decision (applying upstream patch, planned for hotfix release 2.4.2).
• Log the action: who decided what, when, and the underlying reasoning.
• Surface the patched version in the next scheduled evidence pack.

If Article 14 applies (the vulnerability is actively exploited or causes a severe incident), the same data feeds the early-warning notification.

What to do this quarter

If you are reading this in the run-up to September 2026 (when CRA reporting obligations begin), a small set of changes covers most of the operational gap:

• Make SBOMs a release artifact. Every release, every product, in CycloneDX or SPDX.
• Stand up a continuous monitoring layer. It does not need to be perfect; it needs to re-check those SBOMs as new CVEs are published.
• Wire ownership. Components need owners; findings need a route.
• Capture decisions as you go. Triage notes that get written down once during the response are infinitely cheaper than ones reconstructed during an audit.
• Schedule evidence packs. Monthly or quarterly, depending on your support period.

None of these are exotic. The CRA does not require new technology. It requires that the operational shape of vulnerability handling actually happens, and that the evidence exists when asked.

The shorter version: the CRA does not ask you to do something nobody is doing. It asks you to do continuously what many teams currently do only at release time.