# ISO/SAE 21434 Automotive Cybersecurity: UN R155 Type Approval & CSMS Audits Author: Pacific Certifications Author URL: https://blog.pacificcert.com/author/pacific-certifications/ Published: 2026-10-29 Category: System Certification Category URL: https://blog.pacificcert.com/category/system-certification/ Meta Title: ISO/SAE 21434 Cybersecurity & UN R155 Type Approval Meta Description: Master ISO/SAE 21434 engineering frameworks and UN R155 type approval requirements. Learn how to navigate CSMS audits, TARA, and supply chain security. Tags: ISO/SAE 21434, Automotive Cybersecurity Tag URLs: ISO/SAE 21434 (https://blog.pacificcert.com/tag/isosae-21434/), Automotive Cybersecurity (https://blog.pacificcert.com/tag/automotive-cybersecurity/) URL: https://blog.pacificcert.com/iso-sae-21434-automotive-cybersecurity-r155-csms-compliance/ ![ISO/SAE 21434 Automotive Cybersecurity: UN R155 Type Approval & CSMS Audits](https://prod.superblogcdn.com/site_cuid_cljse4miw184303tp9kqsuho9k/images/isosae-21434-automotive-cybersecurity-un-r155-type-approval-and-csms-audits-1793270108257-compressed.jpg) ## **Introduction** A modern vehicle carries dozens of **electronic** control units, several external connections and software that is updated long after the car leaves the factory. A manufacturer can build a safe, well-engineered vehicle and still be refused sales in a market because it cannot show how it manages cyber risk. UN Regulation No. 155 turned that question into a condition of type approval, and ISO/SAE 21434 became the **engineering** framework most organizations use to answer it. > **Tip**: Review one ECU’s threat analysis, cybersecurity requirements, test evidence and post-launch vulnerability response plan to identify potential assessment gaps. Understand ISO/SAE 21434 Cybersecurity Requirements * * * ## **Regulatory Demands for Vehicle Type Approval** 1. UN R155 is a regulation under the UNECE WP.29 framework requiring vehicle manufacturers to operate a **certified** Cybersecurity Management System (CSMS) and to obtain vehicle type approval that includes cybersecurity. 2. In the EU, the requirements applied to new vehicle types from July 2022 and to all newly **registered** vehicles from July 2024. Other contracting parties, including Japan and South Korea, apply it under their own timelines. 3. ISO/SAE 21434:2021 is an engineering standard covering cybersecurity risk management across the **vehicle** lifecycle. It is widely used as evidence of how R155 requirements are met, though the regulation does not name it as mandatory. 4. A **companion** regulation, UN R156, covers software update management and is often assessed alongside R155. 5. Approval **authorities** and their designated technical services, not the manufacturer, decide whether a CSMS and a vehicle type satisfy the regulation. 6. Suppliers are not **approved** directly under R155, but manufacturers must show they manage supplier-related risks, so requirements flow down contractually. **Topic** **UN R155** **ISO/SAE 21434:2021** Nature Regulation with legal force in adopting markets Voluntary engineering standard Who it addresses Vehicle manufacturers seeking type approval Any organization in the automotive supply chain Main focus Certified CSMS and vehicle type cybersecurity Cybersecurity engineering and risk management across the lifecycle Outcome CSMS certificate of compliance and vehicle type approval Organizational and project evidence, with no regulatory certificate of its own Who assesses Approval authority or its designated technical service Customers, internal audit and voluntary third-party assessment Risk method Requires threat identification and mitigation, with an annex of threat examples Defines a structured TARA with impact and attack feasibility ratings Post-production Monitoring, detection and response required Operations and maintenance, incident response and decommissioning Supplier link Manufacturer must manage supplier risk Cybersecurity interface agreements and distributed activities * * * ## **Scope Across Connected Electronic Architectures** 1. Telematics, infotainment, driver assistance, gateways, powertrain and body control units all fall **within** a realistic scope. 2. **External** interfaces such as cellular, Wi-Fi, Bluetooth, USB, OBD-II and charging connections create entry points. 3. Backend systems, including cloud services, mobile apps and over-the-air update servers, extend the scope **beyond** the vehicle. 4. **Components** developed by suppliers still sit inside the manufacturer's risk picture. 5. Reused software and platform **architectures** carry their cybersecurity history with them, so inherited assumptions need review. 6. **Scope** statements that list only new ECUs, and ignore carry-over parts, are a common source of assessor questions. Define Your Automotive Cybersecurity Assessment Scope * * * ## **Threat Analysis and Risk Assessments (TARA)** 1. Start from a **clear** item definition, including boundaries, interfaces and assumptions. 2. Identify assets and the **cybersecurity** properties that matter for each, such as integrity of braking commands. 3. Link damage **scenarios** to safety, financial, operational and privacy impact. 4. **Describe** threat scenarios and attack paths, using catalogues as inputs but not as replacements for analysis. 5. Rate attack **feasibility** with a documented method, and keep the rating rules consistent across projects. 6. **Determine** risk values and decide on treatment, whether reduce, avoid, share or retain. 7. **Derive** cybersecurity goals and requirements, and trace them to design and verification. 8. Update the **TARA** when the design, threat landscape or field data changes. > **Takeaway:** A TARA is not a document to complete once. Assessors judge it on whether its conclusions visibly drive requirements, tests and later changes. * * * ## **Supply Chain Software Security Oversight** 1. Cybersecurity interface **agreements** should define who does what, including responsibilities for vulnerability handling and incident communication. 2. **Software bills** of materials help identify third-party and open-source components and their known vulnerabilities. 3. Suppliers should be **assessed** for cybersecurity capability, using evidence beyond a questionnaire answer. 4. Update and patch **obligations** over the vehicle's life, which may span many years, should be written into contracts. 5. **Delivery** of test results, TARA inputs and security requirements should be part of acceptance. 6. **Monitoring** of open-source and component advisories needs an owner, not a shared inbox. 7. Flow-down must reach **sub-suppliers** where they provide security-relevant software. Strengthen Automotive Supplier Cybersecurity Controls * * * ## **Post-Production Vulnerability Governance** 1. **Monitoring** should cover threats, vulnerabilities and attacks relevant to the vehicle fleet. 2. **Intake** channels for researchers and customers should be published and staffed. 3. Triage rules should **connect** each reported issue to a risk rating and a response timeline. 4. **Incident** response should define roles, decision rights and communication with authorities and customers. 5. Over-the-air and workshop **update** processes need integrity checks and rollback arrangements. 6. **Fleet-wide** impact assessment should identify which vehicles and variants are affected. 7. Lessons from **incidents** should feed back into the TARA and the development process. 8. **Records** should show that detected issues were handled within the timelines the organization has set for itself. * * * ## **Consultant Built System but Staff Unaware** The weakness shows during the audit: 1. **Process documents** read well, but engineers cannot describe how TARA outcomes reach their requirements. 2. Staff name the **consultant's** templates rather than their own workflow. 3. **Records** expected by the process, such as TARA updates after design changes, are missing or recreated later. 4. **Interviews** with different teams about the same process produce conflicting answers. 5. Roles in the **CSMS** exist on an organization chart but nobody has been trained for them. 6. **Incident** response procedures have never been exercised, so the first test is a real event. 7. The CSMS covers the **headquarters** but not the development sites or suppliers that do the real work. Outside support is not a problem in itself. A system built without genuine engineering ownership is. Strengthen Automotive Cybersecurity Process Ownership * * * ## **Supplier Evaluation Omitted Prior to Purchasing** 1. **Sourcing decisions** made on price and delivery alone, with no cybersecurity criteria in the request for quotation. 2. No record of a supplier's own **development** process, certifications or past incidents. 3. **Components** purchased from distributors with unclear software provenance. 4. Evaluation done once at **selection** and never repeated when the supplier's circumstances change. 5. Missing **cybersecurity** interface agreements, leaving responsibilities undefined. 6. No process to **restrict** or replace suppliers with unresolved security weaknesses. 7. **Purchasing** teams unfamiliar with what the CSMS requires of them. * * * ## **System Architecture Complexity Governing Mandays** Where an approval authority or technical service sets effort for CSMS assessments, these factors typically matter: 1. Number of vehicle types, **platforms** and model lines in scope. 2. Number of **ECUs**, domain controllers and external interfaces. 3. Extent of connected **services** and backend systems. 4. Number of **development**, production and operations sites. 5. **Degree** of distributed development and the number of key suppliers. 6. Volume of **over-the-air** update activity. 7. Maturity of the CSMS, including **findings** from previous assessments. 8. Reuse of **existing** certified processes across similar organizations within a group. Understand UN R155 CSMS Assessment Duration Factors * * * ## **Harmonizing Cybersecurity with Automotive Quality** 1. Existing IATF 16949 or ISO 9001 change control can carry **cybersecurity** impact assessment, so security changes follow the same gates as other changes. 2. Core tools can be **extended**, for example linking cybersecurity risk to FMEA and control plans where safety is affected. 3. **Functional** safety under ISO 26262 and cybersecurity under ISO/SAE 21434 should share interfaces for hazards that overlap. 4. Corrective action and problem-solving **routes** already used for quality escapes can handle security incidents. 5. **Internal audit** programs can add cybersecurity checks to existing schedules. 6. Information security **controls** under ISO/IEC 27001 and TISAX address enterprise security, but they do not replace product cybersecurity engineering. 7. **Shared** records and document control reduce duplicate evidence work. * * * ## **Attaining CSMS Certification for Global Approvals** 1. **Confirm** which markets you sell into and how each approval authority applies R155. 2. **Define** the CSMS scope across organizations, sites, vehicle types and suppliers. 3. **Run** a gap analysis against R155 requirements and, where used, ISO/SAE 21434. 4. **Establish** the processes for risk management, development, supplier oversight, monitoring and incident response. 5. **Train** personnel and run internal audits and an incident exercise. 6. **Engage** the approval authority or its designated technical service for the CSMS assessment. A certificate of compliance is issued by the approval authority and is time-limited, so renewal needs planning. 7. **Obtain** vehicle type approval, which depends on a valid CSMS and on type-specific evidence. 8. **Keep** the CSMS effective through monitoring and any required reassessment. ISO/SAE 21434 itself is not a standard that an accredited certification body issues a management system certificate against. Third-party assessments against it are available, but they are voluntary and different from the R155 CSMS certificate. Understand the UN R155 CSMS Approval Process * * * ## **How Pacific Certifications can help?** UN R155 CSMS certificates are issued through type approval authorities and their designated technical services, and ISO/SAE 21434 is an engineering standard without an accredited management system certification scheme of its own, so organizations should confirm the route required by their market and customers. For the quality and information security foundations that support an automotive cybersecurity program, Pacific Certifications can provide: - Independent ISO 9001 and ISO/IEC 27001 certification audits - Stage 1 documentation and certification-readiness audits - Stage 2 implementation and effectiveness audits - Annual surveillance audits and triennial recertification audits Pacific Certifications conducts impartial audits and does not design, implement or manage cybersecurity programs for its clients, and does not act as an approval authority or technical service under UN R155. * * * ### **Contact Us** To schedule your ISO/SAE 21434 certification, contact us at [**support@pacificcert.com**](mailto:support@pacificcert.com) or +91-8595603096. For training programs on ISO/SAE 21434 certification requirements and preparation, contact us at [**trainings@pacificcert.com**](mailto:trainings@pacificcert.com). Apply for ISO/SAE 21434 Automotive Cybersecurity Assessment Strengthen vehicle cybersecurity, threat and risk management, and regulatory readiness by aligning automotive development processes with ISO/SAE 21434 requirements and supporting UN R155 CSMS compliance. [Apply for ISO/SAE 21434 Assessment](https://pacificcert.com/contact-us/) **Read More at:** [ISO certifications for automotive industry](https://pacificcert.com/iso-certifications-for-automotive-industry/) ![Pacific Certifications ](https://prod.superblogcdn.com/site_cuid_cljse4miw184303tp9kqsuho9k/images/pacific-certifications-1791368593127-compressed.png) ## FAQs Q: Is ISO/SAE 21434 mandatory? A: Not as a standard. UN R155 is the legal requirement, and ISO/SAE 21434 is a widely used way to structure the engineering evidence. Q: Who issues the CSMS certificate? A: The approval authority of the relevant market, usually through a designated technical service, not an ordinary ISO certification body. Q: Do suppliers need an R155 certificate? A: No. The manufacturer holds it. Suppliers are, however, expected by customers to show cybersecurity capability, often through ISO/SAE 21434 practices and assessments. Q: What is the difference between R155 and R156? A: R155 covers cybersecurity management, and R156 covers software update management, including over-the-air updates. Q: Does TISAX or ISO 27001 satisfy R155? A: No. They address information security of the organization, while R155 and ISO/SAE 21434 address cybersecurity of the vehicle and its lifecycle. --- This blog is powered by Superblog. Visit https://superblog.ai to know more. ---