EU CRA Conformity Roadmap for Automotive Suppliers

If your organization already operates a UNECE R155 cybersecurity management system (CSMS), you have done the hard work that makes the EU Cyber Resilience Act (Regulation (EU) 2024/2847) tractable. But you do not get a free pass: the CRA is a product-level regulation with its own conformity-assessment regime, its own vulnerability-reporting timetable, and its own ENISA-facing notification mechanics. The two regimes overlap in spirit and complement each other in scope, but you cannot file the same evidence twice.

This article is the delta playbook for Tier-1 and Tier-2 automotive suppliers: what your existing R155 CSMS gives you for free, what Article 10 and Annex I demand on top, and a 12-month roadmap to get from R155 maturity to CRA conformity without rebuilding your management system from scratch.

If you want the comparison-level view first, see our EU CRA vs UNECE R155 article. For the conformity-assessment mechanics in isolation, see EU CRA Conformity Assessment for Automotive Components. This piece sits between them: it assumes you have already chosen to comply with both and are looking for the operational sequencing.

TL;DR for the impatient

• The CRA entered into force on 10 December 2024. Vulnerability-handling and reporting obligations apply from 11 September 2026; the full set of obligations applies from 11 December 2027. Verify the latest implementing acts and ENISA guidance before relying on these dates for a specific submission.
• R155 covers vehicle-level cybersecurity (the type approval). CRA covers product-level cybersecurity (every “product with digital elements” placed on the EU market). For a Tier-1 selling an ECU into an OEM and into the aftermarket, both can apply to the same hardware.
• Article 10 sets the manufacturer’s essential obligations: place only secure-by-design products on the market, maintain a vulnerability-handling process, provide users with security information, and ensure the product is “without known exploitable vulnerabilities” at placement.
• Annex I Part I (security properties of products) overlaps ~70–85% with R155 + ISO/SAE 21434 controls. Annex I Part II (vulnerability-handling requirements) maps closely to your existing CSMS post-production monitoring.
• The new work is mostly conformity-assessment paperwork (technical file in the CRA-prescribed format), vulnerability reporting to ENISA on a 24h early-warning / 72h notification / final-report-when-handled clock that is independent of your R155 type-approval reporting flow, and EU declaration of conformity.
• Penalties are tiered (Article 64): up to €15M or 2.5% of worldwide turnover (whichever is higher) for breaches of Annex I essential requirements and Article 13/14 obligations; €10M or 2% for other obligations; €5M or 1% for supplying incorrect or misleading information.

What CRA actually requires of an automotive supplier

The CRA is structured around four obligation pillars for “manufacturers” (Article 10 in the regulation; the term covers anyone placing a product with digital elements on the EU market, including automotive Tier-1s and Tier-2s selling components branded as theirs).

1. Essential cybersecurity requirements (Annex I Part I)

The product, when placed on the market and throughout its support period, must be designed, developed and produced to ensure an “appropriate level of cybersecurity based on the risks”. Annex I Part I enumerates 13 properties; the ones that bite for automotive components are:

• Delivered without known exploitable vulnerabilities.
• Secure-by-default configuration, with the ability to reset to that state.
• Mitigation of known exploitable vulnerabilities through security updates, including automatic updates where appropriate, with mechanisms to revert in case of failure.
• Protection from unauthorized access through appropriate control mechanisms (authentication, identity / access management).
• Confidentiality and integrity of stored, transmitted and processed data, including state-of-the-art mechanisms.
• Availability of essential and basic functions after a security incident, including resilience against denial-of-service.
• Minimization of attack surface, including external interfaces.
• Reduction of impact of incidents using appropriate exploitation-mitigation mechanisms and techniques.
• Recording and monitoring of relevant internal activity, including access, modifications, and security-relevant events.
• Possibility for users to securely and easily remove all data and settings.

For a Tier-1 selling an automotive ECU, most of these are already satisfied through the controls you put in place to clear ISO/SAE 21434 Clause 11 (cybersecurity validation) and Clause 12 (production). The reframe is the documentation: you must show the regulator the same evidence in the CRA technical-file format, not in the R155 evidence-pack format.

2. Vulnerability-handling requirements (Annex I Part II)

Annex I Part II requires the manufacturer to:

• Identify and document vulnerabilities and components contained in the product, including by drawing up an SBOM covering at the very least the top-level dependencies.
• Address and remediate vulnerabilities without delay, including by providing security updates.
• Apply effective and regular tests and reviews of the security of the product.
• Once a security update is available, publicly disclose information about fixed vulnerabilities, including a description of the vulnerability and remediation guidance.
• Put in place and enforce a policy on coordinated vulnerability disclosure.
• Take measures to facilitate the sharing of information about potential vulnerabilities, including by providing a contact address.
• Provide for mechanisms to securely distribute updates to ensure they are pushed in a timely manner and, where applicable, automatically.
• Ensure that, where security patches are available, they are disseminated free of charge, accompanied by advisory messages.

An R155-compliant CSMS already covers most of this. The CRA-specific additions are the SBOM disclosure expectation (R155 does not explicitly require SBOM; CRA effectively does), the public disclosure of fixed vulnerabilities (R155 disclosure is private to the type-approval authority), and the free-of-charge security-patch obligation (a procurement-clause concern more than an engineering one).

3. Reporting obligations (Article 14)

This is where CRA materially extends R155. Article 14 imposes a three-stage reporting timeline to ENISA — via the single reporting platform that ENISA operates — and to the relevant CSIRT:

• 24-hour early warning after becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product.
• 72-hour vulnerability notification with available information including the affected product, severity, and any corrective measures available.
• Final report — without undue delay after the vulnerability is remediated or the incident is handled — with a description of the vulnerability, severity, impact, root-cause analysis, and remediation actions taken.

This timetable is independent of the R155 incident-reporting flow you already run with your type-approval authority. You need both. The operational discipline is to treat the two reporting streams as a single internal incident with two simultaneous regulatory outflows, not as two separate processes.

4. Conformity assessment (Article 32 and Annex VIII)

Most automotive products will be placed on the market through self-assessment under Module A of Annex VIII (internal control), provided they are not classified as “important” or “critical” under Annex III. For products that are classified as important — and Annex III explicitly contemplates “smart vehicle systems” in its illustrative list, with secondary legislation refining the scope — the assessment routes get more involved (Module B + C, full quality assurance under Module H, or third-party European cybersecurity certification).

The output of the conformity assessment is the EU declaration of conformity (Annex V), the CE marking (already required for many automotive sub-systems), and the technical file (Annex VII) retained for at least 10 years after the product is placed on the market.

What an R155-mature supplier carries over for free

If your CSMS is healthy, you already have:

Cybersecurity governance and process documentation: ~85% reusable

Roles, responsibilities, training records, change-management procedures, supplier-management framework, incident-response plan, internal-audit cadence. The CRA does not require a separate management system; it requires evidence that the manufacturer has the processes in place. Your R155 CSMS evidence package satisfies most of this, with the addition of the CRA-specific reporting workflows.

TARA and risk management: ~80% reusable

Your ISO/SAE 21434 TARA structure feeds the CRA “risk-based level of cybersecurity” argument directly. The asset definitions, threat enumeration, attack-feasibility scoring, and risk-treatment decisions all transfer. The CRA expects the analysis to cover the product as a standalone unit (not just as part of the vehicle), so a Tier-1 with an ECU-level TARA is well-placed; a Tier-2 with only system-level analysis may need to author a component-level TARA from the system one.

Security testing evidence: ~70% reusable

Penetration tests, fuzz tests, integration tests, SAST/DAST findings, formal verification where applicable. Reusable in substance; the technical file requires them organized to map onto Annex I Part I’s 13 properties, not onto R155 Annex 5’s threat categories. Plan a one-time re-indexing exercise.

SBOM: highly reusable, with new disclosure obligations

If you already produce CycloneDX or SPDX SBOMs for your OEM customers, the underlying inventory is reusable. The CRA introduces two new requirements:

• The SBOM must be accessible to authorities on request as part of the technical file. It does not need to be made public, but the manufacturer must keep it.
• Public disclosure of fixed vulnerabilities must be supported by the SBOM mapping — advisory readers must be able to determine whether the fix applies to their version.

Vulnerability-handling: highly reusable, with new ENISA reporting

Your CNNVD/NVD/MITRE monitoring program, your fix-availability SLA with the OEM, and your CSMS post-production monitoring transfer over. The new operational requirement is the three-stage reporting timeline to the ENISA single reporting platform (24h early warning, 72h notification, final report once the issue is handled), running in parallel with your existing R155 type-approval-authority reporting.

What changes substantively

Five things require new work, not just relabeling.

1. The technical file (Annex VII) and the EU declaration of conformity (Annex V)

R155 evidence is delivered through the type-approval submission to your home authority (KBA, RDW, etc.). CRA evidence is delivered through a technical file retained by the manufacturer for 10 years and made available to authorities and notified bodies on request. The technical file must contain:

• A description of the product including its intended use.
• The cybersecurity-risk assessment used to demonstrate conformity with Annex I Part I.
• A description of the vulnerability-handling process used to demonstrate conformity with Annex I Part II.
• An SBOM and the cybersecurity-relevant configuration of the product.
• Test reports.
• The EU declaration of conformity.
• Records of post-market vulnerability reports and any incidents.

Practically: stand up a CRA technical-file template alongside your R155 evidence pack. Generate both from the same source TARA + SBOM + test evidence. The painful version is maintaining two documents in parallel by hand; the sustainable version is generating both views from a single TARA platform.

2. ENISA reporting integration

The single reporting platform ENISA operates is the conduit for all CRA Article 14 reports. You need:

• A nominated CRA-reporting role inside the organization (often the same person who handles R155 incident notification, but with a separate reporting account).
• An incident-classification rubric that triggers the CRA timeline as soon as the incident meets “actively exploited vulnerability” or “severe incident with impact on product security” criteria — the rubric must be tighter than R155’s, because the 24-hour clock starts on awareness, not on root-cause confirmation.
• Pre-staged report templates for the three stages, populated where possible from the existing post-production monitoring tooling.
• A communication SOP between your global SOC, the CSMS officer, and the CRA reporting role — an incident reaches all three simultaneously.

The 24-hour early warning is the most operationally demanding piece. Many R155 organizations have informal “we’ll notify the authority within a few business days” norms. The CRA explicitly forbids that pattern.

3. Coordinated vulnerability disclosure (CVD) policy

Annex I Part II requires the manufacturer to put in place a CVD policy. R155 does not require this explicitly. If you do not already have a public security@ contact, a published vulnerability-disclosure SLA, and a public security advisory mechanism, this is a ~6-week effort spanning legal, security engineering, comms, and product. The artifact is roughly the same shape as a security.txt file plus a published policy page; the discipline is operating it.

4. Public security advisories

R155 disclosure is private to the authority. CRA requires public disclosure of fixed vulnerabilities once the security update is available, with a description of the vulnerability, severity, and remediation guidance. The format expected by ENISA aligns with CSAF 2.0 security advisories — if you are already producing CSAF for your OEM customers (see our Tier-2 to OEM evidence handover playbook), you mostly have the format; you need a public publication channel for it.

5. Conformity-assessment route choice

For Class I products, self-assessment under Module A is sufficient. For products on the “important” list (Annex III), you must choose between Module B + C (EU-type examination + production-quality assurance), Module H (full quality assurance), or third-party European cybersecurity certification. The choice has material cost and lead-time implications:

• Module A (self-assessment): paper-only, no notified body, fastest. Default for most automotive components.
• Module B + C: type-examination by a notified body, production verification. ~3–6 months added lead time per major product line. Required for Annex III important products that are not certified under a recognized European cybersecurity certification scheme.
• Module H: full quality assurance audit by a notified body. Heaviest lift; suitable for manufacturers shipping a portfolio of products.

The decision between Module B + C and Module H is largely a portfolio-economics question: if you ship one product line, B + C is cheaper. If you ship a dozen, H amortizes faster. The wildcard is which European cybersecurity certification schemes get adopted as alternatives — treat the picture as evolving and revisit the choice annually.

Quick comparison: R155 vs CRA

Dimension	UNECE R155	EU CRA (2024/2847)
Object of regulation	Vehicle type approval	Product with digital elements placed on the market
Geographic scope	UNECE 1958 contracting parties (~60+)	EU/EEA market; manufacturer can be outside the EU but appoint an authorized representative
Who is regulated	Vehicle manufacturer (OEM)	Product manufacturer (OEM, Tier-1, Tier-2, or any seller)
Conformity gate	Type approval + CSMS certificate	Conformity assessment + CE marking + EU declaration of conformity
Risk basis	Vehicle-level TARA per R155 Annex 5	Product-level cybersecurity risk assessment per Annex I
Vulnerability reporting	To type-approval authority; no fixed timeline	To ENISA + CSIRT via single reporting platform; 24h early warning / 72h notification / final report when handled
Public disclosure	Not required	Required for fixed vulnerabilities once update is available
SBOM	Recommended (ISO 21434), not mandated	Effectively mandated as part of vulnerability-handling and technical file
Support period	Throughout vehicle production + post-production	At least 5 years from placement on market (longer if reasonably expected by user)
Penalties	Withdrawal of type approval; vehicle cannot be sold	Tiered: up to €15M or 2.5% (Annex I + Art. 13/14); €10M or 2% (other obligations); €5M or 1% (incorrect information); product withdrawal; recall
Effective date	New types 2022-07; existing types 2024-07 (already in force)	Vulnerability-handling 2026-09-11; full obligations 2027-12-11

The 12-month roadmap from R155 to CRA

This roadmap assumes your starting point is “R155 mature, CRA not yet addressed”. Adjust the milestones if you already have CSAF advisory pipelines or a public CVD policy.

Months 1–3 — gap analysis and ownership

1. Run a R155-to-CRA gap analysis at the product family level: which products are in scope, which Annex III classification applies, which Annex I Part I properties are not yet evidenced.
2. Decide and document the conformity-assessment route per product family (Module A by default; Module B+C or H for Annex III important products).
3. Nominate a CRA reporting role and create an ENISA single-reporting-platform account. Define the on-call rota.
4. Commission a coordinated vulnerability-disclosure policy (legal + security + comms). Publish a security@ contact and an SLA on the company website.
5. Start the CSAF advisory pipeline if you do not have one. The Tier-2 to Tier-1 to OEM evidence flow already covers the format expectation; this extends it to the public-disclosure stage.

Months 4–6 — technical file and SBOM disclosure

1. Stand up a CRA technical-file template aligned with Annex VII. Map each section to evidence already in your R155 pack; identify gaps.
2. Re-index existing test reports against Annex I Part I’s 13 properties. Most reports cover multiple properties; do this once, not per submission.
3. Validate that your SBOM coverage is sufficient for the technical file. Top-level dependencies are required at minimum; a richer SBOM reduces vulnerability-investigation latency later.
4. Run a tabletop exercise on the 24h early-warning / 72h-notification / final-report reporting timeline. Use a synthetic exploit-in-the-wild scenario that your existing post-production monitoring would surface.
5. Update supplier interface agreements to require Annex-I-compatible evidence flow upstream. Without it, you cannot complete your own conformity assessment for components you incorporate.

Months 7–9 — first conformity assessment

1. Run the conformity assessment on a pilot product. Module A: internal review, sign declaration. Module B+C: notified-body engagement (book the date 4–6 months in advance).
2. Issue the EU declaration of conformity and apply CE marking (where not already applied).
3. Begin operating the public security advisory channel — even before the CRA mandates it, soft-launch lets you stress-test the disclosure pipeline.
4. Validate the technical-file retention process. 10 years means the document-management system, not engineers’ laptops.

Months 10–12 — rollout and steady-state

1. Roll the conformity-assessment process across remaining product families.
2. Integrate the CRA reporting clock into your incident-management runbooks — the 24-hour early-warning is a discipline, not a system change.
3. Run an internal audit against Annex I Part I and Part II controls; close any residual gaps.
4. Establish a quarterly review of ENISA bulletins, harmonized standards, and notified-body guidance. CRA secondary legislation will continue to land for several years.

Common pitfalls

Treating CRA as “R155 with paperwork”

The two regimes overlap heavily on engineering controls but diverge sharply on procedure: who you report to, what you publish, when the clock starts, what document format is authoritative. A team that just renames its R155 evidence pack as a “CRA technical file” will fail an authority inspection — the structure differs, and so do the obligations around public disclosure and the 10-year retention.

Underestimating the 24-hour clock

The CRA 24-hour early warning starts on the manufacturer’s awareness of an actively exploited vulnerability or a severe incident with security impact, not on root-cause confirmation. Organizations whose incident response is geared toward “don’t notify until you understand it” will miss the deadline. Build a notification SOP that fires on awareness with the information available, then refines at 72h and again with the final report once the issue is handled.

Forgetting CRA Article 13 obligations of distributors and importers

Article 13 imposes verification obligations on distributors and importers — they must check the EU declaration of conformity, the CE marking, the user instructions, and the technical-file accessibility before placing the product on the market. If your supply chain crosses a non-EU boundary, the importer obligations land somewhere; clarify in the contract whether the importer or the manufacturer-with-EU-representative carries the verification.

Annex III classification drift

Annex III lists important and critical product classes; the European Commission can update it via delegated acts. A product self-assessed under Module A today can land on the important list tomorrow, requiring a Module B+C or H pivot. Track Annex III revisions; do not assume a once-classified product stays classified.

Letting the SBOM atrophy

The CRA expects the SBOM to be maintained throughout the support period. An SBOM generated once at release and never updated is not compliant. The vulnerability-handling Annex I Part II requires you to monitor against the SBOM through the full support period, which means the SBOM must reflect what is actually in the field, not what was in the first ROM image.

Single-source the evidence: TARA + SBOM + test reports + advisories

The sustainable architecture for a Tier-1 or Tier-2 covering both R155 and CRA is to maintain a single source of truth for the cybersecurity artifacts and generate the regulator-specific views as templates:

1. Author the TARA against ISO/SAE 21434.
2. Maintain a catalog overlay that maps ISO 21434 threats to R155 Annex 5 categories and to CRA Annex I Part I properties.
3. Generate the R155 evidence pack and the CRA technical file from the same source via templates.
4. Run vulnerability monitoring against a single SBOM; emit advisories to OEM customers (R155 flow) and to the public CSAF channel (CRA flow) from the same fix-tracking system.
5. Track the delta between R155 Annex 5 revisions, GB 44495 Annex A revisions, and CRA Annex I revisions over time so each regulator-specific update is incremental, not a rewrite.

This is what an automated TARA platform does for you when it ships with multi-regulation overlays. Done by hand, the dual-track discipline is feasible but easily slips when staffing changes or when a product family acquires regulatory complexity (R155 + CRA + GB 44495 simultaneously, increasingly common for global Tier-1s).

Key takeaways

1. The EU CRA is in force; vulnerability-handling obligations start 11 September 2026, full obligations 11 December 2027. The window for “we will get to it” is closed for any product reaching the EU market.
2. If you have mature R155 + ISO/SAE 21434 evidence, you reuse roughly 70–85% of governance, TARA, and security-testing artifacts. The lift is in the technical-file format, ENISA reporting integration, public CVD, and conformity-assessment route choice.
3. The largest practical risks are the 24-hour early-warning clock, Annex III classification drift over time, importer/distributor obligations if your supply chain crosses an EU boundary, and SBOM atrophy through the support period.
4. Plan a 12-month runway for an R155-mature supplier to reach CRA conformity on a first product family. After that, each additional product family is closer to 4–8 weeks if the technical-file template and ENISA workflow are reusable.
5. Build a single-source TARA + SBOM + advisory pipeline that emits regulator-specific views as templates; avoid maintaining two parallel evidence packs by hand.

Further reading

• EU CRA vs UNECE R155 — high-level comparison
• EU CRA Conformity Assessment for Automotive Components
• UNECE R155 Type Approval Guide
• ISO/SAE 21434 TARA Step-by-Step Guide
• GB 44495 vs UNECE R155 — entering China
• Tier-2 → Tier-1 → OEM Evidence-Handover Playbook
• CSMS Audit Preparation Checklist