Iso/Sae 21434 Automotive Cybersecurity Engineering

ISO/SAE 21434 is an international standard for managing cybersecurity risks in road vehicle electrical and electronic systems. It gives manufacturers and suppliers a framework for identifying threats, defining security requirements and maintaining protection throughout a vehicle’s lifecycle. Its purpose is to make cybersecurity part of.

What ISO/SAE 21434 covers

Developed jointly by ISO and SAE International, the standard addresses vehicle systems, their components and their interfaces. As the official ISO description explains, it sets engineering requirements for cybersecurity risk management without prescribing particular technologies or solutions.

That distinction matters when selecting controls. A firewall, encryption library or intrusion detection system may address a particular risk, but installing one does not establish that a vehicle’s cybersecurity risks have been managed. Engineers need to explain what requires protection, how an attack could cause harm and why the chosen measures are appropriate.

The audience includes vehicle manufacturers, component suppliers, software developers and teams responsible for maintaining vehicle systems. The work crosses organisational boundaries: a supplier’s assumptions about an interface must match how the manufacturer actually uses it.

Why vehicle cybersecurity needs a lifecycle approach

Connected vehicle functions introduce interfaces through which systems exchange commands, software and data. Infotainment, diagnostic access and remote services can create different attack paths. Assessing each feature in isolation can miss risks created by its connections to other parts of the vehicle.

Cybersecurity also changes after release. A vulnerability may be discovered in a software component, a service may change or a new attack technique may challenge an earlier assumption. Development checks therefore need to connect with monitoring, incident response and maintenance.

For readers building their knowledge of these subjects, the cybersecurity articles provide wider context. Within a vehicle project, however, general security advice must be translated into requirements that account for the actual architecture and operating conditions.

How to put the framework into practice

The following sequence is a practical starting point for organising the work. Activities will need revisiting when the design, interfaces or threat information change; they are not a checklist completed once at project launch.

1. Define the system and assign responsibility

   Describe the function under assessment, its boundaries, interfaces and dependencies. Record assumptions about users, servicing, connectivity and the surrounding vehicle architecture. Identify who owns cybersecurity decisions and who must provide supporting information.

   For example, a connected control unit may rely on another component to authenticate incoming requests. Make that dependency explicit so it can be checked during integration.

2. Identify assets and assess threat scenarios

   Identify what needs protection, including software integrity, commands, credentials and sensitive data. Consider the consequences if an attacker compromises those assets, then examine plausible ways the attack could happen.

   Threat analysis and risk assessment should connect potential harm with attack feasibility. This helps prioritise engineering effort rather than treating every interface or vulnerability as equally significant. Record the reasoning so another team can review the assessment.

3. Turn risk decisions into security requirements

   Define what the system must do to address the assessed risks. Requirements should be specific enough to guide design and verification. For a software update function, for example, a requirement might address checking an update’s authenticity before accepting it.

   Choose controls to meet those requirements. Authentication, access restrictions, cryptography and network separation are possible measures, depending on the threat scenario. Document any dependencies, such as how credentials are provisioned and protected.

4. Integrate security into development and testing

   Carry the requirements into architecture, implementation and integration work. Use secure coding practices, design reviews and testing suited to the system. Check both the intended behaviour and how interfaces respond to invalid, unexpected or unauthorised inputs.

   Keep a traceable connection between the risk, the requirement, the implemented control and the verification result. Review unresolved findings before release, including whether they affect earlier assumptions about acceptable risk.

5. Plan production, support and decommissioning

   Consider how production and servicing could affect the security of the delivered system. Practical checks might include credential handling, software configuration and diagnostic access. Define how vulnerabilities will be reported, assessed and assigned for action after release.

   Plan how fixes will reach affected vehicles and how their effectiveness will be checked. At decommissioning, consider sensitive data, credentials and access to connected services. Assign owners for these tasks while the relevant teams and suppliers are available.

Make supplier responsibilities explicit

A vehicle manufacturer and its suppliers need an agreed division of cybersecurity work. Clarify who performs assessments, implements requirements, supplies verification evidence and handles vulnerability notifications. An interface specification alone may leave these responsibilities unresolved.

Useful information to exchange includes:

• The component’s intended use and security assumptions.
• Cybersecurity requirements allocated to each party.
• Known limitations, dependencies and unresolved findings.
• Contacts and procedures for reporting vulnerabilities and coordinating fixes.

For manufacturing teams exploring the surrounding operational environment, the discussion of Industrial Cybersecurity, Second Edition offers related reading. Protecting production systems and engineering vehicle cybersecurity require coordination, while each needs its own clearly defined scope.

Coordinate cybersecurity with safety and external services

Cybersecurity and functional safety teams should share information when an attack could affect vehicle behaviour. The source of a cybersecurity concern may be deliberate manipulation, while safety engineering also examines failures and malfunctioning behaviour. Their analyses can inform one another without making either discipline a substitute for the other.

Remote services also introduce dependencies outside the vehicle. Teams should assess what happens if communication is unavailable or data cannot be trusted. The separate debate about net neutrality and its possible impact on cybersecurity provides broader context about internet access; vehicle engineering still needs explicit assumptions about the services each function depends on.

Start with a focused gap review

Using the standard can improve consistency and make security decisions easier to review, but it does not guarantee that a vehicle is free from vulnerabilities. Evidence needs to relate to the actual product and remain useful as that product changes.

Select one vehicle function and map its interfaces, current risk assessment, security requirements and verification evidence. Assign an owner to each missing element, then use that review to plan the next engineering tasks.