The EU Cyber Resilience Act's reporting obligations come online in just over four months — and the operational bar is steeper than the headline numbers suggest.
On September 11, 2026, Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) becomes enforceable. From that date, manufacturers of products with digital elements placed on the EU market must notify actively exploited vulnerabilities and severe security incidents through ENISA's new Single Reporting Platform on a tight three-stage cadence:
- Early warning within 24 hours of becoming aware
- Substantive notification within 72 hours
- Final report within 14 days of a corrective measure being available (for vulnerabilities), or within one month of notification (for severe incidents)
Missing those deadlines is a top-tier infringement under the regulation — up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Art. 64(2)). And Article 69(3) makes the reporting obligation retroactive to your entire installed base, not just products you place on the market after the December 2027 main-application date.
For Saphira and VicOne customers, this isn't a future problem. It's a workflow problem we've already been solving — and the partnership we announced in March maps directly onto what Article 14 actually requires.
Why the 24-hour clock is harder than it sounds
The CRA defines an actively exploited vulnerability narrowly: there must be reliable evidence that a malicious actor has used a flaw against a system without the owner's permission. But the 24-hour clock starts at reasonable belief — not forensic confirmation. Unusual access patterns, customer reports of compromise, or threat intelligence indicating your product is being targeted all start the timer.
That early-warning notification has to identify the affected Member States. The 72-hour follow-up has to describe the nature of the exploit, the mitigations you've already taken, the mitigations users can deploy themselves, and a sensitivity flag if you want the receiving CSIRT to consider delaying further dissemination. The 14-day final report needs severity, root cause, threat-actor information where available, and the corrective measures shipped.
Translated into engineering reality, that means within 72 hours your team needs to have:
- Confirmed which product versions and SKUs contain the vulnerable component — SBOM-grounded
- Mapped the vulnerability to specific assets, attack paths, and downstream safety or availability impacts — TARA-grounded
- Identified or shipped at least preliminary mitigations
- Drafted user-facing guidance in a structured, ideally machine-readable format
Most teams don't have this stack pre-wired. They run vulnerability management and TARA documentation as separate motions, with the TARA only refreshed at audit gates or release boundaries. Under the CRA, that gap stops being a documentation hygiene issue and starts being a compliance failure — the engineering context you need for the 72-hour notification is locked inside the next quarterly TARA cycle.
How the Saphira × VicOne loop pre-stages Article 14 compliance
The closed loop we built with VicOne is purpose-shaped for this. VicOne xZETA detects vulnerabilities — including zero-days surfaced through Trend Micro's Zero Day Initiative — against your SBOM, and prioritizes findings using the VicOne Vulnerability Impact Rating (VVIR). When a finding affects a component in your product, xZETA fires an event into Saphira. Saphira automatically refreshes the relevant TARA work products — impacted assets, updated attack paths, recalculated risk, revised cybersecurity goals and requirements — and feeds the engineering impact analysis back to VicOne so vulnerability response prioritization reflects real product context rather than CVSS scores in isolation.
For the Article 14 reporting cadence, that loop pre-positions exactly the artifacts your reporting workflow needs:
- Within 24 hours: SBOM-mapped product identification plus an early VVIR-driven severity read is already in hand. Your early-warning submission has the affected products, the jurisdictions where they've been made available, and a preliminary "suspected malicious activity" determination ready to file.
- Within 72 hours: Saphira has the refreshed TARA delta, the mapped attack paths, and the scoped corrective measures. The notification body — nature of the exploit, mitigations taken, mitigations users can deploy — is generated from the living cybersecurity case rather than assembled by hand from disconnected tickets.
- Within 14 days: When the patch ships, the final report writes itself from the closed loop: severity assessment, root cause analysis, the applied corrective action, and full traceability back to security goals.
And the same loop satisfies Annex I Part II
The CRA's vulnerability handling obligations in Annex I Part II aren't a separate workstream — they're the operational substrate the loop runs on:
| CRA requirement | Saphira × VicOne |
|---|---|
| Part II.1 — Identify and document vulnerabilities; maintain an SBOM | xZETA-generated SPDX/CycloneDX SBOMs continuously rescanned |
| Part II.2 — Address and remediate vulnerabilities without delay | Auto-triggered TARA refresh + Saphira-managed mitigation actions |
| Part II.3 — Apply effective and regular security testing | Continuous scanning across the support period, not point-in-time |
| Part II.4 — Publicly disclose information about fixed vulnerabilities | Saphira generates the user-facing advisory from the closed loop |
| Part II.5 — Coordinated vulnerability disclosure policy | Saphira's CVD workflow + RBAC-controlled approval gates |
| Part II.6 — Mechanisms to share vulnerability information | API-mediated handoff back to VicOne for upstream component owners |
| Part II.8 — Disseminate security updates without delay, with advisory messages | Final report and user advisory publish from the same workflow |
Beyond automotive: who this matters for
A common misread of the CRA is that automotive is "already covered" by UN R155. The CRA does explicitly exclude products falling within the scope of Regulation (EU) 2019/2144 (Art. 2(2)(c)) — so the vehicle itself, type-approved under R155, is out of scope. But almost everything around the vehicle is in scope:
- Standalone automotive components and aftermarket parts sold separately
- EV chargers and charging infrastructure software
- Telematics units, OBUs, and fleet management endpoints sold as standalone products
- The broad robotics market — industrial robots, AMRs, humanoids, manipulation platforms
The "important products with digital elements" list in Annex III pulls in many of the building blocks our customers ship: network management systems, intrusion detection and prevention systems, identity and access management software, microcontrollers and microprocessors with security-related functionalities, and smart home products with security functionalities. These categories carry stricter conformity assessment procedures and the same Article 14 reporting clock.
For Tier suppliers, robotics OEMs, and EV charger manufacturers in this scope, the September 2026 deadline isn't optional and the reporting workflow isn't something you stand up after the first incident. The teams that will hit the 24-hour clock cleanly are the ones whose vulnerability management and cybersecurity case documentation are already a single closed loop.
What you can measure
The instrumentation matters because the regulator will ask. If you wire the loop properly, the metrics tell the story directly:
- Time from vulnerability discovery → updated TARA + draft Article 14 notification
- Time from discovery → user-facing advisory published
- Percentage of high-VVIR findings with completed engineering impact analysis inside 24 hours
- Audit-prep time reduction for CRA technical documentation per Annex VII
- Traceability coverage from threats → mitigations → shipped corrective measures across the support period
These are the same KPIs that map onto Article 14 deadlines, Article 13(3) risk assessment maintenance, and Article 31 technical documentation requirements. They're also the metrics that turn an Article 14 audit from a fire drill into a five-minute report export.
Get ahead of the September clock
If you're a manufacturer of products with digital elements selling into the EU — automotive Tier supplier, robotics company, EV charger OEM, industrial control vendor — the four-month runway to Article 14 enforcement is exactly the right window to wire vulnerability management and TARA into a single, audit-ready workflow rather than discovering the gap during your first reportable incident.
We're working with customers right now on CRA-readiness assessments that integrate Saphira's TARA automation with VicOne's xZETA vulnerability and SBOM management. If you'd like to walk through how the Saphira × VicOne loop maps onto your product portfolio and your Article 14 obligations, book a call.
The clock starts September 11. Don't be assembling the workflow on day one.
