Vulnerability handling and disclosure under the CRA

Vulnerability handling is a running process

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, treats vulnerability handling as an operational obligation that runs across a product's supported lifetime — not a box ticked at conformity assessment. A manufacturer must identify vulnerabilities, remediate them, disclose them in a coordinated way, and report the serious ones to authorities on a clock. This is closer to running a security operations function than to writing a document.

Two things make it demanding. First, it never stops: the duty persists for as long as the product is supported. Second, part of it is time-bound: the reporting obligations apply from 11 September 2026, ahead of the main body of CRA obligations. The dates are laid out in the EU CRA timeline; this piece is about the process behind them.

The four moving parts

Element	What the CRA expects	What it means in practice
Vulnerability identification	Know the components; find the flaws	An SBOM queried against vulnerability feeds
Remediation	Fix without undue delay across supported life	A patch pipeline, including OTA where used
Coordinated disclosure	A published policy and contact point	A route for researchers to report; coordinated release
Reporting	Notify authorities of exploited vulnerabilities and severe incidents	A rehearsed detect-to-notify capability on a clock

Each depends on the one above it. You cannot remediate what you have not identified; you cannot report coherently without a disclosure process behind it. The chain starts with knowing your components, which is why the SBOM is the foundation of the whole obligation.

Identification: the SBOM does the work

When a vulnerability is published, the first question is which of your products contain the affected component and version. If you can answer that in minutes by querying an SBOM, triage is fast enough to meet the reporting windows. If you answer it by asking engineers to check, you will miss the clock. Vulnerability identification under the CRA is therefore an SBOM-driven process: the inventory turns each new advisory into a targeted query rather than a manual hunt.

Coordinated disclosure: a published route

The CRA requires a coordinated vulnerability disclosure policy. In substance that means a published contact point where researchers and others can report a vulnerability, an internal process to triage and remediate what comes in, and a coordinated approach to disclosing the vulnerability once a fix is available. The point is predictability: a researcher who finds a flaw should know exactly how to report it and what will happen next, and the manufacturer should not be improvising when a report lands.

For automotive this connects to the wider security community. Vehicle vulnerabilities are often first surfaced by researchers, and a manufacturer without a disclosure route forces those findings into public channels or into silence — neither of which serves anyone. A published policy turns adversarial disclosure into coordinated disclosure.

Reporting: the clock that bites first

The reporting duty is the hardest near-term obligation because it is time-bound and operational. From 11 September 2026, manufacturers must notify authorities of actively exploited vulnerabilities and severe incidents within defined, staged windows. Meeting those windows requires a capability that is live, staffed and rehearsed:

• Detection — you have to know an exploitation or severe incident is happening.
• Triage — you have to assess severity and confirm scope, fast.
• Decision — someone with authority must decide to notify.
• Notification — you must submit within the window, with the right content.

That is a detect-to-notify pipeline, and it maps directly onto a monitoring function. For a vehicle fleet, the natural home is a vehicle security operations centre: the VSOC monitors the fleet and backend, and feeds the vulnerability and reporting decisions the CRA demands. Building the reporting capability and building the VSOC are, in large part, the same project.

Where this overlaps with R155

A manufacturer running a mature CSMS to UN R155 already has much of this. R155 requires the CSMS to detect and respond to attacks and to monitor across post-production, and it leans on ISO/SAE 21434 for the engineering substance of vulnerability management. What the CRA adds is the active reporting clock and the explicit coordinated disclosure policy. So the sensible build is not a parallel CRA process but an extension of the existing one: take the CSMS vulnerability-handling machinery, add the disclosure policy and the rehearsed reporting path, and you have satisfied both.

Getting ready

Work back from 11 September 2026. Stand up the SBOM-driven identification, publish the disclosure policy with a contact point, and — the long pole — build and rehearse the reporting path so it works under a realistic clock. Rehearse it with a tabletop before you need it live, because the first exploited vulnerability will not wait for the process to mature.

The AutoSifu view

We build vulnerability handling as one capability that serves both the CRA and the R155 CSMS — SBOM-driven identification, a published disclosure policy, and a rehearsed reporting path wired into fleet monitoring. Through CIRT we run a single route — compliance, solutioning and CoC/VTA support — so the reporting capability required by September 2026 is the same one that satisfies the CSMS's post-production monitoring, with the approval body in the room while the process is designed. That is one operation meeting two duties, not two teams meeting one deadline each.