ISO 26262, SOTIF, and ISO 21434: Why You Can't Run Them as Separate Projects

Three Standards. Three Teams. Three Spreadsheets.

Walk into most automotive safety programs today and you'll find the same pattern. The functional safety team is running ISO 26262 out of a requirements tool and a HARA spreadsheet. The ADAS validation team is managing SOTIF (ISO 21448) in a separate document set — usually inherited from the systems team who did the scenario analysis. The cybersecurity team is in a different building, maintaining a TARA in yet another tool, with loose references to the safety concept that nobody has formally connected.

Three standards. Three teams. Three data stores. Minimal structured linkage between them.

This setup feels manageable early in the program. By the time you're preparing for a Tier 1 audit or a CSMS certification review, it generates a specific and expensive class of problem: questions that nobody can answer without a week of manual reconstruction.

"How does your cybersecurity TARA connect to your functional safety concept?"

"Which SOTIF triggering conditions are also addressed in your ISO 26262 HARA?"

"If a cyberattack compromises sensor data integrity, which safety goals are potentially undermined — and how are those addressed in your Technical Safety Concept?"

These aren't trick questions. They're exactly what an integrative safety assessment expects you to have answered. And in a siloed program, the honest answer is: nobody knows without pulling three teams into a room for several days.

Why the Standards Are Designed to Overlap

ISO 26262, ISO 21448 SOTIF, and ISO 21434 are not three independent domains. They address three different causes of the same outcome: a vehicle harming someone.

• ISO 26262 addresses safety violations caused by faults in electrical/electronic systems — hardware failures, software bugs, systematic design errors.
• ISO 21448 SOTIF addresses safety violations caused by the intended functionality performing below expectations — sensor limitations, classifier errors, edge cases outside the training distribution. No fault required.
• ISO 21434 addresses safety violations caused by deliberate adversarial action — an attacker exploiting a vehicle system to cause harm, disable a safety function, or manipulate control outputs.

All three converge on the same system artifacts: the item definition, the operational scenarios, the hazardous events, the safety goals, and the verification evidence. The boundaries between them are porous by design.

ISO 21448 Clause 4 explicitly states that SOTIF development shall be performed in conjunction with ISO 26262 functional safety activities, and that SOTIF requirements shall be consistent with the Technical Safety Concept.

ISO 21434 Clause 5.4.3 requires that cybersecurity goals which impact functional safety shall be coordinated with the functional safety activities.

The standards themselves are telling you to integrate. The question is whether your program has a mechanism to do it.

The Overlapping Scenario Problem

Consider a concrete example: camera-based automatic emergency braking (AEB) in adverse lighting conditions.

Under ISO 26262, your HARA identifies "unintended braking at highway speed" as a hazardous event with ASIL C or D. Your functional safety concept includes a monitoring function that validates AEB commands before they're executed. Safety goal: The AEB system shall not initiate braking above 0.3g without validated object detection confirmation.

Under ISO 21448 SOTIF, your scenario analysis identifies sun glare directly into the camera as a triggering condition. The camera outputs high-confidence false positive detections. Your SOTIF analysis says: this triggering condition maps to "unintended braking" — you need either ODD restriction (no AEB in direct sun conditions) or validation evidence that the detection algorithm rejects glare artifacts with sufficient confidence.

Under ISO 21434, your TARA identifies "sensor data injection via diagnostic bus" as a threat scenario. An attacker with physical access injects crafted sensor packets that make the AEB system perceive a non-existent obstacle. Your cybersecurity goal: The AEB sensor data path shall authenticate inputs and reject injected data.

Same hazardous event — unintended braking — arising from three different causes. Three different analyses, in three different documents, with three different proposed mitigations.

The problem: none of those mitigations were reviewed for consistency with each other.

The ISO 26262 monitoring function assumes sensor data arrives from a legitimate source — its detection algorithm wasn't designed to handle injected adversarial data. The SOTIF ODD restriction for sun glare doesn't mention that an attacker could simulate sun-glare-like inputs at any time of day. The cybersecurity authentication mechanism wasn't evaluated for whether it interferes with the safety monitoring function's timing requirements.

In a siloed program, each of these gaps lives in the negative space between documents that nobody owns. In an integrated program, they surface as cross-standard traceability alerts before the design is frozen.

What Integration Actually Requires

Real integration isn't about sharing a file server or having a weekly cross-team meeting. It requires three structural things:

1. A Shared Scenario and Hazard Model

Operational situations in ISO 26262 HARA, SOTIF triggering conditions, and ISO 21434 damage scenarios should all reference the same underlying scenario descriptions. When the systems team adds a new operational scenario — say, construction zone driving at reduced speed — that addition should automatically surface in all three analyses as a potential gap item.

Without a shared model, scenario coverage decisions are made independently in each standard. You get inconsistent ODD definitions, different assumptions about exposure, and safety goals that silently assume away the scenarios another analysis is trying to cover.

2. Cross-Standard Traceability Between Hazardous Events and Threats

Every cybersecurity threat scenario that can lead to physical harm should link to the ISO 26262 hazardous event it could precipitate. Every SOTIF triggering condition that produces an unsafe output should link to the functional safety concept requirement that addresses the same hazardous event.

This isn't complex to set up, but it requires a data model that spans standards rather than treating each standard as its own isolated record system.

3. Consistent Safety Mechanism Review

Safety mechanisms designed to satisfy ISO 26262 safety goals need to be reviewed against two additional questions:

• Can a SOTIF triggering condition defeat this mechanism? (A monitoring function that relies on sensor data being valid doesn't help when the sensor is generating plausible-but-wrong outputs.)
• Can a cybersecurity attack compromise this mechanism? (A redundant channel provides independence against random faults, but not against an attacker who can address both channels through the same communication bus.)

These questions can't be answered by the safety team in isolation. They require the SOTIF and cybersecurity analyses to be structurally connected to the safety concept review.

The Audit Consequences of Getting This Wrong

Functional safety assessors are increasingly trained to probe cross-standard consistency. The SAE/ISO harmonization working groups have published guidance on integrated safety and security analysis. Tier 0.5 customers — direct OEM suppliers — are starting to require evidence of multi-standard traceability, not just independent compliance artifacts for each standard.

Specific findings that come from siloed approaches:

"Cybersecurity threats to safety-critical functions not reflected in functional safety concept." The TARA identifies that an attacker can disable the safety monitoring channel, but the FSC doesn't mention this attack path. Finding: the safety case is incomplete.

"SOTIF triggering conditions not evaluated against safety mechanism robustness." The FSC assumes sensor data validity. The SOTIF analysis identifies conditions where sensor data is plausible but wrong. These have never been reviewed together. Finding: undocumented gap in safety mechanism coverage.

"No rationale for SOTIF/ISO 26262 boundary at triggering condition boundary." The SOTIF analysis terminates a triggering condition at "sensor output degradation." The ISO 26262 HARA starts at "incorrect input to AEB function." The boundary between them — who owns the failure mode between sensor output and AEB function input — is undocumented. Finding: potential coverage gap.

What Integration Looks Like in Practice

The teams building ISO WIZ started from this specific problem: programs that are technically compliant with each standard in isolation but have structural gaps at the boundaries between standards.

The architecture is a shared data model where the same operational scenario record drives HARA scenario analysis, SOTIF triggering condition documentation, and TARA damage scenario definitions. When you derive a safety goal in ISO 26262, the platform surfaces any cybersecurity threats and SOTIF triggering conditions linked to the same hazardous event — so the safety mechanism review automatically includes the cross-standard questions.

When an ISO 21434 cybersecurity goal changes — say, the attack feasibility rating for a threat scenario increases — the platform flags any ISO 26262 safety goals that relied on that threat being low-risk. Cross-standard consistency is maintained continuously, not reconstructed manually at assessment time.

This is what "harmonized" means in practice. Not four workstreams running in parallel with a meeting to reconcile at the end. One data model, one traceability graph, four compliance views derived from it.

The Practical Starting Point

If your program is currently running ISO 26262, SOTIF, and ISO 21434 as separate workstreams, the most valuable first step is not to rebuild your data from scratch. It's to map the connections you already have:

1. List your safety goals. For each one, identify which SOTIF triggering conditions can produce the same hazardous event without a fault.
2. For each safety goal, identify which cybersecurity threat scenarios in your TARA could undermine the safety mechanism designed to address it.
3. Document the gaps explicitly. Where a connection exists but is unreviewed, that's a known gap. Where no connection has ever been drawn, that's a potential unknown gap.

That mapping exercise is the foundation of an integrated program. It's also, incidentally, exactly what an integrative safety assessor will reconstruct from your documents if you don't do it yourself.

ISO WIZ automates this mapping and keeps it current throughout the program lifecycle. But even without tooling, the exercise of making these cross-standard connections explicit is the difference between a program that passes assessment and one that gets sent back for a reconciliation sprint two weeks before launch.