Safety & Cybersecurity Co-Engineering
Apply ISO 26262 and ISO/SAE 21434 to the same item: align HARA with TARA, share the item definition and assumptions, resolve safety and security conflicts, and feed UNECE R155 and R156 type approval.
- Chapters
- 10
- Chapters
- Figures and interactive visuals
- 13
- Figures and interactive visuals
- Worked example
- 1
- Worked example
Quick answers
- What is safety and cybersecurity co-engineering in ISO 26262?
- Co-engineering is the coordinated application of ISO 26262 for functional safety and ISO/SAE 21434 for cybersecurity engineering to the same item. It is needed because ISO 26262 addresses malfunctions, not deliberate manipulation, yet in a connected vehicle an attack such as message injection or a compromised software update can violate a safety goal. The two disciplines share the item definition, architecture, assumptions and parts of verification, and they must resolve conflicts between their requirements.
- What is the difference between HARA and TARA?
- HARA (ISO 26262) rates hazardous events caused by malfunctions using severity, exposure and controllability, and produces safety goals with ASILs. TARA (ISO/SAE 21434) rates threat scenarios from deliberate attacks using impact and attack feasibility, and produces cybersecurity goals. They are parallel analyses of the same item: threats that lead to safety-relevant damage should be traced to the corresponding hazards, and hazards point security to the functions most worth protecting.
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 results support each other in review.
One assumptions register, not two
Share the item definition, system boundary, assumptions and verification interface across both teams, so neither analysis rests on operating premises the other has already changed.
Type-approval evidence planned early
See how UNECE R155 and R156 use cybersecurity and software update management evidence, so it arrives as planned input to type approval rather than paperwork before launch.
What you’ll be able to do
Align HARA with TARA
Run hazard and threat analyses side by side and keep their results consistent.
Share work products
Maintain one item definition, boundary and assumptions register for both disciplines.
Resolve conflicts
Apply clear principles when availability and access collide with restriction and authentication.
Trace attacks to safety goals
Connect attack paths to hazardous events and the controls that protect them.
Prepare regulatory evidence
Plan CSMS and SUMS evidence as inputs to type approval, not late paperwork.
Chapter by chapter
- 01
Why Safety Needs Security
See how a deliberate attack can become a safety hazard and why the safety engineer has a direct stake in cybersecurity.
- The convergence imperative
- Attack to hazard
- Regulatory context
- 02
ISO 26262 vs ISO 21434
Compare the purpose, scope and ownership of the two standards and how ASIL and CAL express different things.
- Side-by-side comparison
- What each standard owns
- ASIL versus CAL
- 03
HARA vs TARA
Compare inputs, parameters and outputs of the two risk analyses and see how they feed each other on an AEB radar ECU.
- Inputs and parameters
- Mutual feedback
- AEB radar alignment
- 04
Shared Work Products
Map which work products the two disciplines share across the lifecycle, including one shared assumptions register.
- Work product map
- Shared assumptions register
- V&V interface
- 05
Conflicts & Trade-offs
Recognize the recurring tensions between safety and security requirements and the principles for resolving them.
- Fundamental tension
- Common conflict patterns
- Resolution principles
- 06
Co-Engineering Process
Align milestones, run joint reviews and set up the organizational interface between the safety and security teams.
- Aligned milestone map
- Joint review formats
- Organizational interface
- 07
Attack Paths to Hazards
Trace attack paths from entry points to hazardous events and see which security controls enable safety goals.
- Threat-to-hazard chain
- Attack vector taxonomy
- Controls as safety enablers
- 08
UNECE R155/R156 & CSMS
Understand the cybersecurity and software update management regulations and how they use ISO/SAE 21434 evidence.
- R155 and the CSMS
- R156 and the SUMS
- Evidence from ISO/SAE 21434
- 09
Worked Example
Take a connected brake and steering ECU through parallel HARA and TARA snippets, one resolved conflict and shared requirements.
- Integrated chassis module
- HARA and TARA snippets
- Diagnostic access conflict
- 10
Organisation & Pitfalls
Avoid the organizational anti-patterns and technical pitfalls of co-engineering and check your setup against good practice.
- Organizational anti-patterns
- Technical pitfalls
- Good-practice checklist
Read all 10 chapters with Expert.
Start with a free account: the complete Functional Safety Concept guide and 5 practice exams a month, then upgrade when you need this guide.
Expert plan pricingNot just text: the visual toolkit
Standards landscape
Which standards feed, co-apply with or regulate each other.
HARA and TARA on one event
The two analyses applied to the same hazardous event.
Safety-security conflict resolver
An interactive walk from a tension to a balanced design decision.
Connected-vehicle attack surface
Entry points mapped onto the safety-critical backbone.
R155 and R156 process map
How management system evidence flows into type approval.
Integrated chassis control module
A connected ECU that controls brake-by-wire and electric power steering is taken through both analyses, one conflict and the requirements both disciplines share.
- Item description with functions, connectivity and diagnostic access
- Selected hazardous events from the HARA
- Selected threat scenarios from the TARA
- Open diagnostic access against secure ECU access
- A shared requirements table
Unlock in course
Who this guide is for
- Safety engineers whose item now has external connectivity, OTA updates and a threat model
- Cybersecurity engineers who need their TARA to line up with an existing HARA
- Managers building the organizational interface between safety and security teams
- Teams preparing R155 and R156 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 and RBD simulators, and 5 practice exams per month. The Pro and Expert plans unlock more of the 93-guide library. No credit card required.
Continue with
Where this topic leads next.
- Beyond the standardAutomotive Cybersecurity with ISO/SAE 21434Learn how ISO/SAE 21434 runs cybersecurity engineering across a vehicle program: the organizational CSMS, item definition and assets, TARA from damage scenarios to risk treatment, cybersecurity goals and CAL, secure development, security testing, and what UNECE R155 and R156 demand after release.
- Beyond the standardSafety-Aware Machine Learning (ISO 8800)Engineer AI and ML components that survive a safety case. Learn the ISO/PAS 8800:2024 lifecycle on top of ISO 26262 and ISO 21448, covering dataset coverage, robustness, runtime monitoring, and assurance arguments.
- FoundationsFaults and FailuresLearn the complete fault taxonomy: single-point, residual, latent, and safe faults plus transient vs. permanent classifications. Covers FTTI analysis, dependent failure analysis, FMEDA calculations, and the bathtub curve.