This article lays out the technical methodology: where the standards interact at the clause level, how to map safety goals to cybersecurity goals, and what the typical organizational failure modes look like.
Why the Standards Have Structural Overlap
ISO 26262 was designed around the premise of random hardware failures and systematic software faults. Its risk framework — Automotive Safety Integrity Level (ASIL) — rates severity, exposure, and controllability. It does not model adversarial intent.
ISO/SAE 21434 was designed around intentional threats. Its risk framework — Cybersecurity Assurance Level (CAL) — rates impact, ease of attack, and feasibility. It does not produce functional safety requirements.
The structural gap: ISO 26262 defines safety mechanisms to protect against faults. Those safety mechanisms are software running on hardware connected to a network. An attacker who can disable or circumvent a safety mechanism achieves the same effect as the fault the mechanism was designed to catch — without triggering any failure mode analysis.
ISO 26262-9 Clause 7 requires safety mechanisms to achieve Diagnostic Coverage (DC) targets of ≥60% (ASIL A), ≥90% (ASIL B/C), or ≥99% (ASIL D). None of those DC calculations account for a mechanism that is working perfectly but has been silenced by a command injection attack.
Where the Clause References Intersect
The most actionable way to structure co-engineering is to map clause-level outputs from each standard to the inputs they require from the other.
The HARA-to-TARA link is the most critical. When your HARA identifies that uncommanded braking at highway speed is a hazardous event with ASIL D severity, that same scenario — caused by an attacker rather than a hardware fault — becomes a CAL 4 damage scenario in your TARA. The two analyses should share the scenario definition and reference each other explicitly.
The Shared Work Product Problem
Separate teams maintaining separate documents is where co-engineering breaks down. A safety engineer updates the safe state definition for an AEB function. The cybersecurity engineer's threat model still references the old safe state. The TARA no longer correctly assesses the attack surface. Nobody notices until an assessor asks for traceability between the two documents.
The specific documents that require co-ownership or explicit cross-referencing:
- Item definition: Must describe the security-relevant interfaces that also carry safety-critical data
- HARA: Must flag which hazardous events are reachable via cybersecurity attacks
- TARA: Must identify which assets are safety-relevant and map to HARA hazardous events
- Safety concept: Must include cybersecurity assumptions (e.g., "this safety mechanism assumes SecOC protects the CAN message carrying the enable signal")
- Software architecture: Must satisfy both safety partitioning (ISO 26262-6) and security separation (ISO 21434 Clause 10) — these requirements can conflict
The conflict case is real: ISO 26262 may require a watchdog to reset the ECU on any detected fault. ISO 21434 may require logging and network notification before any reset. If the security team implements their requirement independently of the safety team, the reset sequence may delay the safe state transition beyond the Fault Tolerant Time Interval (FTTI) — causing a safety violation in the course of implementing a security requirement.
Organizational Failure Modes
Beyond the technical integration, co-engineering fails for organizational reasons that are predictable.
Different suppliers. The Tier-1 safety team and the Tier-2 security module supplier have no shared review process. The security module's attack surface was never included in the HARA scope because it was procured separately.
Terminology mismatch. "Asset" means different things in safety (something that has value and must be protected) and in cybersecurity (same definition, but operationalized differently). Safety engineers and security engineers frequently talk past each other in joint reviews because neither has internalized the other standard's vocabulary.
No shared traceability. Safety requirements are in one tool; cybersecurity requirements are in another. Links between them exist only in email threads and meeting notes.
A Practical Co-Engineering Workflow
The following sequence integrates both standards without requiring a single merged team:
Shared item definition. Begin with a single item definition document that both safety and cybersecurity teams use as input. It must describe all external interfaces, including connectivity.
Parallel HARA and preliminary TARA. Run both analyses simultaneously with weekly synchronization. HARA hazardous events feed directly into TARA damage scenarios. Any hazardous event reachable by an attacker gets flagged in the HARA as having a security dependency.
Joint review of safety mechanism list. Before the safety concept is finalized, review every safety mechanism against the preliminary TARA attack paths. Identify mechanisms that are exposed to attack and add cybersecurity assumptions to the safety concept explicitly.
Shared software architecture review. A single architecture review that applies both ISO 26262-6 partitioning criteria and ISO 21434 isolation criteria. Conflicts are resolved at design time, not in separate reviews after the fact.
How ISO WIZ Supports Co-Engineering
ISO WIZ was built with the premise that safety and cybersecurity are not separate programs — they are one program with two regulatory dimensions. The platform maintains a unified item definition, a linked HARA and TARA, and a shared traceability graph that spans both standards.
When a safety engineer updates a safe state definition, ISO WIZ automatically flags the TARA damage scenarios that reference that safe state for re-review. When a cybersecurity engineer adds a new attack path, the system identifies which HARA hazardous events share the same triggering condition and prompts the safety team to assess whether the safety concept assumptions remain valid.
The cross-standard gap detection runs continuously. If a safety mechanism has no corresponding TARA analysis of its attack surface, that gap surfaces as an open finding — not as a surprise in a certification audit.
Co-engineering ISO 26262 and ISO 21434 correctly requires treating the two standards as architecturally linked from the start of the project. ISO WIZ provides the infrastructure to do that without doubling your documentation effort.