ISO 21448 SOTIF: What Your AEB / ADAS Team Needs in 2026

1. SOTIF is not ISO 26262 — and confusing them costs you a re-assessment

We see this misunderstanding in roughly half of the first ADAS programmes that land on our desk: the team has a clean ISO 26262 work product set, a tidy HARA, an ASIL decomposition that survives review — and then assumes the safety case is finished. It isn’t, because a different standard governs a different class of hazard.

ISO 26262 is about malfunctioning behaviour: something breaks. A bit flips in RAM, a transistor latches up, a CAN frame is corrupted, a sensor channel fails short-to-battery. You answer those with safety mechanisms, diagnostic coverage, FMEDA, hardware metrics (SPFM, LFM, PMHF) and a controllability argument. The fault is the root cause, and you can point to it.

ISO 21448:2022 — the Safety Of The Intended Functionality, SOTIF — is about the opposite situation: nothing is broken and you still have a hazard. The hardware is healthy, the software executes exactly as specified, every diagnostic reads green — and the function still does the wrong thing because its intended behaviour has performance limitations. A radar that cannot separate a stationary vehicle from an overhead gantry. A camera classifier that has never seen a particular trailer livery at dusk and confidently misclassifies it. An emergency-braking function that triggers on a steam plume because the perception chain genuinely believes there is an obstacle. No component failed. The function did what it was built to do, and that was unsafe in this scenario.

Two further SOTIF causes sit alongside performance limitations: foreseeable misuse (the driver leans on a Level 2 assist as though it were Level 3 and stops monitoring the road) and insufficient specification (the requirement never covered this corner of reality). None of these are addressed by an ISO 26262 safety mechanism, because there is no fault for a mechanism to detect. That is the whole point, and it is why a SOTIF gap will not show up in your FMEDA. For the functional-safety foundation that SOTIF builds on, our functional safety practice is the starting point, and the ASIL mechanics are covered in our ASIL D FuSa guide for Tier-1s.

2. The four areas — and where your real work lives

ISO 21448 frames the problem with a 2×2 partition of all possible scenarios, split on two axes: safe vs unsafe, and known vs unknown. It is the single most useful mental model in the standard, so we draw it on the whiteboard at every SOTIF kick-off.

Area 1 — known, safe. Scenarios you understand, where the function behaves acceptably. This is your specified, validated operating envelope. Good news, no further action beyond keeping it.
Area 2 — known, unsafe. Scenarios you have identified as hazardous — the steam plume, the gantry, the low-sun camera washout. You know about them, which means you can act: improve the algorithm, add a sensor modality, restrict the ODD, or add a SOTIF measure.
Area 3 — unknown, unsafe. The dangerous one. Hazardous scenarios nobody on the programme has thought of yet. They are unsafe and you do not know they exist — so you cannot have mitigated them.
Area 4 — unknown, safe. Scenarios you have not considered but which happen to be harmless. Less interesting, but they exist.

The entire SOTIF activity reduces to a single geometric goal: shrink Area 2 and Area 3. You shrink Area 3 (unknown-unsafe) by discovering scenarios — analysis, simulation, proving-ground exploration, field data mining — and pulling them into Area 2, where they become known. You then shrink Area 2 (known-unsafe) by engineering — pushing those scenarios into Area 1 through better perception, sensor fusion, ODD limits or functional restrictions.

The trap we see most often: teams pour effort into Area 2 because it is visible and tractable, while Area 3 — the residual risk that actually hurts — goes unfunded. The acceptance argument at the end of a SOTIF project is fundamentally a statement about how small you have driven Area 3 and why that residual is tolerable. If your plan has no explicit Area 3 reduction strategy, you do not yet have a SOTIF plan.

3. Integrating SOTIF into your existing safety work — reuse, don’t duplicate

The fear we hear most is that SOTIF means a second, parallel safety organisation with its own HARA, its own reviews and its own paperwork. It does not, and building it that way is how programmes lose a quarter. ISO 21448 is deliberately written to interlock with the ISO 26262 lifecycle, and the efficient route is to attach SOTIF activities to work products you already produce.

In practice we anchor SOTIF at a handful of existing points:

Item definition. The same item definition feeds both standards. For SOTIF you extend it with the ODD — the operational design domain — and with the sensing and decision performance the function relies on. This single addition drives most downstream SOTIF analysis.
Hazard analysis. Run the SOTIF hazard identification in the same workshop as the HARA where you can, with the same cross-functional team. The hazardous events are often shared; what differs is the cause. For each hazard you ask the ISO 26262 question (“what malfunction leads here?”) and the SOTIF question (“what performance limitation or misuse leads here with no fault?”). One workshop, two cause classes.
Functional and technical safety concept. SOTIF measures — sensor fusion, plausibility checks, ODD monitoring and degradation, driver-attention management for misuse — live alongside your ISO 26262 safety mechanisms in the same architecture, not in a separate document.
Verification and validation. The V&V campaign is shared infrastructure. The same HIL, the same simulation toolchain and the same proving-ground slots serve both fault-injection (26262) and scenario coverage (21448).

Where the two genuinely diverge is the nature of the argument. ISO 26262 gives you discrete, countable targets — metrics, coverage percentages, a PMHF figure. SOTIF gives you a statistical and completeness argument over a continuous scenario space, which is harder to close and needs a different evidence mindset. Recognising that early prevents the most expensive mistake: trying to force SOTIF residual risk into a single ASIL-style number it was never meant to produce.

4. Triggering conditions and the scenario catalogue

The engine of SOTIF analysis is the triggering condition: the specific input or environmental circumstance that exposes a performance limitation and turns a benign function into a hazardous one. Not the limitation itself — the condition that activates it. Low sun directly behind a pedestrian. Heavy spray reducing radar return. A cyclist whose silhouette overlaps a parked car. Retroreflective road furniture that mimics a vehicle signature. Snow occluding lane markings. Each is a triggering condition, and identifying them systematically is the bulk of the analytical work.

We drive this from the ODD outward. The operational design domain — road types, speed ranges, weather, lighting, traffic density, geographic scope — is the boundary of where the function is allowed to operate. Every dimension of the ODD is a source of triggering conditions: each weather state, each lighting transition, each road-furniture type, each manoeuvre by a surrounding actor. We decompose the ODD methodically and, for each cell, ask which performance limitations of the sensing and decision chain it could excite.

That feeds the scenario catalogue — the living, structured inventory of scenarios that defines what the function must handle and what it is tested against. A useful catalogue is not a flat list; it is organised so that scenarios are parameterised (ego speed, target speed, time-to-collision, illumination, surface friction) and traceable back to the ODD dimension and triggering condition that motivated them. The same catalogue then becomes the test specification for Section 5.

Two disciplines separate a catalogue that earns trust from one that does not. First, it must be maintained: every new triggering condition found in simulation, on the proving ground or in field data is folded back in, so the catalogue grows toward completeness rather than freezing at SOP. Second, it needs an explicit completeness rationale — how do you argue you have not missed a whole class of scenario? We use structured ODD decomposition, established scenario taxonomies, expert-elicitation workshops and field-data analytics in combination, precisely because no single source is complete on its own. Building this catalogue and the analysis behind it is core safety-software engineering work, and getting the method right early is what we cover in our SOTIF training and consulting.

5. Verification and validation — and the “how much testing is enough” argument

SOTIF V&V is scenario-based, and it runs across three tiers that trade coverage against fidelity:

Simulation. Where you get scale. You can sweep thousands of parameter variations of a triggering condition, run sensor and environment models, and probe the unknown-unsafe space far faster than any physical test. This is your primary tool for exploring Area 3. Its weakness is fidelity — a sensor model is only as good as its validation against reality.
Proving ground. Where you get controlled, repeatable physical truth for the highest-severity scenarios — AEB on soft targets, vulnerable-road-user cut-ins, low-friction surfaces. Lower volume, high confidence.
Field / on-road. Where reality surprises you and feeds Area 3 discovery. Open-road and shadow-mode data is where genuinely unforeseen triggering conditions surface, which then flow back into the catalogue and the simulation sweeps.

The metric that ties this together is ODD coverage: have you exercised the function across every dimension and combination of its declared operating domain, against defined acceptance criteria? Acceptance criteria must be set before testing — a measurable bar per scenario class (e.g. required detection range, time-to-brake, false-activation rate under defined conditions) that the function must meet for the residual risk to be deemed acceptable.

Which brings the question every programme eventually asks: how much testing is enough? For a continuous scenario space you cannot test exhaustively, and naive statistical arguments demand implausible mileage to demonstrate safety by brute force alone. The SOTIF answer is not “more kilometres”; it is a structured completeness argument. You combine targeted scenario coverage of the known-unsafe region, simulation-led exploration of the unknown-unsafe region, a defensible ODD-decomposition completeness rationale, and an acceptance criterion on residual risk — and you argue, with evidence, that further testing yields diminishing reduction of Area 3. “Enough” is the point where your discovery methods stop surfacing new hazardous scenarios and your residual-risk argument holds. That is an engineering and evidence judgement, not a mileage counter.

6. The regulatory push — SOTIF is no longer optional

For a while, SOTIF could be treated as a maturity goal — nice to have, deferred under schedule pressure. Regulation has closed that door. The EU General Safety Regulation, Regulation (EU) 2019/2144, makes a suite of advanced driver-assistance systems mandatory on new vehicle type-approvals and, in its phased timeline, across new registrations: advanced emergency braking (AEB), intelligent speed assistance, emergency lane-keeping, driver-drowsiness and attention warning, and more.

The consequence is direct. If a regulation mandates that an ADAS function be present, then a performance limitation in that function — an AEB that fails to detect, or that activates spuriously — is a safety problem in a regulated, type-approved system. That is precisely the SOTIF domain: no fault, but a hazard from the intended functionality. You can no longer ship the function and treat its perception limits as an unspecified residual. A SOTIF argument — ODD, triggering conditions, scenario coverage, acceptance criteria, residual-risk justification — is now part of demonstrating that a regulated function is safe enough to put on the road.

In practical terms, this means OEM programmes increasingly flow SOTIF expectations down to Tier-1 suppliers as contractual deliverables alongside the ISO 26262 work products. We now see SOTIF requirements appearing in statements of work where, two or three years ago, there were none. A perception or AEB supplier that cannot produce a credible SOTIF argument is, increasingly, not a viable supplier for these functions. The standard has become a market-access condition, not a badge.

7. Evidence — the SOTIF argument alongside the functional safety case

Everything above exists to produce one thing: a SOTIF argument — a structured, evidence-backed case that the residual risk from performance limitations and foreseeable misuse has been driven acceptably low. It sits beside your ISO 26262 functional safety case, not inside it, because it argues a different claim with different evidence.

A SOTIF argument that survives assessment links a chain that an assessor can walk end to end:

Item definition and ODD — the function, its boundaries, and the declared operating domain it is validated within.
Hazard identification — the hazardous events and the performance-limitation and misuse causes behind each, the Area 2 inventory.
Triggering conditions — traced from ODD decomposition to the specific conditions that expose each limitation.
SOTIF measures — the architectural and functional responses (fusion, plausibility, ODD monitoring and degradation, misuse handling) and which scenarios each addresses.
V&V evidence — the simulation, proving-ground and field results showing acceptance criteria met across ODD coverage.
Completeness and residual-risk rationale — why Area 3 has been driven small enough, and why the remaining residual is acceptable.

Two qualities decide whether that argument holds. The first is traceability: every test must trace to a triggering condition, every triggering condition to an ODD dimension, every hazard to a measure and its evidence. Gaps in that chain are exactly where an assessor — or a field incident — finds the hole. The second is honesty about residual risk: a credible SOTIF argument does not claim zero risk over a continuous scenario space. It states the residual plainly and justifies why it is acceptable against defined criteria. We have watched arguments fail not because the engineering was weak, but because the residual was hidden rather than owned.

Read alongside the functional safety case, the two together answer the complete question a regulator and an OEM now ask: the malfunction risk is controlled (ISO 26262), and the intended-functionality risk is acceptable (ISO 21448). For a perception or AEB programme in 2026, neither half stands on its own — and the SOTIF half is the one most teams are still learning to build.

Want a 30-min walkthrough on your project?

No NDA needed. Tell us the standard, the item or asset, the assessor, and your deadline. Within 48 hours you’ll get a one-page diagnostic mapped to the points above — yours to keep, whether or not you hire us.

Book a FuSa walkthrough

Author: Adrian Valea, Founder & Managing Director, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Published 2026-05-30.

ISO 21448 SOTIF for ADAS no fault, still a hazard.