A modern car is a computer on wheels. It runs dozens of electronic control units (ECUs), talks to the cloud over the air, and connects to the world through V2X, Bluetooth, and the OBD port. Every one of those connections is an attack surface, and ISO/SAE 21434 automotive cybersecurity is the engineering discipline that keeps those surfaces trustworthy for the life of the vehicle.
For manufacturers and suppliers, this is not an abstract exercise. UN R155 is the legal instrument here, and ISO/SAE 21434 is the engineering framework manufacturers use to satisfy it. Failing the cybersecurity requirements can stop a vehicle from being approved at all.
What ISO/SAE 21434 automotive cybersecurity actually is
ISO/SAE 21434:2021, “Road vehicles: Cybersecurity engineering,” defines engineering requirements for managing cybersecurity risk across the full vehicle lifecycle. That lifecycle spans concept, product development, production, operation, maintenance, and decommissioning.
The standard matters because it is the recognized engineering framework behind UNECE UN R155. UN R155 has applied to new vehicle types since July 2022 and to all new vehicles produced since July 2024 in adopting markets, including the EU, the UK, Japan, and South Korea. It requires two separate things: a certified Cybersecurity Management System (CSMS) and cybersecurity type approval for each vehicle type. It has legal effect only in contracting parties that have adopted it, so the United States and China sit outside it. External interfaces in scope include V2X, Bluetooth, and OBD ports.
In practice, ISO/SAE 21434 gives engineers a common way to prove that cybersecurity was designed in, not bolted on. That proof is what regulators and OEM auditors ask to see.
Who needs to comply
ISO/SAE 21434 applies to the whole supply chain, not just the automaker.
- OEMs own the organizational Cybersecurity Management System (CSMS) required for UN R155 type approval.
- Tier 1 and Tier 2 suppliers build the ECUs and components, provide cybersecurity engineering evidence, and meet the interface agreements set by the OEM.
- Aftermarket and telematics providers deliver OTA updates and connected services to vehicles already in the field.
Because the obligations flow across contracts, a gap at any tier becomes everyone’s problem.
Why it matters: market access is on the line
Non-compliance with UN R155 is a market-access issue, not a paperwork inconvenience. A vehicle that cannot demonstrate the required cybersecurity engineering can be refused type approval or barred from sale in UNECE markets.
OEMs increasingly cascade these requirements to their Tier 1 and Tier 2 suppliers through contracts. A supplier that cannot produce cybersecurity work-product evidence risks losing the business.
There is also a long-tail problem unique to automotive. Vehicles typically stay in service for 15 years or more. Cryptographic and key-management decisions made on the production line have to remain sound for the entire operational life of the car.
TARA: the risk methodology at the core
Threat Analysis and Risk Assessment (TARA), defined in Clause 15, is the core methodology of the standard. It gives teams a repeatable way to decide where cybersecurity effort should go.
A TARA works through asset identification, threat scenario identification, impact rating, attack path analysis, and risk determination. It is applied to every cybersecurity-relevant item, including ECUs, in-vehicle buses, and external interfaces.
The output is not a policy document. It is a prioritized view of risk that tells engineers which cryptographic controls each item actually needs.
The cryptography behind ISO/SAE 21434 compliance
Most of what a TARA recommends comes down to cryptography and key management. Here are the six control areas that carry the most weight in automotive programs, with the Keyfactor product that supports each one.
Secure onboard communication
Clause 9 (concept) sets cybersecurity goals and Clause 10 (product development) turns them into requirements. Authenticated in-vehicle communication is a common result rather than a stated requirement of the standard. Certificate and message-authentication-code based authentication, aligned with AUTOSAR SecOC, verifies traffic on in-vehicle buses such as CAN and Ethernet. This stops a rogue node from injecting messages onto the bus. EJBCA issues and manages the certificates behind it.
ECU and device identity provisioning
Where a TARA calls for it, Clause 10 covers developing a unique cryptographic identity per ECU and Clause 12 (production) covers provisioning it without introducing vulnerabilities on the line. That identity is what enables authenticated communication and trusted diagnostics later on. EJBCA embeds certificate-based identity into large fleets of connected devices at production scale.
Secure software and firmware updates
Clause 10 also covers the design of signing and verification, and Clause 13 (operations and maintenance) covers cybersecurity incident response and preserving cybersecurity during and after updates.. Firmware and OTA update packages should be cryptographically signed and verified before installation on any ECU. That verification is how a vehicle knows an update is genuine and untampered. SignServer and Signum provide the signing side of that pipeline. Software updates fall under a separate regulation, UN R156, which requires a Software Update Management System and RXSWIN identifiers. In the EU both R155 and R156 became type approval prerequisites through Regulation (EU) 2019/2144.
Cryptographic key management across the vehicle lifecycle
Clause 8 (continual cybersecurity activities) and Clause 13 (operations and maintenance) carry key management over time, acting on the risk treatment decisions from Clause 15. ECU keys and certificates have to be managed from production through 15 or more years of field service, including revocation and re-keying. Keyfactor Command handles that certificate and key lifecycle across the fleet.
V2X and external interface authentication
Clause 9 addresses concept-phase threat scenarios for external interfaces. PKI-backed certificates authenticate V2X messages and other external connections, so the vehicle can trust what it receives. EJBCA supplies the PKI behind these certificates.
Cryptographic component inventory
Clause 7 covers distributed cybersecurity activities, including the Cybersecurity Interface Agreement and evaluation of supplier cybersecurity capability. An accurate inventory of cryptographic libraries and algorithms across ECUs and supplier components supports both the TARA and OEM audits. Keyfactor AgileSec discovers and catalogs that cryptographic footprint.
Getting audit ready
ISO/SAE 21434 conformance is assessed through CSMS audits and product-level cybersecurity assessments. Assessors focus on documented engineering evidence, not policy statements alone. Six probes tend to separate programs that pass from programs that stall.
- TARA coverage for every cybersecurity-relevant item, including ECUs, buses, and external interfaces.
- ECU identity provisioning evidence: a unique identity per ECU at manufacture, not a shared fleet key.
- A signed update pipeline, with firmware and OTA updates signed and verified before installation.
- Key lifecycle management across a 15-plus-year service life, covering rotation, re-keying, and revocation.
- Supplier cybersecurity interface agreements that specify cryptographic requirements and work-product evidence.
- CSMS alignment with UN R155, supported by documented ISO/SAE 21434 engineering evidence.
If you can produce that evidence on demand, the audit becomes a formality rather than a fire drill.
The post-quantum horizon
A vehicle built today will still be on the road when today’s public-key algorithms are retired. NIST IR 8547, currently an initial public draft, proposes deprecating 112-bit-strength algorithms such as RSA-2048 and ECDSA P-256 after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. Many cars sold now will outlive both dates.
The risk is not only future. Data encrypted today can be harvested now and decrypted later, so the sensitivity horizon of the data sets the real deadline. Larger post-quantum algorithms also carry practical constraints for resource-limited ECUs, which is general industry context worth planning around.
The answer is cryptographic agility: the ability to rotate, reissue, and re-key at fleet scale. Hybrid constructions that pair an approved post-quantum algorithm with a classical one are not caught by the 2035 disallowance, which makes them a practical bridge during migration..
How Keyfactor can help
Keyfactor maps directly to the cryptographic work ISO/SAE 21434 demands. EJBCA provides PKI for ECU identity provisioning, secure onboard communication, and V2X and external interface authentication. SignServer and Signum sign firmware and OTA updates. Keyfactor Command manages key and certificate lifecycle across the vehicle’s service life, and AgileSec inventories the cryptographic components behind it all.
These products connect through the Keyfactor Trust Control Plane. It observes, analyzes, provisions, orchestrates, and governs every cryptographic asset and machine identity, so the evidence any framework asks for comes from a single system of record rather than a scramble across teams and spreadsheets.
Conclusion and next steps
ISO/SAE 21434 compliance is an ongoing operating capability, not a one-time project. The programs that stay road legal treat cryptography as living infrastructure: observe it, analyze it, provision it, orchestrate it, and govern it continuously.
Now is a good time to assess your current automotive cryptographic posture and the evidence you could produce today. To see how Keyfactor supports ISO/SAE 21434 and UN R155 evidence across the vehicle lifecycle, Request a Demo.
Got ISO/SAE 21434 questions? We’ve got answers.
What is ISO/SAE 21434?
ISO/SAE 21434:2021 is the “Road vehicles: Cybersecurity engineering” standard. It defines engineering requirements for managing cybersecurity risk across the full vehicle lifecycle, from concept and development through operation, maintenance, and decommissioning.
How is ISO/SAE 21434 related to UN R155?
ISO/SAE 21434 is the recognized engineering framework that supports UNECE UN R155. UN R155 is a legal precondition for vehicle type approval in UNECE markets, so the engineering evidence from ISO/SAE 21434 underpins that approval.
Who has to comply with ISO/SAE 21434?
The whole supply chain is involved. OEMs own the Cybersecurity Management System required for type approval, Tier 1 and Tier 2 suppliers provide cybersecurity engineering evidence, and aftermarket and telematics providers secure OTA updates and connected services.
What happens if a manufacturer does not comply?
Non-compliance with UN R155 can mean a vehicle is refused type approval or barred from sale in UNECE markets. OEMs also cascade requirements to suppliers by contract, so a supplier without work-product evidence can lose the business.
What is TARA in ISO/SAE 21434?
TARA stands for Threat Analysis and Risk Assessment, defined in Clause 15. It works through asset identification, threat scenario identification, impact rating, attack path analysis, and risk determination for every cybersecurity-relevant item.
Why does the 15-year vehicle service life matter for cryptography?
Vehicles typically stay in service for 15 years or more. Cryptographic and key-management choices made at production must remain secure for the entire operational life, which is why key rotation, re-keying, and revocation are essential.
How does post-quantum cryptography affect automotive programs?
RSA and elliptic curve algorithms are targeted for deprecation around 2030 and disallowance around 2035, yet many vehicles built now will still be on the road. Cryptographic agility and hybrid certificates let manufacturers rotate and re-key at fleet scale during the transition.
How does Keyfactor support ISO/SAE 21434 compliance?
Keyfactor maps to the standard’s cryptographic controls: EJBCA for ECU identity and V2X authentication, SignServer and Signum for signed updates, Command for key lifecycle management, and AgileSec for cryptographic inventory. The Trust Control Plane unifies this evidence in a single system of record.
