Automotive Cybersecurity Guide: ISO/SAE 21434 and UN R155

A modern vehicle is a network of dozens of computers on internal buses that trust every message, connected to cellular, Bluetooth, charging and diagnostic interfaces that attackers can reach. Since UN Regulations No. 155 (R155) and No. 156 (R156) became conditions of type approval in the EU and other markets, a manufacturer that cannot evidence a working cybersecurity management system cannot sell new vehicles there. This guide explains what R155, R156, ISO/SAE 21434 and ISO 24089 each require, how threat analysis and risk assessment (TARA) works, which in-vehicle controls matter most, and how to monitor a fleet after sale. It is written for product security leads at manufacturers and suppliers, architects moving into automotive from IT or OT, and assessors.

Key takeaways

• Regulation sets the "what", the standard sets the "how". R155 requires a certified cybersecurity management system (CSMS) and a risk-assessed vehicle type; ISO/SAE 21434 is the engineering standard most manufacturers use to produce the evidence.
• The obligation continues after sale. R155 requires continual monitoring of vehicles after first registration, timely mitigation, and a report to the approval authority at least once a year.
• Internal buses trust everything by default. Thieves have used CAN injection; message authentication (AUTOSAR SecOC), segmentation and allowlisting gateways are the core in-vehicle defences.
• The update path is the most powerful attack path. R156 requires a software update management system (SUMS) and safe failure recovery; Uptane-style designs stop one key or server compromise becoming a fleet compromise.
• Keys and credentials decide the outcome. Shared symmetric keys, open debug ports and leaked back-end credentials turn one compromised vehicle or laptop into many.

Why vehicles are a different security problem

• Safety comes first: ISO/SAE 21434 rates impact in four categories (safety, financial, operational, privacy), with the safety rating derived from ISO 26262.
• Buses without authentication: a Controller Area Network (CAN) frame carries an identifier and data but nothing proving which electronic control unit (ECU) sent it. Anything spliced into the wiring can transmit frames other ECUs will act on. CAN FD, LIN, FlexRay and automotive Ethernet often coexist in one vehicle.
• Long life in hostile hands: vehicles stay in service for over a decade, physically accessible to thieves and workshops.
• Deep supply chains: most ECUs come from Tier 1 and Tier 2 suppliers, and R155 paragraph 7.2.2.5 requires the manufacturer to show how its CSMS manages those dependencies.
• Back ends are part of the vehicle: telematics, mobile apps, OTA servers and charging networks can command cars. R155 Annex 5 lists back-end servers as the first threat category.

The canonical demonstration remains Charlie Miller and Chris Valasek's 2015 research on an unaltered 2014 Jeep Cherokee. The head unit exposed a D-Bus service on TCP port 6667, reachable over the Sprint cellular network; they then reflashed the chip that bridges to the CAN buses, which performed no firmware signature check, and sent arbitrary CAN messages. The resulting recall covered 1.4 million vehicles.

The regulatory and standards landscape

R155 and R156 are UN Regulations under the 1958 Agreement, administered by the UNECE World Forum for Harmonisation of Vehicle Regulations (WP.29), and entered into force in January 2021. In the EU, compliance has been required for new vehicle types since July 2022 and for all new vehicles sold since July 2024, including older types still in production. Japan and Korea are following similar timelines.

ISO/SAE 21434 was published in August 2021; ISO now lists it as "to be revised", so check which edition your contracts reference.

What R155 and R156 require in practice

R155: the CSMS and the vehicle type

Paragraph 7.2.2.2 lists the processes the CSMS must contain, which in practice become the audit agenda: (a) organisational cybersecurity management; (b) risk identification covering at least the threats in Annex 5 Part A; (c) risk assessment, categorisation and treatment; (d) verification that risks are managed; (e) testing; (f) keeping the risk assessment current; (g) monitoring, detecting and responding to attacks, threats and vulnerabilities; and (h) providing data to analyse attacks.

For each vehicle type, paragraph 7.3 requires an exhaustive risk assessment including interactions with external systems, proportionate mitigations drawn from Annex 5 Parts B and C or justified alternatives, a secured environment for any aftermarket software or services, testing before approval, detection and forensic data capability, and cryptographic modules that follow consensus standards. The CSMS certificate is valid for at most three years, and paragraph 7.4.1 requires monitoring outcomes to be reported at least once a year.

R156: the SUMS and safe updates

• RXSWIN: a manufacturer-defined identifier for type-approval-relevant software. It must be unique, readable in a standardised way at least through the OBD port, protected against unauthorised modification, and tracked in an auditable register.
• Protection: updates and the update process must be protected against manipulation, and the vehicle must verify update authenticity and integrity.
• Safe execution: a failed or interrupted update must restore the previous version or reach a safe state; updates run only with enough power to finish; if updating while driving could be unsafe, the vehicle must not be drivable during the update.
• Change impact: each update is assessed for effects on type-approved systems, and users are informed before and after.

Threat analysis and risk assessment under ISO/SAE 21434

TARA connects regulation to design. ISO/SAE 21434 describes the methods in Clause 15; they are applied to an "item" (a vehicle-level function or system) in the concept phase and revisited through the lifecycle, including when a new CVE affects an installed component. Published descriptions agree on six activities:

1. Asset identification: assets and the property at stake (confidentiality, integrity, availability and related properties). A compromised property gives a damage scenario.
2. Threat scenario identification: for example spoofing brake-request frames, or replaying an unlock command from the telematics back end.
3. Impact rating: severe, major, moderate or negligible for safety, financial, operational and privacy impact, assessed for road users rather than the manufacturer.
4. Attack path analysis: the routes an attacker would take, such as modem to head unit to gateway to chassis bus.
5. Attack feasibility rating: high, medium, low or very low, using attack potential (elapsed time, expertise, knowledge of the item, window of opportunity, equipment), attack vector, or CVSS exploitability.
6. Risk value determination: impact and feasibility combined into a value from 1 to 5 using a matrix defined in advance.

Each risk is avoided, reduced, shared or retained. Reductions become cybersecurity goals (for example "prevent unauthorised modification of steering torque requests"), retained or shared risks become cybersecurity claims, and goals are refined into technical requirements allocated to ECUs. The informative Annex E defines four Cybersecurity Assurance Levels (CAL 1 to CAL 4), usually set per goal from impact and attack vector. A CAL sets the rigour and independence of verification, not which controls are needed, and binds a supplier only when the OEM's specification or Cybersecurity Interface Agreement says so.

Attack surfaces and controls

The table maps R155 Annex 5 Part A threat categories to observed attacks and the controls used against them, with NHTSA practice numbers where the 2022 guidance states the control directly.

In-vehicle network defences

• SecOC: AUTOSAR Secure Onboard Communication adds a truncated message authentication code and freshness value so the receiver can verify the sender and reject replays. Common profiles use AES-128 CMAC truncated to 24 or 28 bits for classic CAN; AUTOSAR notes that 64 bits and above is generally considered sufficient against guessing, so short truncation needs expert judgement. CAN FD and Ethernet leave room for longer tags.
• Why it matters: in a 2023 Toyota RAV4 theft investigated by Ken Tindell of Canis Automotive Labs and researcher Ian Tabor, thieves reached the CAN bus through headlamp wiring and sent frames impersonating the smart key receiver to unlock the car and disable the immobiliser. The receiving ECUs trusted the frames because nothing authenticated them.
• Gateways and segmentation: isolate ECUs with wireless interfaces from braking, steering and propulsion domains, filter by allowlist, and keep critical safety signals unreachable from external interfaces [T.10].
• Diagnostics: restrict powerful UDS (ISO 14229) services to defined operating modes [T.6], limit harm from misuse (for example only at low speed) [T.7], avoid global symmetric keys [T.8], and replace legacy SecurityAccess (service 0x27) seed-key schemes with certificate-based Authentication (service 0x29) where ECUs support it.
• Keyless entry: relay attacks extend the range between fob and car. Thatcham Research tests for them in its consumer security ratings and in 2019 called sleeping, motion-sensing fobs "a good short-term option", urging manufacturers to design the vulnerability out.

Charging and V2X

• EV charging: charge points talk to their management system over OCPP. Security profile 1 uses HTTP Basic authentication without a secure channel and suits only trusted networks; profile 2 adds TLS with a server certificate; profile 3 uses TLS with client certificates on both sides and should be the default for new deployments. OCPP 2.0.1 and 2.1 are approved as IEC 63584. Vehicle-to-charger communication is defined in ISO 15118, whose 2026 amendment to Part 20 includes an "improved security concept".
• V2X: basic safety messages, broadcast up to ten times a second, are digitally signed and verified before use. The US Security Credential Management System design, developed by the Crash Avoidance Metrics Partners under a USDOT cooperative agreement, issues batches of short-lived pseudonym certificates to limit tracking, and uses a Misbehavior Authority and revocation lists to remove bad actors.

Secure software updates and OTA

An OTA platform can change every vehicle in a fleet, so its design must assume something in the chain will be compromised. Uptane, built on The Update Framework (TUF), is the reference design:

• Two repositories: the Image repository holds signed images from the OEM and suppliers, is mainly human-controlled and changes rarely, so its keys can stay offline. The Director repository is online and automated, and tells each vehicle what to install from an inventory of vehicles, ECUs and versions.
• Verification: the Primary ECU downloads metadata for itself and its Secondaries and must perform full verification (Director and Image metadata agree); constrained Secondaries may use partial verification.
• Named attacks: freeze (countered by metadata expiry), rollback (version checks), mix-and-match of incompatible images (Snapshot metadata) and arbitrary software (signature thresholds, so one stolen key cannot push code).

Map these to R156 evidence: metadata verification for authenticity and integrity, A/B partitions or retained images for failure recovery, charge and gear interlocks for safe execution, and the Director inventory as the source for the RXSWIN register. NHTSA [G.10] and [G.11] add a practical test: track software per ECU and per vehicle so that affected vehicles can be identified quickly when a vulnerability is published.

Where identity fits

Most controls above reduce to managing machine identities: ECU keys, vehicle and charger certificates, OTA signing keys, diagnostic tool credentials and back-end service accounts.

• Per-vehicle keys: NHTSA [T.5] says a credential from one vehicle "should not provide access to other vehicles". Inject unique keys at end-of-line. See the Device and IoT Identity Guide.
• Long-lived PKI: plan certificate renewal over the air and revocation for assets that outlive most CA hierarchies. See the Machine Identity, PKI and Certificate Lifecycle Guide.
• Signing keys: keep root and Image repository keys offline in HSMs with multi-person ceremonies. See the Cryptographic Key Management Guide.
• Back-end credentials: the Toyota T-Connect key exposure left a connected-service access key on public GitHub for five years, and the Mercedes-Benz GitHub token exposure opened internal source code through one employee's repository. Both fall in R155's back-end threat category. See the Secrets Management Guide.
• Workshop and supplier access: tools that can reprogram ECUs need authenticated, logged, revocable access [T.9]. See the Third-Party Access Guide.

Monitoring the fleet

R155 requires monitoring to be continual, to include vehicles after registration, to respect privacy, and to feed both timely mitigation and the annual report. Most manufacturers run a vehicle security operations centre (VSOC) correlating on-board intrusion detection events, back-end logs and external intelligence such as supplier advisories, CVE feeds and Auto-ISAC sharing.

• On the vehicle: SecOC verification failures per message ID, unexpected diagnostic sessions and 0x27/0x29 failures, gateway filter drops, secure boot failures, update verification failures and RXSWIN changes. Paragraph 7.3.7 expects forensic capability, so plan retention.
• In the back end: every remote command with the requesting identity, OTA approvals and signing events, anomalous API volumes per account or vehicle, and charger authentication failures.

Metrics that show the programme works:

• Vulnerability response time: median days from a relevant CVE or report to a deployed fix, by severity.
• OTA reach: share of affected in-service vehicles on fixed software 30 and 90 days after a security campaign.
• TARA currency: share of in-production vehicle types whose TARA was reviewed in the last 12 months or after the last significant change.
• Supplier coverage: share of ECU suppliers with a signed Cybersecurity Interface Agreement and a vulnerability-handling contact.
• Key hygiene: ECU types still using shared symmetric keys or unlocked debug interfaces in production.

Implementing a programme

1. Scope the obligations: markets, vehicle categories, approval dates and the suppliers whose parts are in scope.
2. Stand up the CSMS: accountable roles, the eight paragraph 7.2.2.2 processes, and ISO/SAE 21434 as the method. Consider a pre-assessment with your technical service before the formal audit.
3. Fix supplier contracts: Cybersecurity Interface Agreements, CAL expectations, SBOM delivery and vulnerability notification times. Supplier evidence feeds every vehicle-type risk assessment, so start here.
4. Pilot TARA on one connected platform: calibrate impact and feasibility tables with safety engineers and reuse the result as a template.
5. Close the highest risks in architecture: segmentation, allowlisting gateways, SecOC on safety-relevant messages, secure boot, locked debug ports, per-vehicle keys and certificate-based diagnostics.
6. Build the SUMS and OTA chain, then test in rings: bench ECUs, test fleet, employee vehicles, then staged customer cohorts with a halt criterion such as a failure rate above an agreed threshold. Rollback is the retained previous image or a signed campaign that re-issues it; rehearse both.
7. Test before approval: penetration test vehicle, back end and apps against the TARA attack paths, fuzz exposed protocols, and track findings to closure as paragraph 7.3.6 evidence.
8. Operate: run the VSOC, keep TARAs current and produce the annual report from operational data.

Choosing your approach

• OEMs own the CSMS certificate, vehicle-level TARA and SUMS. Invest first in supplier governance and the update chain, which scale risk fleet-wide.
• Tier 1 suppliers are asked for component TARA, CAL-appropriate verification, SBOMs and incident response.
• Smaller suppliers should reuse AUTOSAR security modules and established TARA tooling, and negotiate a proportionate Cybersecurity Interface Agreement.
• Fleet operators, charging networks and aftermarket vendors hold no type approval but are part of the attack surface: focus on device identity, OCPP profile 3, account security for remote commands and authenticated connections to vehicles [G.41 to G.43].
• TISAX is not product security: AL2 assessments use plausibility checks and evidence review, AL3 adds on-site inspection, and results last three years, but none of it assesses the vehicle. You need both.

Common failure patterns

• Paper CSMS: processes written for the audit while monitoring and TARA updates do not run, leaving the annual report empty and the certificate at risk.
• Fleet-wide secrets: one symmetric key or seed-key algorithm across a model line, so extracting it from one ECU unlocks every vehicle of that type.
• Trusting the bus: SecOC on a few messages while the frames that unlock, start or steer remain unauthenticated, as the RAV4 case showed.
• Unchecked update paths: a bridge chip accepting unsigned firmware, the step that turned head-unit access into vehicle control in the Jeep research.
• Ignoring production IT: R155 covers the production phase. The Jaguar Land Rover cyberattack halted global production, a reminder that plant, key injection and end-of-line systems need the same rigour as the vehicle.
• Debug left open: JTAG or UART reachable on production boards behind hidden connectors, which NHTSA says is not sufficient.

Framework mapping

Practitioner checklist

• Document the eight R155 paragraph 7.2.2.2 processes and evidence that each one runs.
• Sign Cybersecurity Interface Agreements, with SBOM and vulnerability notification terms, with every ECU supplier.
• Maintain a TARA per vehicle type, with impact and feasibility tables agreed with safety engineering.
• Authenticate safety-relevant messages with SecOC and filter between segments by allowlist.
• Eliminate fleet-wide keys, lock debug interfaces and move diagnostics to certificate-based authentication.
• Sign updates with offline, threshold-protected keys, enforce anti-rollback and rehearse failure recovery.
• Keep an RXSWIN and per-ECU software inventory that answers "which vehicles are affected?" within hours.
• Vault, scope and rotate every back-end credential that can reach vehicles or OTA infrastructure.

Standards and references

• EUR-Lex: UN Regulation No 155, Cyber security and cyber security management system
• EUR-Lex: UN Regulation No 156, Software update and software update management system
• ISO: ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering
• ISO: ISO 24089:2023, Road vehicles, Software update engineering
• NHTSA: Cybersecurity Best Practices for the Safety of Modern Vehicles
• Uptane: Uptane Standard for Design and Implementation
• AUTOSAR: Secure Onboard Communication (SecOC) Protocol Specification
• Miller and Valasek: Remote Exploitation of an Unaltered Passenger Vehicle

Related NHI Mgmt Group resources: Device and IoT Identity Guide · OT and ICS Identity and Access Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Cryptographic Key Management Guide · Third-Party Access Guide. This guide summarises UN Regulations No. 155 and No. 156 and is not legal advice.