UNECE R155 Type Approval: What OEMs Need to Know

UNECE Regulation No. 155 (R155) represents the most significant regulatory shift in automotive cybersecurity history. Since July 2024, every new vehicle sold in the 64 UNECE contracting parties — including the entire European Union, Japan, South Korea, and Australia — must demonstrate compliance with R155 cybersecurity requirements as a precondition for type approval. For OEMs and their Tier-1 suppliers, this is no longer a future concern: it is an active enforcement reality.

This article breaks down exactly what R155 type approval entails, how the process works step by step, what evidence you need to produce, and where teams most commonly fail.

1. R155 in the Regulatory Landscape

R155 was adopted in June 2020 by WP.29, the United Nations World Forum for Harmonization of Vehicle Regulations. It sits within a broader ecosystem of automotive cybersecurity regulations and standards that every OEM must navigate.

R155 and R156: The Twin Pillars

R155 governs Cyber Security Management Systems (CSMS). Its companion regulation, R156, governs Software Update Management Systems (SUMS). Together, they require OEMs to demonstrate both that vehicles are protected against cybersecurity threats and that software updates are managed securely throughout the vehicle lifecycle. Type approval authorities increasingly assess them in tandem, and OEMs should prepare evidence packages that address both regulations simultaneously.

Relationship to ISO/SAE 21434

While R155 defines what must be achieved, ISO/SAE 21434 defines how to achieve it. The regulation explicitly references ISO/SAE 21434 as a suitable framework for demonstrating compliance. A conformant ISO/SAE 21434 implementation provides the process evidence that R155 auditors expect, covering cybersecurity governance, threat analysis and risk assessment (TARA), secure development, production, operations, and decommissioning. However, ISO/SAE 21434 compliance alone does not guarantee R155 approval — the regulation has its own specific requirements, particularly around the Annex 5 threat catalog.

EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act, adopted in 2024, introduces horizontal cybersecurity requirements for all products with digital elements sold in the EU. While motor vehicles are explicitly excluded from CRA scope (they fall under R155), aftermarket components, connected accessories, and standalone software products sold separately may be subject to CRA. OEMs and suppliers must carefully assess which of their products fall under R155 versus CRA, particularly for components like aftermarket telematics units, mobile companion apps, and cloud backend services.

China GB 44495

China has developed its own mandatory national standard, GB 44495, for vehicle cybersecurity. While conceptually similar to R155, GB 44495 includes China-specific requirements around data localization, cross-border data transfer restrictions, and additional technical requirements for connected vehicles operating in China. OEMs selling in both UNECE and Chinese markets must maintain compliance programs that address both regulatory frameworks, which often require separate evidence packages and audit processes.

2. The Two Pillars: CSMS Certificate and Vehicle Type Approval

R155 compliance operates on two distinct levels that are often conflated but must be understood separately:

Pillar 1: CSMS Certificate of Compliance

The CSMS certificate is an organizational-level approval. It confirms that the OEM has established and maintains processes to manage cybersecurity across the vehicle lifecycle. The CSMS covers:

• Cybersecurity governance: Defined roles, responsibilities, and competencies for cybersecurity across the organization.
• Risk management processes: Systematic identification, assessment, and treatment of cybersecurity risks for vehicle projects.
• Secure engineering: Development processes that incorporate security by design, including secure coding, testing, and verification.
• Supply chain management: Processes to ensure suppliers and service providers meet cybersecurity requirements.
• Incident response: Monitoring, detection, and response capabilities for cybersecurity incidents affecting vehicles in the field.
• Post-production management: Ongoing vulnerability monitoring, patch management, and cybersecurity updates throughout the vehicle lifetime.

A CSMS certificate is valid for three years and must be renewed through re-audit. It is a prerequisite for any vehicle type approval under R155.

Pillar 2: Vehicle Type Approval

The vehicle type approval is a product-level approval. It confirms that a specific vehicle type has been developed and assessed in accordance with the certified CSMS, and that adequate cybersecurity measures are implemented. This requires demonstrating:

• A complete TARA has been performed for the vehicle type.
• Identified risks have been appropriately mitigated.
• The vehicle architecture implements adequate protections.
• Cybersecurity testing and validation have been completed.
• Post-production cybersecurity measures are in place.

A common misconception is that obtaining the CSMS certificate means vehicles are automatically approved. The CSMS certificate is necessary but not sufficient — each vehicle type must still be individually assessed and approved by the type approval authority.

3. The Type Approval Process Step by Step

Step 1: CSMS Audit by Approval Authority

The OEM applies to a type approval authority (TAA) in any UNECE contracting party. The TAA — or a designated technical service acting on its behalf — audits the OEM’s cybersecurity management system. This audit evaluates:

• Documented cybersecurity policies and processes
• Organizational structure and competency evidence
• Risk assessment methodology and criteria
• Development lifecycle integration
• Supplier management procedures
• Incident monitoring and response capabilities
• Evidence from completed or ongoing vehicle projects demonstrating process implementation

The audit typically involves document review, on-site interviews with engineering and management staff, and examination of project-level evidence. Expect the initial CSMS audit to take 3–6 months from application to certificate issuance, depending on organizational readiness and the TAA’s workload.

Step 2: Vehicle Type Assessment

With a valid CSMS certificate, the OEM submits a vehicle type for approval. The submission package must include:

1. System description: Complete architecture documentation including all ECUs, communication networks, external interfaces, and connectivity features.
2. TARA results: Threat analysis and risk assessment covering all relevant components, with clear traceability from threats to mitigations.
3. Risk treatment evidence: Documentation of implemented security measures and their effectiveness, including testing results.
4. Annex 5 coverage: Explicit mapping demonstrating how each applicable threat and mitigation in the R155 Annex 5 catalog has been addressed.
5. Post-production plan: Cybersecurity monitoring strategy, vulnerability management procedures, and update capabilities for the vehicle type.

The technical service reviews this package, may request additional evidence or clarification, and may perform independent testing or verification of specific claims.

Step 3: Approval Decision

Based on the CSMS certificate status and the vehicle type assessment, the TAA issues one of three outcomes:

• Approval granted: The vehicle type receives an R155 type approval number, and production can proceed.
• Conditional approval: Approval with conditions that must be met within a specified timeframe, typically for minor gaps.
• Approval refused: Significant gaps identified. The OEM must remediate and resubmit.

Once approved, the OEM must maintain compliance. Any significant change to the vehicle type’s cybersecurity architecture requires reassessment. The TAA may also conduct surveillance activities to verify ongoing compliance.

4. R155 Annex 5: The Threat Catalog

Annex 5 of R155 is one of the most operationally demanding elements of the regulation. It provides a structured catalog of threats and corresponding mitigations organized into seven categories:

Threat Categories

1. Threats regarding back-end servers: Attacks on OEM backend systems that could affect vehicles, including data breaches, unauthorized access, and service disruption.
2. Threats regarding communication channels: Man-in-the-middle attacks, message spoofing, eavesdropping, and session hijacking on V2X, telematics, and diagnostic communication.
3. Threats regarding update procedures: Compromise of software update packages, update servers, or the update mechanism itself.
4. Threats regarding unintended human actions: Social engineering, insider threats, and accidental exposure of sensitive data or credentials.
5. Threats regarding external connectivity: Exploitation of APIs, connected services, third-party applications, and external interfaces.
6. Threats regarding vehicle data and code: Extraction of firmware, reverse engineering, manipulation of calibration data, and unauthorized access to stored personal data.
7. Threats regarding vehicle physical systems: Hardware tampering, sensor spoofing, fault injection, and physical access exploitation.

Working with Annex 5

The Annex 5 catalog is not a checklist to be satisfied mechanically. OEMs must demonstrate that their TARA process has considered each threat category and either identified it as applicable (with corresponding mitigations) or justified why it is not relevant to the specific vehicle type. The technical service will scrutinize dismissals — simply stating “not applicable” without technical justification is insufficient.

For each applicable threat, the OEM must show that at least one mitigation from the catalog (or an equivalent measure) has been implemented and verified. The traceability chain runs from Annex 5 threat, through the TARA, to the security requirement, to the implemented control, to the test result confirming effectiveness.

5. Supply Chain Requirements

R155 places cybersecurity obligations squarely on the OEM as the entity seeking type approval. However, the regulation explicitly requires the OEM to manage cybersecurity risks across the entire supply chain. In practice, this means:

Supplier Cybersecurity Requirements

• Contractual obligations: Suppliers must be contractually required to implement cybersecurity processes consistent with the OEM’s CSMS. This includes secure development practices, vulnerability disclosure, and incident notification.
• TARA contributions: Tier-1 suppliers are expected to perform component-level TARAs that feed into the OEM’s vehicle-level assessment. The OEM must verify these TARAs meet their quality standards.
• Vulnerability management: Suppliers must provide ongoing vulnerability monitoring and timely security patches for their components throughout the agreed support period.
• Evidence packages: Suppliers must provide cybersecurity evidence packages (development interface agreements, test reports, SBOM data) that the OEM can incorporate into their type approval submission.

Cascading Requirements

The supply chain obligations cascade: Tier-1 suppliers must impose equivalent requirements on their Tier-2 suppliers, and so on. The OEM retains overall responsibility but must demonstrate that their supplier management processes effectively propagate and verify cybersecurity requirements through the chain.

Supply chain gaps are among the top reasons for type approval delays. Start supplier alignment early — ideally during concept phase — and include cybersecurity deliverables in procurement contracts from the outset.

6. Common Pitfalls

Having supported multiple OEMs and Tier-1 suppliers through R155 compliance, we consistently see the same failure patterns:

Treating CSMS as a Documentation Exercise

Some OEMs create comprehensive policy documents that describe ideal processes but cannot demonstrate actual implementation. Auditors will ask for project-level evidence — specific TARAs, actual incident reports, real supplier assessments. If the processes exist only on paper, the CSMS audit will fail.

Incomplete Annex 5 Coverage

Teams frequently miss threat categories that seem outside their immediate scope. Backend server threats are commonly overlooked by vehicle engineering teams who consider cloud infrastructure “someone else’s problem.” The technical service will expect comprehensive coverage regardless of internal organizational boundaries.

Inadequate Traceability

The traceability chain from threat to mitigation to test evidence must be unbroken. Gaps typically occur at the interfaces: the TARA identifies a threat, a security requirement is written, but the mapping between the requirement and the implemented control is missing or ambiguous. Similarly, test reports may demonstrate that a control functions correctly but fail to link back to the specific threat it addresses.

Underestimating Post-Production Requirements

R155 requires cybersecurity monitoring and response capabilities that extend throughout the vehicle’s lifetime. OEMs that focus exclusively on development-phase compliance often have weak plans for field monitoring, vulnerability triage, and security update deployment. The TAA will assess whether the OEM has realistic capabilities, not just plans on paper.

Late Supplier Engagement

Waiting until the type approval submission is imminent to request cybersecurity evidence from suppliers creates critical-path delays. Suppliers need lead time to produce TARAs, SBOM data, test reports, and vulnerability assessments. Some suppliers may lack the cybersecurity maturity to produce adequate evidence, requiring capacity building or alternative sourcing.

Ignoring Cross-Regulation Dependencies

OEMs selling in multiple markets often treat R155, GB 44495, and other regulations as entirely separate workstreams. This leads to duplicated effort and inconsistent evidence packages. A unified compliance framework that maps requirements across regulations and produces evidence once, used many times, is significantly more efficient.

7. How ThreatZ Supports R155 Compliance

ThreatZ was designed from the ground up to support the specific evidence requirements of R155 type approval:

Automated TARA with Annex 5 Mapping

ThreatZ generates comprehensive TARA from your vehicle architecture model and automatically maps identified threats to the R155 Annex 5 catalog. The platform highlights coverage gaps and ensures every applicable threat category has been addressed, eliminating the manual cross-referencing that plagues spreadsheet-based approaches.

End-to-End Traceability

Every element in ThreatZ — from asset through threat through security goal through security requirement through control through test case — is linked in a navigable graph. This traceability chain is exactly what technical services require during vehicle type assessment, and ThreatZ can generate the evidence package documentation directly from the graph.

SBOM-Driven Vulnerability Monitoring

ThreatZ integrates SBOM management with continuous vulnerability monitoring. When new CVEs are published affecting components in your vehicle’s software bill of materials, ThreatZ automatically correlates them to your TARA and flags affected security assessments for review. This directly supports the post-production monitoring requirements of R155.

Supply Chain Collaboration

ThreatZ provides structured workflows for suppliers to contribute component-level TARAs, security evidence, and SBOM data into the OEM’s vehicle-level assessment. Role-based access controls ensure suppliers see only their scope while the OEM maintains a unified view across the entire vehicle.

Multi-Regulation Support

A single ThreatZ project can generate compliance evidence mapped to R155, ISO/SAE 21434, GB 44495, and other applicable regulations. Perform the analysis once and produce tailored reports for each regulatory framework, avoiding the duplication trap that slows down multi-market OEMs.

8. Key Takeaways

• R155 is mandatory now: Since July 2024, all new vehicles in UNECE contracting parties require R155 type approval. There is no grace period remaining for new vehicle types.
• Two approvals required: OEMs need both a CSMS certificate (organizational) and vehicle type approval (product). The CSMS certificate is a prerequisite, valid for three years, and must be maintained through ongoing compliance.
• ISO/SAE 21434 is necessary but not sufficient: While ISO/SAE 21434 provides the process framework that R155 auditors expect, OEMs must also address regulation-specific requirements, particularly the Annex 5 threat catalog.
• Annex 5 demands rigorous mapping: Every applicable threat category must be addressed with traceable mitigations. Unjustified dismissals will be challenged by technical services.
• Supply chain management is critical: The OEM bears ultimate responsibility, but compliance depends on cybersecurity evidence from the entire supplier chain. Engage suppliers early and contractually.
• Post-production requirements persist: R155 compliance does not end at type approval. Ongoing vulnerability monitoring, incident response, and update capabilities must be maintained throughout the vehicle lifetime.
• Multi-market complexity requires unified tooling: OEMs operating across R155, GB 44495, and other regulatory frameworks should invest in platforms that map requirements across regulations to avoid duplicated effort and inconsistent evidence.