No single team knows that their three requirements interact. In heavy rain, a spoofed radar disruption message could trigger the safe state while a legitimate SOTIF-relevant degradation is already in progress — and the security module's logging requirement adds 200 ms to the safe state transition, pushing total response time beyond the FTTI.
This is not an edge case. It is the predictable consequence of three standards that were written independently, by different working groups, for problems that are physically inseparable in a modern vehicle.
The Structural Dependencies
Each standard has explicit or implicit dependencies on the other two that are often treated as someone else's problem.
ISO 26262 Depends on ISO 21434
ISO 26262 defines safety mechanisms and specifies that they must achieve Diagnostic Coverage targets. But ISO 26262-9 Clause 6 also requires that freedom from interference be demonstrated — that the elements implementing safety mechanisms cannot be disrupted by other software or hardware in the system.
A cybersecurity attack that disrupts a safety mechanism is a failure of freedom from interference. ISO 26262 does not have a methodology for analyzing intentional attacks; it assumes the software environment is well-behaved. ISO 21434 provides the threat analysis methodology that fills this gap. If your safety concept includes a software safety monitor, your TARA must include that monitor as an asset and analyze what happens if it is compromised.
This dependency is not optional. ISO 26262-8 Clause 6 requires cybersecurity to be considered as part of the safety lifecycle. Teams that run ISO 26262 without any connection to ISO 21434 have a documented gap in their safety concept.
ISO 21434 Depends on ISO 26262
ISO 21434 Clause 15 (threat analysis and risk assessment) requires that the impact of a cybersecurity attack be assessed. Impact assessment for a vehicle attack must include safety impact — the severity of the hazardous event that would result if the attack succeeded.
ISO 26262 HARA provides exactly this: a structured, ASIL-rated severity assessment for each hazardous event. A TARA that assesses impact without referencing the HARA severity ratings is either duplicating work or introducing inconsistencies. If the HARA rates uncommanded acceleration as S3 severity, the TARA should reflect that rating in its impact assessment — and if the TARA independently derives a different severity, one of them is wrong.
SOTIF Depends on Both
ISO 21448 addresses the safety of the intended functionality — the residual risk from a system that is working exactly as designed but whose design has limitations. For ADAS and automated driving systems, SOTIF requires identification of triggering conditions: operational scenarios that cause the system's performance to fall below acceptable bounds.
SOTIF triggering conditions that result from the system being in a degraded state — one of its sensors partially obscured, one of its processing channels running at reduced capacity — must be assessed in the context of what degraded state is possible. That context comes from ISO 26262: the FMEDA and fault tree analysis define the credible single-point and multi-point failure states. If the ISO 26262 analysis shows that a radar sensor can lose 40% of its range in a credible single fault, the SOTIF analysis must include that degraded range as a triggering condition input.
Conversely, a SOTIF-identified triggering condition that involves vehicle behavior exceeding the driver's ability to control it is a safety issue — and that safety issue must be reflected in the ISO 26262 HARA as a hazardous event. If the SOTIF team identifies a new triggering condition, the HARA may need to be updated.
The Cost of Running Them Separately
The direct costs of separate programs are visible: three teams, three tool licenses, three sets of review meetings, three sets of documentation packages for the OEM.
The indirect costs are larger. Cross-standard rework — discovering in the ISO 26262 review that the cybersecurity architecture invalidates a safety assumption — is typically 3–5x more expensive than catching the same issue during a joint design review. Finding a gap in a certification audit, when both the safety and cybersecurity certificates are in scope, can delay vehicle launch by months.
The hidden cost is silent inconsistency: documentation that appears complete for each standard independently but contains logical contradictions at the boundaries. These contradictions often do not surface until a regulator or assessor asks for a traceability matrix connecting the three standards — at which point the development organization discovers it does not have one.
The Integration Architecture
The minimum integration architecture:
Shared item definition. A single document, owned by systems engineering, that defines the item being developed. All three standards use this as their starting point. Changes to it trigger review across all three.
HARA-TARA synchronization checkpoint. After the HARA is baselined and after the TARA is baselined, a joint review confirms that severity ratings are consistent and that all safety-relevant functions appear as assets in the TARA.
Safety concept cybersecurity assumption review. Before the safety concept is finalized, the cybersecurity team reviews every safety mechanism for attack surface. Safety mechanisms that depend on the integrity of a networked signal must carry an explicit cybersecurity assumption, and the TARA must address that assumption.
SOTIF-HARA boundary review. When the SOTIF triggering condition list is baselined, a joint review with the safety team confirms that triggering conditions that result in hazardous events are captured in the HARA, and that HARA degraded states are reflected in the SOTIF analysis.
Change impact process. Any change to a work product in one standard must be assessed for impact on the other two before it is closed. This does not require a full re-analysis; it requires a structured impact question: does this change affect any assumption that the adjacent standard relies on?
Why Tooling Matters
The integration architecture described above is achievable with discipline and manual process. Teams do it. The problem is that manual process degrades under schedule pressure. The HARA-TARA synchronization checkpoint gets skipped once, then twice, then it stops appearing on the schedule. The change impact question gets answered in an email that nobody reads six months later.
Tooling enforces the linkages that manual process forgets. When the HARA severity rating for a hazardous event changes, the tool can automatically flag the linked TARA damage scenario for re-review — without requiring anyone to remember that the link exists.
Running ISO 26262, SOTIF, and ISO 21434 as a single integrated program is not a tooling problem — it is an engineering architecture decision. But tooling is what makes that architecture maintainable over a multi-year vehicle development program.