ISO/SAE 21434: Automotive Cybersecurity Explained

A connected vehicle is an attack surface on wheels. The telematics link to a backend, the diagnostic port a workshop tool plugs into and the channel that delivers software updates are all paths an attacker can walk. ISO/SAE 21434, published in August 2021, gives manufacturers and suppliers a shared process for managing that risk across the whole vehicle lifecycle.

Why Vehicles Need Their Own Cybersecurity Standard

Office IT security was not designed for a system that steers and brakes at motorway speed. A few properties set vehicles apart:

• Long life: a car stays on the road fifteen years or more, while the threats change every year.
• Hard deadlines: a brake controller cannot pause for a security check that misses its timing.
• Physical access: owners, workshops and thieves can all touch the hardware.
• Safety consequences: a successful attack on braking or steering is not a data breach but a possible road casualty.
• Scale: one vulnerability shared by a vehicle type can be exploited across hundreds of thousands of cars.

This is why UN Regulation 155, in force since 2021, made a certified Cybersecurity Management System (CSMS) a condition of type approval in the markets that apply it. R155 does not name ISO/SAE 21434, but authorities treat it as the benchmark behind a credible CSMS. R155 is the legal gate; ISO/SAE 21434 is the engineering method that gets a programme through it.

The Shape of a Threat: A Telematics Example

Take a telematics control unit (TCU) in a mid-range car. It connects outward to a mobile network and a backend, and inward, through a gateway, to the CAN bus and the ECUs that control powertrain and braking.

An attacker who finds an unauthenticated remote procedure on the TCU's cellular interface has a foothold without ever touching the car. Reaching the brake ECU still needs a second step: getting across the gateway. One broken control does not end the defence, and one working control does not end the threat.

ISO/SAE 21434 handles this with TARA, the Threat Analysis and Risk Assessment. It identifies the assets worth protecting, the damage if they are compromised, the attack paths that lead there, how feasible each path is and what to do about the risk. Here the remote route to the brake ECU is one attack path in two steps, and its feasibility is rated for the path as a whole. The results become cybersecurity goals, which are refined into requirements for hardware and software.

Cybersecurity Goals Are Not Safety Goals

Engineers from functional safety often treat a cybersecurity goal as another safety goal. A safety goal comes from analysing the item's malfunctioning behaviour, whatever its cause: a systematic fault in hardware or software, or a random hardware failure. A cybersecurity goal protects a security property, such as integrity or availability, against someone who wants to break it.

A disabled brake is a disabled brake, but what stands behind it differs. A random hardware failure has a failure rate and a systematic fault is controlled by process; an attack has an adversary who adapts. That is why TARA rates attack feasibility, something no FMEDA does.

When both analyses land on the same ECU, their requirements have to be reconciled. Authenticating diagnostic messages, for example, must not add enough latency to break the safety timing budget. The hand-off between ISO/SAE 21434 and ISO 26262 has to be planned, not discovered late.

Post-Production Is Not Optional

A common planning mistake is to treat development as the real scope and the field as light monitoring. UN R155 does not allow that reading: the CSMS covers the vehicle into the field, and the manufacturer's CSMS certificate is valid for at most three years before it is reassessed.

Three duties follow, and each needs decisions while the concept is still open: knowing which software each vehicle variant carries, so a new vulnerability can be matched to the fleet; agreed criteria for choosing between a patch, a workaround and an accepted risk; and a way to deliver the fix. UN R156 requires a software update management system for vehicle types whose software can be updated, in the workshop or over the air. It does not demand over-the-air updates, but whichever update channel the programme chooses has to be designed in, not retrofitted.

Two Misconceptions

• "Encryption is cybersecurity." Encryption is one control. A vehicle can encrypt every external channel and still be open through a diagnostic interface that accepts unauthenticated commands.
• "ISO/SAE 21434 only applies to connected vehicles." It applies to the E/E systems of series production road vehicles whose development began after 2021. Physical interfaces are in scope with or without a cellular modem.

Where to Go from Here

This article stops at orientation. The questions that decide whether a programme holds up in an audit are where the real work is: how to rate attack feasibility so the rating can be defended, what a supplier's TARA quietly assumes about your vehicle, who has the authority to stop a release, how a software bill of materials turns a vulnerability disclosure into a list of affected vehicles, and how cryptographic latency fits inside the fault tolerant time interval. The Automotive Cybersecurity concept page works through each of them and ends with a worked example from TARA to cybersecurity concept for a connected ECU.

Abbreviations

• ASIL - Automotive Safety Integrity Level, the ISO 26262 risk class from A to D.
• CAN - Controller Area Network, the common in-vehicle bus.
• CSMS - Cybersecurity Management System, required by UN R155.
• E/E - Electrical and electronic, including programmable electronics.
• ECU - Electronic Control Unit.
• FMEDA - Failure Modes, Effects and Diagnostic Analysis.
• HARA - Hazard Analysis and Risk Assessment, ISO 26262.
• TARA - Threat Analysis and Risk Assessment, ISO/SAE 21434.
• TCU - Telematics Control Unit.
• UN R155 / R156 - UNECE regulations on cybersecurity management and software update management.