ISO 26262 and ISO/SAE 21434: Safety Meets Cybersecurity in Automotive Systems

Hello, automotive safety engineers, cybersecurity engineers, and system architects! As vehicles become increasingly connected and autonomous, two critical disciplines that were once separate are now converging: functional safety (ISO 26262) and cybersecurity (ISO/SAE 21434). A cybersecurity breach can directly cause a functional safety hazard – a hacker compromising the CAN bus can cause unintended braking just as effectively as a hardware fault. Understanding how these two standards interact, where they overlap, and how to implement them together is essential for modern automotive development.

In this comprehensive guide at PiEmbSysTech, we will compare the two standards, explain their interaction points, contrast HARA with TARA, compare ASIL with CAL, and provide practical guidance for co-engineering safety and security in connected vehicles. Let us begin.

Table of Contents

1. Why Safety and Cybersecurity Must Be Addressed Together
2. ISO/SAE 21434 – Cybersecurity Engineering Overview
3. ISO 26262 – Functional Safety Recap
4. The Fundamental Difference – Accidental vs Intentional
5. HARA vs TARA – Risk Assessment Compared
6. ASIL vs CAL – Safety Integrity vs Cybersecurity Assurance
7. Interface Points Between ISO 26262 and ISO 21434
8. When a Cybersecurity Breach Becomes a Safety Hazard
9. Worked Example – AEB System Under Both Standards
10. Lifecycle Comparison – Safety vs Security
11. Co-Engineering Best Practices
12. UNECE WP.29 R155/R156 – Regulatory Context
13. The Master Comparison Table
14. Organizational Considerations – Team Structure
15. Future: HATARA and Unified Assessment
16. Frequently Asked Questions
17. Conclusion

1. Why Safety and Cybersecurity Must Be Addressed Together

Historically, functional safety and cybersecurity were treated as separate disciplines with separate teams, separate processes, and separate standards. This separation worked reasonably well when vehicles were isolated mechanical-electrical systems with minimal connectivity. Modern vehicles, however, have dozens of ECUs connected via CAN, CAN FD, and Ethernet networks, with external connectivity through telematics units, V2X communication, OTA update interfaces, Bluetooth, Wi-Fi, and USB ports.

This connectivity means that a cybersecurity vulnerability can be exploited to cause a functional safety hazard. A remote attacker who gains access to the vehicle’s CAN bus could inject malicious steering commands, suppress brake activation signals, manipulate sensor data fed to ADAS algorithms, or disable safety mechanisms like airbag deployment. In each case, the root cause is a cybersecurity breach, but the consequence is a functional safety violation – potentially life-threatening. ISO 26262 alone cannot address this because it assumes accidental failures, not intentional attacks. ISO 21434 alone cannot fully address it because it focuses on cybersecurity properties (confidentiality, integrity, availability) without the automotive-specific safety consequence analysis (severity, controllability) that ISO 26262 provides.

2. ISO/SAE 21434 – Cybersecurity Engineering Overview

ISO/SAE 21434:2021 “Road vehicles – Cybersecurity engineering” defines a structured approach for managing cybersecurity risks throughout the entire lifecycle of road vehicle E/E systems. It requires cybersecurity management at the organizational level (policies, competence, awareness), TARA (Threat Analysis and Risk Assessment) during the concept phase, cybersecurity requirements specification and design, cybersecurity verification and validation, and continuous cybersecurity monitoring during production and post-production (including vulnerability management, incident response, and OTA update security).

ISO 21434 evaluates cybersecurity threats based on the CIA Triad: Confidentiality (preventing unauthorized data access), Integrity (ensuring data and functions cannot be modified without authorization), and Availability (ensuring the system operates when needed). The required protection level is expressed as CAL (Cybersecurity Assurance Level), which determines the rigor of cybersecurity engineering activities.

3. ISO 26262 – Functional Safety Recap

ISO 26262 addresses hazards caused by malfunctioning behavior of E/E systems – random hardware failures and systematic software/hardware errors. It uses HARA to identify hazardous events and classify them using ASIL (A–D). The focus is on preventing harm to vehicle occupants and other road users from system malfunctions. ISO 26262’s scope explicitly includes the interaction between functional safety and cybersecurity – Part 2 requires the organization to consider interactions between functional safety and cybersecurity in its safety management.

4. The Fundamental Difference – Accidental vs Intentional

The most fundamental philosophical difference between the two standards is the nature of the threat:

ISO 26262 (Functional Safety): Addresses accidental failures – random hardware component wear-out, systematic design errors, software bugs. The “adversary” is physics, entropy, and human error in design – not a malicious actor. The failure modes are predictable and can be enumerated through FMEA/FTA.

ISO 21434 (Cybersecurity): Addresses intentional attacks – deliberate exploitation of vulnerabilities by malicious actors (hackers, nation-state attackers, disgruntled insiders). The “adversary” is intelligent, adaptive, and actively seeking to bypass defenses. Attack vectors evolve over time as new vulnerabilities are discovered and new attack techniques are developed.

This fundamental difference drives different analysis methods (HARA for safety vs TARA for security), different mitigation strategies (safety mechanisms vs security controls), and different lifecycle considerations (safety requirements are relatively stable once established, while cybersecurity threats evolve continuously throughout the vehicle’s operational life).

5. HARA vs TARA – Risk Assessment Compared

Dimension	HARA (ISO 26262)	TARA (ISO 21434)
Purpose	Identify hazardous events from E/E malfunctions; determine ASIL	Identify cybersecurity threats; determine risk level and treatment
Threat source	Accidental faults/failures	Intentional malicious attacks
Risk parameters	Severity (S), Exposure (E), Controllability (C)	Impact (Safety, Financial, Operational, Privacy) × Attack Feasibility
Impact dimensions	Physical harm to people only	Safety, financial damage, operational disruption, privacy violation
Probability dimension	Exposure (how often the driving situation occurs)	Attack feasibility (expertise, knowledge, equipment, time needed)
Output classification	ASIL (QM, A, B, C, D)	Risk level → Cybersecurity treatment decision
Output requirements	Safety goals → FSR → TSR	Cybersecurity goals → Cybersecurity requirements
Standard clause	ISO 26262 Part 3 Clause 7	ISO/SAE 21434 Clause 15

6. ASIL vs CAL – Safety Integrity vs Cybersecurity Assurance

ASIL (Automotive Safety Integrity Level) – A through D – determines the rigor of functional safety development methods, hardware metrics, structural coverage, and confirmation measures. ASIL is well-established with mature, prescriptive requirements for each level.

CAL (Cybersecurity Assurance Level) – 1 through 4 – determines the rigor of cybersecurity engineering activities. CAL is a newer concept (first formally introduced in ISO/SAE 21434 and being further specified in the upcoming ISO/SAE PAS 8475). CAL determines the depth of threat analysis, the rigor of security verification and validation, and the level of security testing required.

There is no direct mapping between ASIL and CAL. A function may be ASIL D (highest safety criticality) but CAL 1 (low cybersecurity assurance needed – perhaps because it has no external connectivity). Conversely, a function may be ASIL A (low safety risk) but CAL 4 (highest cybersecurity assurance – perhaps because it handles sensitive personal data). However, when a cybersecurity breach can lead to a safety hazard, the ASIL of the affected safety function influences the cybersecurity requirements – a cybersecurity vulnerability that could compromise an ASIL D function demands more rigorous cybersecurity treatment than one affecting an ASIL A function.

7. Interface Points Between ISO 26262 and ISO 21434

ISO 26262 (2018 edition) explicitly requires interaction with cybersecurity. The key interface points are:

Part 2 (Safety Management): Requires the organization to consider interactions between functional safety and cybersecurity – including shared responsibility definitions and information exchange between safety and security teams.

Part 3 (Concept Phase): The item definition should consider cybersecurity-relevant interfaces and potential attack vectors. HARA should consider whether cybersecurity breaches could contribute to hazardous events.

Part 4 (System Level): The TSC should include security controls as safety mechanisms where cybersecurity breaches could violate safety goals – for example, secure communication protocols (authenticated CAN, MACsec for Ethernet) as protection against message injection attacks.

Part 6 (Software): Software development should apply secure coding practices alongside safety coding standards (MISRA). Coding guidelines should address both safety and security vulnerabilities (buffer overflows, integer overflows, injection attacks).

Part 7 (Production): Production processes should ensure cybersecurity of the manufactured product – including secure key provisioning, secure boot configuration, and secure firmware flashing.

8. When a Cybersecurity Breach Becomes a Safety Hazard

A cybersecurity breach becomes a functional safety hazard when the attack compromises the integrity or availability of a safety-relevant function. Specific scenarios include: CAN bus message injection (attacker sends malicious steering, braking, or throttle commands — directly violating safety goals), sensor data manipulation (attacker alters radar, camera, or LiDAR data fed to ADAS – causing incorrect perception and potentially dangerous driving decisions), safety mechanism bypass (attacker disables or manipulates a safety mechanism such as an airbag controller or ABS – removing the intended safety protection), OTA update corruption (attacker injects malicious firmware through a compromised OTA channel – introducing safety-relevant software errors), and denial of service on safety-critical communication (attacker floods the CAN or Ethernet bus – preventing safety-relevant messages from being delivered within the FTTI).

In each of these scenarios, the root cause is a cybersecurity vulnerability, but the consequence is a safety goal violation. Addressing these scenarios requires both ISO 26262 (defining the safety goals and safety mechanisms) and ISO 21434 (identifying the cybersecurity threats and implementing security controls to prevent the attacks).

9. Worked Example – AEB System Under Both Standards

Scenario	Root Cause	Analysis	Standard
Brake ECU MCU random failure → AEB does not activate	Hardware fault	HARA → ASIL	ISO 26262
Software bug causes unintended AEB activation	Systematic error	HARA → ASIL	ISO 26262
Attacker injects CAN message to trigger unintended braking	Cyber attack	TARA → Risk level	ISO 21434
Attacker spoofs radar sensor data → AEB fails to detect obstacle	Cyber attack on sensor	TARA → Risk level	ISO 21434
Malicious OTA update corrupts AEB algorithm	Supply chain attack	TARA → Risk level	ISO 21434
Camera blinded by sun → AEB misses pedestrian	Sensor limitation	SOTIF analysis	ISO 21448 (SOTIF)

This example demonstrates that a complete safety assessment of a modern AEB system requires all three standards — ISO 26262, ISO 21434, and ISO 21448 (SOTIF) – working together.

10. Lifecycle Comparison – Safety vs Security

Both standards cover the full product lifecycle, but with different emphases. ISO 26262’s safety requirements are established during development and remain relatively stable during the vehicle’s operational life (safety recalls are rare and driven by field failure data). ISO 21434’s cybersecurity requirements must be continuously updated because the threat landscape evolves – new vulnerabilities are discovered, new attack techniques emerge, and new connectivity features may introduce new attack surfaces. ISO 21434 explicitly requires continuous cybersecurity monitoring during the operational phase, vulnerability management processes, and incident response capabilities that go well beyond ISO 26262’s field monitoring requirements.

11. Co-Engineering Best Practices

Shared item definition: The item definition (ISO 26262) and the cybersecurity item definition (ISO 21434) should use a common system description, ensuring both safety and security analyses start from the same understanding of the system architecture and interfaces.

Coordinated HARA and TARA: Perform HARA and TARA in coordination – ideally using shared workshops where safety engineers and cybersecurity engineers analyze the system together. This ensures that cybersecurity threats that could lead to safety hazards are identified early and that safety mechanisms are not inadvertently weakened by security controls (or vice versa).

Unified requirements management: Safety requirements (from HARA) and cybersecurity requirements (from TARA) should be managed in a shared requirements management system with clear traceability and cross-references – ensuring that no conflict exists between safety and security requirements.

Shared verification and validation: Static analysis tools (MISRA + security coding standards like CERT C/CWE), unit testing, and integration testing should cover both safety and security test cases. Tools like Parasoft C/C++test and LDRA provide combined safety and security verification capabilities.

Joint safety-security assessment: The functional safety assessment (ISO 26262) and cybersecurity assessment (ISO 21434) should be coordinated to ensure consistent risk treatment decisions – particularly for hazards that span both domains.

12. UNECE WP.29 R155/R156 – Regulatory Context

The UNECE WP.29 regulations provide the mandatory regulatory framework that makes both standards practically required: UNECE R155 (Cybersecurity) requires manufacturers to implement a Cybersecurity Management System (CSMS) and demonstrate compliance with cybersecurity engineering practices – ISO/SAE 21434 is the recognized framework. UNECE R156 (Software Update) requires manufacturers to implement a Software Update Management System (SUMS) – addressing the security and safety of OTA updates. Since July 2024, new vehicle types sold in the EU must comply with R155. This regulatory mandate has made ISO 21434 compliance effectively mandatory for vehicles sold in Europe, just as ISO 26262 has been the de facto requirement for functional safety.

13. The Master Comparison Table

Dimension	ISO 26262	ISO/SAE 21434
Full title	Road vehicles – Functional safety	Road vehicles – Cybersecurity engineering
Focus	Accidental E/E system malfunctions	Intentional cybersecurity attacks
Risk assessment	HARA (S × E × C → ASIL)	TARA (Impact × Attack Feasibility → Risk Level)
Integrity classification	ASIL (A–D) + QM	CAL (1–4)
Impact dimensions	Physical harm (injury/death)	Safety + Financial + Operational + Privacy
Probability dimension	Exposure (situation frequency)	Attack feasibility (expertise, time, knowledge, equipment)
Threat model	Physics and entropy (random faults)	Intelligent adversary (hackers, nation-state)
Requirements stability	Relatively stable after development	Continuously evolving (new threats, new vulnerabilities)
Post-production	Field monitoring, recalls	Continuous monitoring, vulnerability management, incident response
Regulatory driver	Industry de facto standard	UNECE R155 (mandatory EU July 2024)
Parts	12 parts (~800+ pages)	1 part (~100 pages)
Key analysis tools	FMEA, FTA, FMEDA	STRIDE, attack trees, penetration testing

14. Organizational Considerations – Team Structure

Both ISO 26262 and ISO 21434 place requirements on the organization – competence management, role definitions, and independence. In practice, the safety team and cybersecurity team must collaborate closely but may have different skill sets. Safety engineers typically have deep expertise in hardware failure modes, FMEA/FTA, and hardware metrics. Cybersecurity engineers typically have deep expertise in network protocols, cryptography, penetration testing, and vulnerability assessment. Effective co-engineering requires cross-training between the disciplines, shared workshops for HARA/TARA coordination, and a common escalation path for conflicts between safety and security requirements (e.g., a security control that introduces a timing delay exceeding the FTTI, or a safety mechanism that creates a new attack surface).

15. Future: HATARA and Unified Assessment

The industry is moving toward HATARA (Hazard Analysis and Threat Analysis and Risk Assessment) – a unified assessment framework that combines HARA and TARA into a single process. HATARA and related methods like STPA-SafeSec (Systems-Theoretic Process Analysis for Safety and Security) analyze the system from both safety and security perspectives simultaneously, identifying scenarios where cybersecurity threats lead to safety hazards and where safety mechanisms interact with security controls. This unified approach reduces redundant analysis effort, improves consistency between safety and security requirements, and ensures that the interaction between the two domains is systematically addressed. The upcoming ISO/SAE PAS 8475 (Cybersecurity Assurance Levels) and the ISO 26262 3rd edition are expected to further formalize the integration between safety and security.

16. Frequently Asked Questions

Q1: Does ISO 26262 require cybersecurity compliance?

ISO 26262 does not mandate ISO 21434 compliance. However, Part 2 requires the organization to consider interactions between functional safety and cybersecurity, and Part 4 requires the TSC to address potential cybersecurity-related failure causes where relevant. In practice, for connected vehicles, addressing cybersecurity is necessary to fulfill the ISO 26262 requirement to consider all reasonably foreseeable causes of safety goal violations.

Q2: Does ISO 21434 require functional safety compliance?

ISO 21434 does not mandate ISO 26262 compliance, but it explicitly references ISO 26262 and requires interaction between cybersecurity and safety engineering activities. Where a cybersecurity threat can lead to a safety hazard, ISO 21434 requires that the safety impact be considered in the cybersecurity risk assessment.

Q3: Can a TÜV assessor assess both safety and cybersecurity?

Some assessment bodies (TÜV SÜD, TÜV NORD, SGS-TÜV) offer combined functional safety and cybersecurity assessment services. The assessors may be different individuals (safety assessor + cybersecurity assessor), but the assessment scope can cover both standards in a coordinated engagement.

Q4: How does secure boot relate to ISO 26262?

Secure boot (verifying firmware authenticity and integrity at startup) is primarily an ISO 21434 cybersecurity mechanism. However, it has safety implications – if a malicious firmware is loaded, it could violate safety goals. In this sense, secure boot can be considered a safety mechanism that prevents cybersecurity-induced safety failures, and it should be documented in both the cybersecurity concept and the safety concept.

Q5: Is MISRA compliance sufficient for both safety and security?

MISRA C/C++ addresses safety-related coding concerns (undefined behavior, type safety, pointer safety) that also have security implications. However, MISRA alone is not sufficient for cybersecurity – additional security coding standards (CERT C/C++, CWE) should be applied to address security-specific vulnerabilities (buffer overflows, format string attacks, injection vulnerabilities). Tools like Parasoft and Coverity support combined MISRA + CERT + CWE analysis.

17. Conclusion

ISO 26262 and ISO/SAE 21434 are two complementary pillars of modern automotive safety engineering. ISO 26262 ensures that E/E systems do not create hazards when they malfunction accidentally. ISO 21434 ensures that E/E systems are resilient against intentional cybersecurity attacks that could compromise safety, privacy, and operational availability. For connected and autonomous vehicles, both standards must be implemented together – coordinated through shared item definitions, coordinated HARA/TARA, unified requirements management, and joint assessment. The UNECE R155 regulatory mandate has made this integration not just a best practice but a legal requirement for vehicles sold in Europe.

This article is part of our comprehensive ISO 26262 series at PiEmbSysTech.

Stay safe. Stay secure. Keep engineering the future.

— The PiEmbSysTech Team