EU CRA Conformity Assessment for Automotive Components

The EU Cyber Resilience Act (CRA), Regulation 2024/2847, introduces mandatory cybersecurity requirements for every product with digital elements sold in the European Union. For automotive suppliers, the CRA creates a parallel compliance obligation alongside UNECE R155 and ISO/SAE 21434. While type-approved vehicles are exempt from CRA scope, the components, aftermarket devices, and software tools that suppliers place independently on the EU market are not. This guide provides a step-by-step walkthrough of EU CRA conformity assessment specifically for automotive components, covering CRA product classification, conformity procedures, ENISA reporting mechanics, technical documentation, CRA penalties, and the key dates every supplier must track.

If you are a compliance manager or cybersecurity engineer at an automotive Tier-1 or Tier-2 supplier, this is the practical implementation reference you need. For a strategic comparison of CRA and R155 scope and overlap, see our companion article on EU CRA vs UNECE R155.

CRA Scope — Which Automotive Products Are Covered?

The Cyber Resilience Act applies to all "products with digital elements" placed on the EU single market. A product with digital elements is defined broadly as any software or hardware product and its remote data processing solutions, including components placed on the market separately. For the automotive industry, this definition captures a wide range of products beyond the vehicle itself. Understanding which products fall in scope is the essential first step before any conformity assessment work begins.

Type-Approved Vehicle Exemption

Article 2(2) of the CRA explicitly exempts motor vehicles and their trailers that fall within the scope of EU Regulation 2019/2144, the General Safety Regulation. This regulation incorporates UNECE R155 cybersecurity requirements into the EU type approval framework. Consequently, a complete vehicle that holds a valid type approval under R155 is not subject to CRA obligations. The rationale is straightforward: the EU does not impose two separate cybersecurity regimes on the same product when one already achieves the regulatory objective.

However, the exemption is narrow and precise. It applies to the vehicle as a whole product, meaning the specific configuration that was type-approved. It does not extend to every component that happens to be installed in a vehicle. If a Tier-1 supplier manufactures a telematics control unit that is integrated into an OEM's type-approved vehicle, that unit is covered by the OEM's R155 type approval. But if the same supplier sells the same unit as a standalone aftermarket product or to fleet management integrators, that product is placed on the EU market independently and falls within CRA scope.

Aftermarket and Non-Regulated Components

Aftermarket automotive products are squarely within CRA scope. This includes aftermarket ECUs, diagnostic tools, OBD-II dongles, dashcams with cloud connectivity, fleet telematics hardware, V2X aftermarket units, and any automotive software product sold independently. These products are placed on the EU market by their own manufacturer and are not covered by any vehicle type approval. The manufacturer of each such product must perform CRA conformity assessment before affixing the CE marking and making the product available.

Software products deserve particular attention. A standalone software application used for vehicle diagnostics, calibration, or fleet management constitutes a product with digital elements under the CRA, even if it has no hardware component. Open-source software that is commercialized (i.e., placed on the market as part of a commercial activity) also falls in scope. Only non-commercial open-source software developed outside the course of a commercial activity is excluded.

Dual-Use Components (R155 + CRA)

Many automotive components exist in a dual-use scenario. A vehicle gateway ECU, for example, may be sold to OEMs for integration into type-approved vehicles (covered by R155) and also sold to aftermarket system integrators (covered by CRA). In this scenario, the manufacturer faces compliance obligations under both regulations, though for different sales channels. The underlying cybersecurity engineering work is largely shared, but the conformity assessment procedures, documentation formats, and reporting obligations differ. Suppliers should map each product variant and sales channel to the applicable regulation during the initial scoping phase.

Product Classification Decision Framework

Once you have confirmed that a product falls within CRA scope, the next step is to determine its classification. The CRA establishes four classification tiers with progressively stricter conformity assessment requirements. The classification determines whether self-assessment is permitted or whether a notified body (third-party auditor) must be involved. Getting the classification right is critical because misclassification can result in non-compliance even if all technical requirements are met.

Default Category (Self-Assessment Path)

Products that do not appear in Annex III (important products) or Annex IV (critical products) of the CRA fall into the default category. The default category covers the majority of products with digital elements. For these products, the manufacturer may perform an internal control procedure (Module A) without involving a notified body. This is the lightest-touch assessment path, but it still requires full compliance with all essential cybersecurity requirements in Annex I, complete technical documentation, and an EU declaration of conformity.

For automotive suppliers, default category products might include simple aftermarket accessories with basic connectivity, vehicle-mounted cameras without cloud processing, or basic sensor modules with limited network interfaces. The key factor is that the product does not perform a function listed in Annex III or Annex IV.

Important Product — Class I

Annex III, Part I of the CRA lists product categories classified as Important Class I. These include identity management systems, network management systems, security gateways, and certain categories of industrial automation and control systems. For automotive components, standalone network gateways, in-vehicle network management tools, and identity management components for fleet systems may fall into this class.

Class I products have a self-assessment option: the manufacturer may perform internal control (Module A) if the product has been designed and manufactured in conformity with a harmonized European standard (hEN) that covers all relevant CRA essential requirements. If no such harmonized standard exists or the product does not fully conform to one, the manufacturer must use a third-party conformity assessment procedure. This creates a strong incentive for automotive suppliers to track and adopt harmonized standards as they are published.

Important Product — Class II

Annex III, Part II lists product categories classified as Important Class II, which require mandatory third-party assessment regardless of harmonized standard conformity. Class II products include operating systems, hypervisors, microcontrollers, hardware security modules (HSMs), secure elements, hardware devices with security boxes, smartcard readers, and firewalls for industrial use. For automotive suppliers, this classification is significant because HSMs are explicitly listed as Class II products. Any HSM placed on the EU market as a standalone product requires third-party conformity assessment by a notified body. The same applies to automotive microcontrollers sold independently, secure boot hardware, and industrial-grade firewalls used in vehicle or factory network architectures.

Critical Products

Annex IV of the CRA lists critical products that require the most rigorous conformity assessment: EU-type examination by a notified body. As of the current text, critical products include smart meter gateways, hardware devices with security boxes intended for qualified electronic signature or seal creation, and similar high-assurance products. Few automotive components currently fall into the critical category, but suppliers should monitor delegated acts from the European Commission, which may expand this list over time. If a product is reclassified from Important to Critical through a delegated act, the conformity assessment requirements become significantly more demanding.

Classification Examples for Automotive

Automotive Product	CRA Classification	Assessment Path
Aftermarket dashcam with Wi-Fi	Default	Self-assessment (Module A)
OBD-II diagnostic dongle	Default	Self-assessment (Module A)
Standalone V2X On-Board Unit	Important — Class I	Self-assess with hEN or third-party
Vehicle network gateway (aftermarket)	Important — Class I	Self-assess with hEN or third-party
Fleet management software platform	Important — Class I	Self-assess with hEN or third-party
Automotive Hardware Security Module (HSM)	Important — Class II	Mandatory third-party (Module B+C or H)
Secure microcontroller (standalone)	Important — Class II	Mandatory third-party (Module B+C or H)
Vehicle firewall appliance	Important — Class II	Mandatory third-party (Module B+C or H)
ECU operating system (sold separately)	Important — Class II	Mandatory third-party (Module B+C or H)
Smart meter gateway (factory energy)	Critical	EU-type examination (notified body)

Note that classification depends on how the product is placed on the market, not solely on its technical characteristics. The same HSM integrated exclusively into a type-approved vehicle is covered by R155. The same HSM sold as a standalone component on the EU market is a Class II product under the CRA.

Conformity Assessment Procedures Step by Step

Once classification is determined, the manufacturer must follow the corresponding conformity assessment procedure. The CRA references assessment modules from the New Legislative Framework, which are well-established patterns used across EU product safety legislation. The three primary routes are Module A (internal control), Module B+C (EU-type examination plus conformity to type), and Module H (full quality assurance).

Internal Control (Module A) for Default Products

Module A is the self-assessment procedure available to default category products and, conditionally, to Important Class I products that conform to harmonized standards. Under Module A, the manufacturer performs the conformity assessment internally, without notified body involvement. The procedure requires the following steps:

1. Identify applicable essential requirements: Review Annex I of the CRA and determine which requirements apply to the product. Document which requirements are applicable and which are not, with justification for any exclusions.
2. Perform cybersecurity risk assessment: Conduct a risk assessment specific to the product, identifying threats, vulnerabilities, and potential impact. The risk assessment must consider the intended use and reasonably foreseeable misuse of the product.
3. Design and implement security measures: Ensure the product is designed, developed, and produced in accordance with the essential requirements. This includes secure default configurations, protection of data confidentiality and integrity, minimization of the attack surface, and availability of security update mechanisms.
4. Compile technical documentation: Prepare the complete technical documentation required by Annex VII, including product description, risk assessment, design and manufacturing information, applied standards, test results, and the SBOM.
5. Establish vulnerability handling process: Implement a coordinated vulnerability disclosure process and ensure the ability to deliver security updates throughout the support period.
6. Draw up the EU declaration of conformity: Prepare the written declaration per Annex V, stating that the essential requirements have been fulfilled. The declaration must reference the product, the manufacturer, the applicable CRA provisions, and any harmonized standards applied.
7. Affix the CE marking: Place the CE marking visibly, legibly, and indelibly on the product or, where not possible, on the packaging and accompanying documentation.

Module A is not a rubber stamp. Market surveillance authorities can request the full technical documentation at any time and may conduct random checks. If the documentation is incomplete or the product fails to meet essential requirements, the manufacturer faces enforcement action regardless of the self-assessment declaration.

EU-Type Examination (Module B + C) for Class II / Critical

Important Class II and Critical products must undergo third-party conformity assessment. The primary procedure is Module B (EU-type examination) followed by Module C (conformity to type based on internal production control). This two-phase approach separates the design review from the production compliance check.

Module B — EU-Type Examination: The manufacturer submits an application to a notified body, including the complete technical documentation and a representative sample of the product. The notified body examines the documentation, verifies that the product has been designed in conformity with the applicable essential requirements of Annex I, performs or commissions tests to verify compliance, and issues an EU-type examination certificate if the product meets all requirements. The certificate specifies the type approved and any conditions for validity.

Module C — Conformity to Type: The manufacturer ensures that production processes reliably produce units conforming to the approved type described in the EU-type examination certificate. The manufacturer performs internal production controls and maintains records demonstrating ongoing conformity. Each product unit must conform to the approved type and meet the essential requirements of the CRA.

For automotive HSMs or secure microcontrollers, this means the supplier must engage a CRA-notified body, submit detailed technical documentation including the hardware design, firmware architecture, cryptographic implementation evidence, and penetration test results, and pass the type examination before placing the product on the market.

Full Quality Assurance (Module H) Alternative

As an alternative to Module B+C, manufacturers of Important Class II products may choose Module H, the full quality assurance procedure. Under Module H, the manufacturer operates an approved quality management system covering design, production, and final product inspection. A notified body audits and approves this quality system, and the manufacturer produces products under the system with ongoing notified body surveillance.

Module H can be more efficient for manufacturers producing a wide range of CRA-covered products because it avoids per-product type examination. Instead of certifying each product individually, the notified body approves the overall quality system and monitors it through periodic audits. For a Tier-1 supplier with dozens of CRA-scoped products, Module H may reduce the total cost and lead time compared to Module B+C for each product. However, Module H requires a mature quality management system that meets CRA-specific requirements, which goes beyond a standard ISO 9001 system.

Harmonized Standards and Presumption of Conformity

The CRA establishes a presumption of conformity for products manufactured in accordance with harmonized European standards (hENs) whose references have been published in the Official Journal of the EU. Conformity with such a standard creates a legal presumption that the product meets the essential requirements covered by that standard. This is particularly valuable for Important Class I products, where harmonized standard conformity enables self-assessment rather than third-party assessment.

The European Commission has issued standardization requests to CEN, CENELEC, and ETSI to develop harmonized standards supporting the CRA. For automotive suppliers, alignment between these standards and ISO/SAE 21434 is being actively discussed. Until harmonized standards are formally published and referenced, no presumption of conformity exists, and suppliers should plan for third-party assessment as the default path for Class I and Class II products.

Suppliers should monitor the Official Journal and the European Commission's standardization work programme for updates. The expected publication of the first CRA harmonized standards is anticipated in late 2026 or early 2027, ahead of the full application date of December 11, 2027.

ENISA Vulnerability Reporting Mechanics

One of the CRA's most operationally impactful obligations is mandatory vulnerability reporting to ENISA (the European Union Agency for Cybersecurity). Unlike R155, which requires monitoring and response but does not specify a central reporting authority with fixed timelines, the CRA establishes a strict three-phase reporting process with hard deadlines. ENISA reporting obligations apply from September 11, 2026, eighteen months before full CRA application, making them the first CRA requirement to become enforceable.

24-Hour Early Warning — What to Report

Within 24 hours of becoming aware of an actively exploited vulnerability in a product with digital elements, the manufacturer must submit an early warning to ENISA. The 24-hour clock starts from awareness, not from confirmation or root cause analysis. The early warning must include:

• Identification of the affected product(s) and product versions
• A preliminary description of the vulnerability and the nature of the active exploitation
• An assessment of whether the vulnerability potentially affects products available in other EU member states
• Any initial assessment of the severity of the vulnerability

The early warning is deliberately designed to be lightweight. The CRA recognizes that detailed analysis is not possible within 24 hours. The purpose is to enable ENISA and national CSIRTs (Computer Security Incident Response Teams) to initiate coordinated response activities. Manufacturers should not delay the early warning waiting for complete information. Report what you know at the 24-hour mark and follow up in subsequent notifications.

72-Hour Vulnerability Notification — Required Content

Within 72 hours of becoming aware of the actively exploited vulnerability, the manufacturer must submit a vulnerability notification to ENISA with substantially more detail. The 72-hour notification must include:

• General information about the nature of the vulnerability, including an assessment of its severity using established scoring methodologies such as CVSS
• Information about the exploitation, including whether the exploitation is known to be targeted or widespread
• Information about the security update or corrective measures available or being developed
• Where applicable, information about any mitigating measures that users can take pending the availability of a patch
• Where applicable, information about coordination with other manufacturers or stakeholders

If a security update is already available at the 72-hour mark, the notification should reference it. If not, the notification must describe the mitigation strategy and expected timeline for delivering a fix. Automotive suppliers accustomed to coordinating patch releases with OEM integration timelines should build this coordination into their 72-hour reporting process.

14-Day Final Report

Within 14 days of becoming aware of the actively exploited vulnerability, the manufacturer must submit a final report to ENISA. The final report must include:

• A detailed description of the vulnerability, including its severity and impact
• Information about any malicious actor that has exploited or is exploiting the vulnerability, where available
• Details of the security update or corrective measures made available to remediate the vulnerability
• Where applicable, guidance to users on actions they can take to mitigate the effects of the vulnerability

The 14-day final report is expected to reflect a substantially mature understanding of the vulnerability, its root cause, and the remediation. For automotive suppliers, this means that vulnerability analysis and patch development processes must be calibrated to produce actionable results within a two-week window, a timeline that may be shorter than typical automotive development cycles.

Single Reporting Platform and Submission Format

ENISA is establishing a single reporting platform to receive CRA vulnerability notifications. The platform will provide a structured submission format that standardizes reporting across all manufacturers and product categories. While the final platform specifications were still being developed at time of writing, manufacturers should prepare by establishing internal processes that capture the required data fields in a structured format. Machine-readable vulnerability reports, ideally aligned with established formats such as CSAF (Common Security Advisory Framework) or VEX (Vulnerability Exploitability eXchange), will streamline the submission process once the platform is operational.

Manufacturers that already operate a Product Security Incident Response Team (PSIRT) should align their incident response workflow with the three-phase ENISA reporting timeline. Organizations without a PSIRT should establish one before September 2026.

Technical Documentation Requirements

CRA Article 31 and Annex VII specify the technical documentation that manufacturers must compile and maintain. This documentation must be prepared before the product is placed on the market and kept up to date throughout the product's support period. Market surveillance authorities may request the documentation at any time, and the manufacturer must be able to provide it within a reasonable timeframe.

Risk Assessment Evidence

The technical documentation must include a cybersecurity risk assessment that is specific to the product. The risk assessment must identify and evaluate the cybersecurity risks associated with the product, considering its intended use and reasonably foreseeable misuse. It must document the threats, vulnerabilities, and potential impacts considered, the risk treatment decisions made, and the security measures implemented as a result. For automotive components, this risk assessment can draw upon existing TARA work performed under ISO/SAE 21434, but it must be product-specific (not merely a reference to a vehicle-level TARA) and must address the CRA's essential requirements in Annex I.

The risk assessment must be kept up to date. When new threats or vulnerabilities are identified, or when the product is modified in a way that affects its cybersecurity properties, the risk assessment must be reviewed and updated accordingly. This creates an ongoing obligation, not a one-time documentation exercise.

SBOM and Secure Development Lifecycle Records

The CRA requires manufacturers to draw up a Software Bill of Materials (SBOM) documenting at minimum the top-level dependencies of the product's software components. The SBOM must be in a commonly used, machine-readable format. While the CRA does not mandate a specific SBOM format, CycloneDX and SPDX are the two leading standards recognized by ENISA and the broader EU cybersecurity ecosystem. Automotive suppliers already generating SBOMs under OEM contractual requirements or ISO/SAE 21434 Clause 7 supply chain provisions should ensure their existing SBOM processes produce output that meets CRA expectations.

Beyond the SBOM, the technical documentation must include evidence that the product was designed and developed following a secure development lifecycle. This includes design specifications showing how security requirements were derived from the risk assessment, evidence of secure coding practices, static and dynamic analysis results, penetration testing reports, and records of security review at each development milestone. For organizations already following ISO/SAE 21434 cybersecurity engineering processes, much of this evidence already exists. The gap is typically in packaging it in the format and structure that CRA Annex VII expects.

Security Update Commitment (Minimum 5 Years)

Article 13(8) of the CRA requires manufacturers to ensure that vulnerabilities are handled effectively and that security updates are provided for the expected product lifetime or for a period of five years from placing the product on the market, whichever is longer. This minimum five-year commitment must be documented in the technical file and communicated to users at the point of sale.

For automotive components with long vehicle lifetimes (often 15 years or more), this creates a question about support duration. While the CRA mandates a minimum of five years, the "expected product lifetime" criterion could extend this obligation significantly if the product is designed for long-lived automotive applications. Suppliers should clearly define and document the expected product lifetime in their technical documentation and ensure their vulnerability handling processes can sustain the committed support period. The declared support period cannot be shortened after the product is placed on the market.

Post-Market Surveillance Obligations

CRA conformity assessment does not end when the CE marking is affixed. The regulation imposes ongoing post-market surveillance obligations that persist throughout the product's support period. These obligations mirror R155's post-production monitoring requirements in concept but add CRA-specific reporting and corrective action procedures.

Monitoring for New Vulnerabilities

Manufacturers must continuously monitor for vulnerabilities in their products, including vulnerabilities in third-party components identified in the SBOM. This means actively tracking vulnerability databases (NVD, vendor advisories, CERT bulletins), monitoring for exploitation reports related to dependencies, and conducting periodic security assessments of deployed products. For automotive suppliers using open-source components, this requires automated SBOM monitoring tools that correlate known vulnerabilities against the product's dependency tree.

When a new vulnerability is identified, the manufacturer must assess whether it affects a product already on the market, determine the severity and exploitability, and decide on corrective action. If the vulnerability is actively exploited, the ENISA reporting timeline triggers immediately upon awareness.

Corrective Action and Market Withdrawal

If a manufacturer identifies that a product already placed on the market does not conform to CRA essential requirements, the manufacturer must immediately take corrective action to bring the product into conformity, withdraw the product from the market, or recall the product, as appropriate. The manufacturer must inform the market surveillance authority of the non-conformity and the corrective measures taken.

For software-based automotive components, corrective action typically means issuing a security update. The CRA requires that security updates be made available to users free of charge, without undue delay, and with accompanying advisory information including the vulnerability details and user guidance. Security updates must be delivered through a secure channel, and users must be informed about available updates in a timely manner.

Market withdrawal is the most severe corrective action and would apply when a vulnerability cannot be patched or when the product fundamentally fails to meet essential requirements. In the automotive context, this is analogous to a product recall, though the CRA uses market withdrawal terminology. Cooperation with market surveillance authorities is mandatory throughout the corrective action process.

Penalties and Enforcement Scenarios

The CRA establishes a multi-layered enforcement framework with significant penalties for non-compliance. Enforcement is carried out by national market surveillance authorities in each EU member state, coordinated at the EU level.

Administrative Fines (up to €15M / 2.5% turnover)

The CRA provides for administrative fines at three severity levels:

• Up to €15 million or 2.5% of global annual turnover (whichever is higher) for failure to comply with the essential cybersecurity requirements in Annex I, failure to comply with vulnerability handling obligations (Article 13), and failure to comply with conformity assessment requirements.
• Up to €10 million or 2% of global annual turnover for failure to comply with other obligations under the CRA, including technical documentation, CE marking, SBOM, and information duties.
• Up to €5 million or 1% of global annual turnover for supplying incorrect, incomplete, or misleading information to notified bodies and market surveillance authorities.

These fines are calculated against the worldwide annual turnover of the undertaking, not just EU revenues. For large automotive suppliers with global revenues in the tens of billions, the 2.5% threshold represents exposure in the hundreds of millions of euros. The fine levels are comparable to GDPR penalties and signal the EU's intent to treat cybersecurity non-compliance as seriously as data protection violations.

Product Recalls and Market Withdrawal

Beyond financial penalties, market surveillance authorities have the power to order product withdrawal from the market, product recall (retrieving products already sold to end users), prohibition of making the product available on the EU market, and requirement to destroy non-compliant products. For automotive component suppliers, a market withdrawal order halts sales of the affected product across the entire EU single market. If the product is a critical component in OEM vehicle production, the supply chain disruption cascades beyond the direct non-compliance. This secondary impact provides strong commercial motivation for CRA compliance independent of the fine amounts.

Real-World Enforcement Scenarios

While CRA enforcement has not yet begun (full application from December 2027), the enforcement scenarios that automotive suppliers should prepare for include:

• Market surveillance audit: A national authority requests technical documentation for a CRA-scoped product. The manufacturer must provide the complete Annex VII documentation within the requested timeframe. Failure to produce adequate documentation results in a non-conformity finding even if the product itself is technically secure.
• Vulnerability exploitation incident: A vulnerability in an automotive component is actively exploited. The manufacturer fails to report to ENISA within 24 hours. The delayed reporting itself constitutes a CRA violation regardless of the subsequent response quality.
• Missing SBOM: During a market surveillance check, a manufacturer cannot produce a machine-readable SBOM for a product already on the market. This documentation gap triggers non-conformity proceedings.
• Inadequate security update support: A manufacturer discontinues security updates for a product that is still within its declared support period. Users or competitors report the situation to the market surveillance authority, triggering an investigation.
• Misclassification: A manufacturer self-assesses an HSM as a default category product when it should be classified as Important Class II. The assessment is invalid, and the product has been placed on the market without proper conformity assessment, constituting a violation from the date of first market placement.

Timeline — Key Dates for Automotive Suppliers

The CRA introduces obligations on a phased timeline. Automotive suppliers must track these dates and align their compliance programmes accordingly.

Date	Milestone	Supplier Action Required
December 10, 2024	CRA enters into force	Begin product portfolio classification and gap analysis
June 11, 2026	Notified body provisions apply	Identify and engage notified bodies for Class II / Critical products
September 11, 2026	Reporting obligations apply	ENISA 24h/72h/14d vulnerability reporting must be operational
Late 2026 – Early 2027	Expected first harmonized standards (hENs)	Adopt applicable hENs for presumption of conformity (Class I self-assessment)
December 11, 2027	Full CRA application	All CRA requirements enforceable; CE marking required for all in-scope products
Ongoing (post-2027)	Post-market surveillance	Continuous vulnerability monitoring, SBOM maintenance, security updates for declared support period

The September 2026 reporting deadline is the most immediate action item for automotive suppliers. ENISA vulnerability reporting processes must be fully operational by this date, even though full CRA application does not begin until December 2027. Suppliers that do not have a PSIRT or structured vulnerability reporting process today need to establish one within the next few months.

Key Takeaways

• Scope first: Map every product in your portfolio against the CRA exemption for type-approved vehicles. Products placed independently on the EU market, including aftermarket components, standalone software, and dual-use products sold outside OEM type approval, are in CRA scope.
• Classification determines the path: Correctly classify each in-scope product using Annex III and IV. HSMs, secure microcontrollers, and operating systems sold independently require mandatory third-party assessment (Class II). Gateways and network management products are typically Class I. Everything else is default category with self-assessment.
• Harmonized standards are the fast lane: For Class I products, conformity with a harmonized European standard enables self-assessment. Monitor the Official Journal for CRA harmonized standard publications and adopt them as soon as they are available.
• ENISA reporting starts September 2026: This is the first enforceable CRA deadline. Establish a PSIRT, implement a 24h/72h/14d reporting workflow, and test it before the deadline. Do not wait for the December 2027 full application date.
• SBOMs are mandatory: Generate and maintain machine-readable SBOMs for every CRA-scoped product. Use CycloneDX or SPDX format. Automate SBOM generation in your CI/CD pipeline and establish ongoing vulnerability correlation.
• Five-year minimum support commitment: Declare and commit to a security update support period of at least five years (or the expected product lifetime, whichever is longer). Build the operational infrastructure to sustain this commitment.
• Penalties are severe: Fines up to 15 million euros or 2.5% of global annual turnover, plus the possibility of market withdrawal and product recall. CRA non-compliance is not a calculated risk worth taking.
• Reuse R155 and ISO/SAE 21434 work: If you already comply with R155 through OEM supply chains and follow ISO/SAE 21434, much of the underlying cybersecurity engineering work transfers to CRA. The gap is primarily in documentation format, SBOM generation, ENISA reporting, and the formal conformity assessment procedure.