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.
Regulatory Demands for Vehicle Type Approval
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.
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.
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.
A companion regulation, UN R156, covers software update management and is often assessed alongside R155.
Approval authorities and their designated technical services, not the manufacturer, decide whether a CSMS and a vehicle type satisfy the regulation.
Suppliers are not approved directly under R155, but manufacturers must show they manage supplier-related risks, so requirements flow down contractually.
Scope Across Connected Electronic Architectures
Telematics, infotainment, driver assistance, gateways, powertrain and body control units all fall within a realistic scope.
External interfaces such as cellular, Wi-Fi, Bluetooth, USB, OBD-II and charging connections create entry points.
Backend systems, including cloud services, mobile apps and over-the-air update servers, extend the scope beyond the vehicle.
Components developed by suppliers still sit inside the manufacturer's risk picture.
Reused software and platform architectures carry their cybersecurity history with them, so inherited assumptions need review.
Scope statements that list only new ECUs, and ignore carry-over parts, are a common source of assessor questions.
Threat Analysis and Risk Assessments (TARA)
Start from a clear item definition, including boundaries, interfaces and assumptions.
Identify assets and the cybersecurity properties that matter for each, such as integrity of braking commands.
Link damage scenarios to safety, financial, operational and privacy impact.
Describe threat scenarios and attack paths, using catalogues as inputs but not as replacements for analysis.
Rate attack feasibility with a documented method, and keep the rating rules consistent across projects.
Determine risk values and decide on treatment, whether reduce, avoid, share or retain.
Derive cybersecurity goals and requirements, and trace them to design and verification.
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
Cybersecurity interface agreements should define who does what, including responsibilities for vulnerability handling and incident communication.
Software bills of materials help identify third-party and open-source components and their known vulnerabilities.
Suppliers should be assessed for cybersecurity capability, using evidence beyond a questionnaire answer.
Update and patch obligations over the vehicle's life, which may span many years, should be written into contracts.
Delivery of test results, TARA inputs and security requirements should be part of acceptance.
Monitoring of open-source and component advisories needs an owner, not a shared inbox.
Flow-down must reach sub-suppliers where they provide security-relevant software.
Post-Production Vulnerability Governance
Monitoring should cover threats, vulnerabilities and attacks relevant to the vehicle fleet.
Intake channels for researchers and customers should be published and staffed.
Triage rules should connect each reported issue to a risk rating and a response timeline.
Incident response should define roles, decision rights and communication with authorities and customers.
Over-the-air and workshop update processes need integrity checks and rollback arrangements.
Fleet-wide impact assessment should identify which vehicles and variants are affected.
Lessons from incidents should feed back into the TARA and the development process.
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:
Process documents read well, but engineers cannot describe how TARA outcomes reach their requirements.
Staff name the consultant's templates rather than their own workflow.
Records expected by the process, such as TARA updates after design changes, are missing or recreated later.
Interviews with different teams about the same process produce conflicting answers.
Roles in the CSMS exist on an organization chart but nobody has been trained for them.
Incident response procedures have never been exercised, so the first test is a real event.
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.
Supplier Evaluation Omitted Prior to Purchasing
Sourcing decisions made on price and delivery alone, with no cybersecurity criteria in the request for quotation.
No record of a supplier's own development process, certifications or past incidents.
Components purchased from distributors with unclear software provenance.
Evaluation done once at selection and never repeated when the supplier's circumstances change.
Missing cybersecurity interface agreements, leaving responsibilities undefined.
No process to restrict or replace suppliers with unresolved security weaknesses.
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:
Number of vehicle types, platforms and model lines in scope.
Number of ECUs, domain controllers and external interfaces.
Extent of connected services and backend systems.
Number of development, production and operations sites.
Degree of distributed development and the number of key suppliers.
Volume of over-the-air update activity.
Maturity of the CSMS, including findings from previous assessments.
Reuse of existing certified processes across similar organizations within a group.
Harmonizing Cybersecurity with Automotive Quality
Existing IATF 16949 or ISO 9001 change control can carry cybersecurity impact assessment, so security changes follow the same gates as other changes.
Core tools can be extended, for example linking cybersecurity risk to FMEA and control plans where safety is affected.
Functional safety under ISO 26262 and cybersecurity under ISO/SAE 21434 should share interfaces for hazards that overlap.
Corrective action and problem-solving routes already used for quality escapes can handle security incidents.
Internal audit programs can add cybersecurity checks to existing schedules.
Information security controls under ISO/IEC 27001 and TISAX address enterprise security, but they do not replace product cybersecurity engineering.
Shared records and document control reduce duplicate evidence work.
Attaining CSMS Certification for Global Approvals
Confirm which markets you sell into and how each approval authority applies R155.
Define the CSMS scope across organizations, sites, vehicle types and suppliers.
Run a gap analysis against R155 requirements and, where used, ISO/SAE 21434.
Establish the processes for risk management, development, supplier oversight, monitoring and incident response.
Train personnel and run internal audits and an incident exercise.
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.
Obtain vehicle type approval, which depends on a valid CSMS and on type-specific evidence.
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.
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 or +91-8595603096.
For training programs on ISO/SAE 21434 certification requirements and preparation, contact us at trainings@pacificcert.com.
Read More at: ISO certifications for automotive industry
