Safety & Cybersecurity Co-Engineering
Learn how ISO 26262 and ISO/SAE 21434 work together: aligning HARA with TARA, sharing the item definition and assumptions register, resolving safety-versus-security conflicts, and meeting UNECE R155/R156 type-approval gates.
- Chapters
- 10
- Chapters
- Standards Aligned
- 2
- Standards Aligned
- CAL Levels
- 4
- CAL Levels
- UNECE Regs
- R155/R156
- UNECE Regs
Why it pays for itself
HARA and TARA that agree
Run the two risk analyses in parallel and reconcile severity, exposure, and controllability with impact and attack feasibility - so safety and security ratings reinforce each other instead of contradicting in review.
One assumptions register, not two
A mapped set of shared work products - item definition, system boundary, assumptions register, joint verification interface - prevents the divergent operating premises that silently invalidate one team's analysis.
Type-approval gates handled early
Understand how UNECE R155 CSMS and R156 SUMS evidence gates the safety release, so cybersecurity management lands as planned input to type approval rather than late paperwork before launch.
What you’ll be able to do
Align HARA with TARA
Run hazard and threat analyses in parallel and reconcile their parameters so safety and security risk ratings stay consistent.
Share work products correctly
Maintain one item definition, system boundary, and assumptions register across both disciplines instead of divergent copies.
Resolve safety-security conflicts
Apply structured principles when availability and access goals collide with restriction and authentication requirements.
Trace attacks to safety goals
Connect attack paths to specific hazardous events and identify which security controls underpin which safety goals.
Meet R155/R156 obligations
Position CSMS and SUMS evidence as inputs to the type-approval and safety-release gates rather than late paperwork.
Synchronise both lifecycles
Set aligned milestones, joint reviews, and re-assessment triggers so security updates do not silently break safety validation.
Chapter by chapter
- 01
Why Safety Needs Security
Establishes that in connected vehicles a deliberate manipulation can violate a safety goal, making cybersecurity a precondition for functional safety rather than a separate concern.
- Attack-to-hazard examples: CAN injection, compromised OTA, spoofed GNSS
- ISO 26262 covers unintentional faults, not deliberate manipulation
- Safety goals depend on security controls such as message authentication codes
- 02
ISO 26262 vs ISO/SAE 21434
Compares scope, risk metrics, lifecycles, and work products of the two standards, clarifying what each owns and where the item definition and architecture must be shared.
- HARA and ASIL versus TARA and Cybersecurity Assurance Level (CAL)
- ASIL D does not imply CAL 4; the scales are derived independently
- Clear ownership of fault domain versus threat domain plus a shared interface zone
- 03
HARA vs TARA
Sets the two parallel risk analyses side by side, showing how to align their inputs, parameters, and outputs so they reinforce rather than contradict each other.
- Severity, exposure, and controllability versus impact and attack feasibility
- Mutual feedback: TARA threats can raise HARA exposure or severity ratings
- Worked alignment on an Automatic Emergency Braking (AEB) radar ECU
- 04
Shared Work Products
Maps the artefacts that safety and security teams exchange or jointly own across the lifecycle, anchored by a shared assumptions register and a common verification interface.
- Work-product map organised by lifecycle phase
- A single shared assumptions register prevents divergent operating premises
- Joint verification and validation interface for safety and security requirements
- 05
Conflicts & Trade-offs
Examines the structural tension where safety favours availability and simple access while security favours restriction and authentication, then gives principles for resolving it.
- Common conflict patterns such as authentication gating a safe-state transition
- Open diagnostic access versus locked-down secure ECU access
- General resolution principles that keep safe states reachable under attack
- 06
Co-Engineering Process
Lays out the integrated workflow that synchronises the ISO 26262 and ISO/SAE 21434 lifecycles through aligned milestones, joint reviews, and a defined organisational interface.
- Aligned milestone map across both lifecycles
- Joint review formats for concept, design, and release gates
- Organisational interface model linking the safety and security teams
- 07
Attack Paths to Hazards
Traces threats through the system to safety hazards, connecting attack trees with fault trees and reframing security controls as enablers of safety goals.
- The threat-to-hazard chain and an attack vector taxonomy
- Attack-path traces mapped onto specific HARA hazardous events
- Security controls (secure boot, message authentication) as safety enablers
- 08
UNECE R155/R156 & CSMS
Covers the regulatory framework in which a Cybersecurity Management System (CSMS) and Software Update Management System (SUMS) are mandatory for type approval and gate the safety release.
- R155 mandates a CSMS; R156 mandates a SUMS for over-the-air and physical updates
- In force for new vehicle types from 2022 and all new vehicles from 2024
- How type-approval audits consume ISO/SAE 21434 evidence
- 09
Worked Example
Runs a connected Integrated Chassis Control Module (ICCM) at ASIL D through parallel HARA and TARA snippets, a resolved conflict, and the shared requirements both analyses produce.
- HARA hazardous events for unintended braking and EPS torque, all ASIL D
- TARA threat scenarios mapped to those events with CAL 2 to CAL 4 ratings
- Open diagnostic access versus secure ECU access conflict, resolved
- 10
Organisation & Pitfalls
Catalogues the organisational anti-patterns and technical pitfalls that derail co-engineering, closing with a good-practice checklist for sustaining alignment.
- Siloed teams and inconsistent assumptions as recurring anti-patterns
- Security patches that silently invalidate prior safety verification
- A good-practice checklist for joint governance and re-assessment triggers
Not just text: the visual toolkit
Standards Landscape
Maps how ISO 26262 and ISO/SAE 21434 relate, what each owns, and where the shared item and architecture interface sits.
HARA vs TARA Comparator
Side-by-side view of inputs, parameters, and outputs of the two risk analyses, with the points where they feed each other.
Attack Path to Hazard Flow
Traces an attacker from entry point through the system to a violated safety goal, linking attack steps to hazardous events.
Shared Work Products Matrix
Lifecycle grid of artefacts that are exchanged, jointly owned, or independently produced by the safety and security teams.
R155/R156 Process Map
Shows how CSMS and SUMS activities flow into type approval and gate the safety release for connected vehicles.
Safety vs Security Conflict Resolver
Walks a concrete tension (authentication gating a safe-state transition) to a balanced design decision.
Integrated Chassis Control Module (ICCM)
An ASIL D ECU managing brake-by-wire and electric power steering on a connected vehicle is taken through parallel HARA and TARA, a resolved conflict, and the shared requirements both analyses generate.
- Item: ICCM with brake-by-wire and EPS torque assist, CAN FD with SecOC message authentication, UDS over DoIP and OBD-II, OTA via the gateway ECU.
- HARA: unintended full braking and unintended EPS torque both rate S3/E4/C3 to ASIL D with quantified safety goals.
- TARA: CAN injection of brake commands maps to the braking hazard at CAL 3; a malicious OTA payload reaches CAL 4.
- Conflict: workshops need open diagnostic access while security demands a locked-down ECU, resolved with role-gated UDS sessions.
- Shared requirements: message authentication on brake and steer frames satisfies both a safety goal and a cybersecurity goal.
Unlock the full alignment table and resolved conflict
Who this guide is for
- Safety engineers whose item now has a CAN FD port, OTA updates, and a threat model
- Cybersecurity engineers who need their TARA to line up with an existing HARA
- Managers building the organisational interface between safety and security teams
- Teams preparing R155/R156 type-approval evidence for a connected vehicle
Frequently Asked Questions
Common questions about Safety & Cybersecurity Co-Engineering
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.