Reporting obligations start on 11 September 2026
Most organizations are planning for December 2027. That is the wrong date to plan against first.
From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT – early warning within 24 hours, full notification within 72 hours, final report thereafter. This obligation applies to products already on the EU market, not only to products you place on it in future.
If you cannot currently detect an actively exploited vulnerability in a fielded product, decide within a day whether it is reportable, and file within 24 hours, you have a gap that becomes visible this autumn.
The essential requirements, technical documentation, conformity assessment and CE marking follow on 11 December 2027.
“We build vehicles – the CRA does not apply to us”
Sometimes true. Often not, and the boundary is where most of the confusion sits.
Vehicles under EU type-approval are carved out, because cybersecurity is already covered by UNECE R155 and R156. But the exclusion applies to the regulated product, not to your company or your portfolio. In scope are, for example:
- Diagnostic and workshop equipment
- Aftermarket and retrofit devices
- Telematics units and connected accessories sold separately
- Charging infrastructure
- Development tools, test benches and software sold as products
- Software components and libraries placed on the market in their own right
A supplier can therefore be entirely outside the CRA for its ECU business and squarely inside it for a diagnostic tool or a licensed software stack.
The first question is not how do we comply – it is which parts of our portfolio are actually in scope, and in which product class.
Where the regulation actually stands
Worth knowing before you build a plan around it:
- The Commission’s standardisation request M/606 covers roughly 40 harmonised standards. As of mid-2026, none had been published in the Official Journal.
- No notified bodies have yet been designated for the CRA. Member States have been able to notify conformity assessment bodies since 11 June 2026.
- The ENISA single reporting platform is scheduled to be operational by 11 September 2026.
The practical consequence: for Important Class I products, two of the three conformity routes depend on standards or specifications that do not yet exist. That does not justify waiting. Reporting readiness, product classification, secure development processes and SBOM generation can all be built now – and they are the long-lead items.
What you get
CRA applicability analysis
A documented, defensible determination for each product line: in scope or out, under which definition, and in which class – default, important (Class I or II), or critical. This is the deliverable that ends the internal argument.
Gap assessment against Annex I
Essential requirements for the product and for vulnerability handling, assessed against how you actually develop and support today – including SBOM readiness under Annex I Part II.
Reporting readiness for September 2026
Trigger definitions, decision criteria for “actively exploited” and “severe”, escalation paths, and a 24/72-hour workflow that a real on-call engineer can follow. Integrated with existing NIS2 or ISO/SAE 21434 incident processes rather than parallel to them.
Implementation roadmap to December 2027
Prioritised, resourced, and sequenced around what is on the critical path – conformity route, technical documentation, supplier obligations, post-market surveillance.
Where existing work carries over
Most automotive organizations have more CRA substance than they think. ISO/SAE 21434 CSMS, TARA, vulnerability management and ISO 5230 open source governance all map onto CRA obligations. The point of the engagement is to reuse them, not to build a second system.
Typical engagement
| Engagement | Typical effort |
| Applicability analysis | 1-2 days, for the first product line, less for similar ones |
| Gap assessment | 3 days per product line |
| Reporting readiness workshop | 3 days, engineering plus support and legal |
| Roadmap and coaching | ongoing, typically 2-4 days per month |
Remote or on site, in German or English. Most organizations start with the applicability analysis, because everything downstream depends on it.
Why Safionyx
CRA readiness is not a legal exercise. It is a product engineering exercise with a legal deadline attached – which is why it sits badly with law firms and badly with generic security consultancies.
Alexander Much spent 22 years in safety- and security-critical automotive software, most recently as Director for Quality, Functional Safety, Cybersecurity and Open Source at Elektrobit, where he built the organization’s cybersecurity compliance capability through the introduction of ISO/SAE 21434 and UNECE R155. He is an INTACS Principal Assessor for Automotive SPICE with the Security Extension, a Certified Automotive Cybersecurity Manager and Engineer, and the author of 50+ publications on functional safety, cybersecurity and process assessment with Springer, Wiley and Elsevier.
The CRA touches all four of those areas at once: secure development process, cybersecurity engineering, open source and SBOM, and demonstrable evidence. That combination is the reason to call.
Related work
- A Multilevel Approach to TARA: Proposals for Attack Feasibility in Interference-Free Scenarios – Wiley, Software: Evolution and Process, 2025
- The New Cybersecurity Challenges and Demands for Automotive Organisations and Projects – Springer, EuroSPI 2023
- Automotive SPICE for Cybersecurity: MAN.7 Cybersecurity Risk Management and TARA – Springer, EuroSPI 2022
Start with the question that matters
Does the CRA apply to your product, and in which class?
A 45-minute call is usually enough to tell you whether you have a September problem, a December 2027 problem, or neither.
Arrange a call: alexander.much@safionyx.com
Sources for the dates above: Regulation (EU) 2024/2847; European Commission, CRA summary and implementation guidance.