ISO 26262 vs SOTIF vs ISO/SAE 21434: Functional Safety, Intended Functionality and Cybersecurity Compared

An automatic emergency braking system can be built with zero hardware faults, flawless code and perfect key management, and still slam on the brakes for a shadow under a bridge. That single scenario explains the whole iso 26262 vs sotif debate. ISO 26262 asks what happens when the electronics fail. ISO 21448 asks what happens when the electronics work exactly as designed but the design is not good enough for the world. ISO/SAE 21434 asks what happens when someone makes the system misbehave on purpose.

It matters now because these questions no longer live in separate departments. Perception stacks with machine learning, over-the-air updates and type-approval rules under UN Regulations 155 and 156 force one ADAS feature to carry three linked arguments at once.

You will leave with a precise comparison table, the mechanics of HARA, ASIL decomposition, triggering-condition analysis, TARA and CAL, and a worked ADAS example that shows exactly where the three lifecycles hand work to each other.

What this covers: scope and editions of each standard, the risk models they use, a side-by-side decision matrix, an AEB worked example, tool qualification, the IEC 61508 lineage, and the failure modes of running the three as silos.

Context and Background

Automotive electronics safety grew out of the generic industrial standard IEC 61508. If you already work with safety instrumented systems, our explainer on IEC 61508 SIL, PFD and safety PLC architecture covers the parent framework. IEC 61508 assumes a fairly stable plant, a defined demand rate and a professional operator. Cars violate all three assumptions: they are mass-produced, driven by untrained people, and used in an open world.

ISO 26262 was the automotive adaptation. The first edition appeared in 2011. The current second edition, ISO 26262:2018, has twelve parts. It added Part 11 on semiconductors and Part 12 on motorcycles, and extended scope from passenger cars to trucks, buses and motorcycles. Its subject is functional safety: absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical and electronic (E/E) systems.

That definition left a gap. A camera that never faults can still misclassify a plastic bag as a pedestrian. ISO/PAS 21448:2019 was the first attempt to fill the gap, and it became the full international standard ISO 21448:2022 in June 2022. Its subject is the safety of the intended functionality (SOTIF): absence of unreasonable risk due to functional insufficiencies of the intended function or its implementation, including reasonably foreseeable misuse. The 2022 edition explicitly extended scope to all levels of driving automation.

Cybersecurity followed a parallel path. SAE J3061 (2016) was a guidebook. ISO and SAE jointly replaced it with ISO/SAE 21434:2021, published in August 2021 as an engineering standard for road vehicle cybersecurity. It became commercially decisive because UN Regulation 155 requires a certified cybersecurity management system (CSMS) for type approval, and 21434 is the most common way manufacturers demonstrate the processes behind that system.

The newest entrant is ISO/PAS 8800:2024, published in December 2024, which addresses safety of AI elements in road vehicles. ISO/TS 5083:2025 covers safety of automated driving systems. Neither replaces the big three; both lean on them. The ISO 21448 catalogue page and the ISO/PAS 8800 page list the official scopes.

My thesis: the three standards are not three checklists. They are three hazard-cause models feeding one safety case, and most programmes fail at the interfaces between them, not inside any one of them.

ISO 26262 vs SOTIF vs ISO/SAE 21434: Three Hazard-Cause Models

Direct answer: ISO 26262 covers hazards caused by malfunctions of E/E systems, meaning random hardware faults and systematic faults. ISO 21448 (SOTIF) covers hazards that arise with no fault at all, from functional insufficiencies such as sensor limits triggered by real-world conditions. ISO/SAE 21434 covers risks from deliberate attacks on vehicle E/E systems and their interfaces.

Figure 1: Three causal routes to the same vehicle-level harm. Faults route through ISO 26262, functional insufficiencies with triggering conditions route through ISO 21448, and threat scenarios route through ISO/SAE 21434.

Read the figure from the bottom up. The harm at the top, an unintended full brake on a motorway, is identical in all three routes. What differs is the cause. A stuck-at fault in a radar MCU is a malfunction. A radar return from a steel manhole cover that the fusion algorithm accepts as an obstacle is a functional insufficiency activated by a triggering condition. A spoofed CAN frame injected through a compromised telematics unit is a threat scenario. The vehicle cannot tell the difference, and neither can the driver behind you.

Each standard owns a cause, not a component

The most common misunderstanding is to treat the standards as owning parts of the vehicle: “26262 for the ECU, SOTIF for the sensor, 21434 for the gateway.” That mapping is wrong. A single camera ECU is subject to all three. Its silicon has random faults (26262 Part 5 and Part 11). Its neural network has performance limits in low sun (21448). Its firmware update interface is an attack surface (21434).

ISO 21448 makes the boundary explicit. It states that ISO 26262 addresses E/E faults and assumes the intended functionality is safe, while SOTIF addresses the cases where the intended functionality itself is insufficient. ISO 26262-2:2018 also asks for communication channels between functional safety and cybersecurity activities, because an attack can produce the same violation of a safety goal as a fault.

The practical rule follows: assign each hazard cause to the standard that owns its cause mechanism, then merge the resulting requirements onto the components. Never start from the component.

Each standard uses a different risk currency

ISO 26262 rates hazards with the Automotive Safety Integrity Level (ASIL). The hazard analysis and risk assessment (HARA) in Part 3 rates each hazardous event for Severity (S0 to S3), probability of Exposure (E0 to E4) and Controllability (C0 to C3). The combination maps to QM (quality management only) or ASIL A to D, with ASIL D reserved for S3, E4 and C3. The ASIL then dictates the rigour of methods across Parts 4 to 9 and, for hardware, quantitative targets.

ISO 21448 deliberately has no integrity level. A hazard is either acceptable or not against acceptance criteria for residual risk, which the developer defines and justifies. Those criteria are then turned into validation targets, such as a quantity of driving or a set of scenario coverage goals that must be met to argue the residual risk is low enough. The standard explains how to derive and argue targets. It does not prescribe numbers, and you should be suspicious of any vendor slide claiming that it does.

ISO/SAE 21434 rates risk through the threat analysis and risk assessment (TARA) methods in Clause 15. A damage scenario receives an impact rating across safety, financial, operational and privacy categories. A threat scenario receives an attack feasibility rating. Impact and feasibility combine into a risk value, and the organisation decides treatment: avoid, reduce, share or retain. The cybersecurity assurance level (CAL), defined in an informative annex with levels CAL 1 to CAL 4, is an optional way to scale assurance rigour. It is not an ASIL equivalent, and 21434 is careful not to make it normative.

Each lifecycle has a different shape

The ISO 26262 lifecycle is a V. It runs from item definition through HARA, functional safety concept, technical safety concept, hardware and software development, integration and safety validation, then production and operation. Its centre of gravity is development before start of production.

The SOTIF lifecycle is a loop. Clause 5 specifies the function. Clauses 6 and 7 identify hazards, functional insufficiencies and triggering conditions. Clause 8 modifies the function to address risk. Clauses 9 to 11 define and execute verification and validation for known and unknown scenarios. Clause 12 evaluates achievement of SOTIF, and Clause 13 extends activities into operation. When validation finds a new triggering condition, the loop restarts at specification.

The ISO/SAE 21434 lifecycle is a V with a long tail. Clauses 9 to 11 cover concept, product development and validation. Clauses 12 to 14 cover production, operations and maintenance, and end of support. Clause 8 defines continual activities: cybersecurity monitoring, event assessment, vulnerability analysis and vulnerability management. Because threats evolve after the car ships, 21434 spends more of its text on the post-production phase than the other two.

Why this matters for evidence

Those shapes predict where evidence lives. A 26262 safety case is front-loaded: FMEDA tables, verification reports, confirmation reviews. A SOTIF argument is statistical and scenario-based: coverage of an operational design domain, field data, simulation campaigns. A 21434 case is partly live: an incident response plan and a vulnerability backlog that keep changing for the vehicle’s support period. Merging three kinds of evidence with different half-lives into one coherent argument is the real engineering problem.

Side-by-Side Comparison: Scope, Metrics and Evidence

The table below is the reference most teams want pinned to the wall. It compares the current published editions as of November 2026.

Dimension	ISO 26262:2018	ISO 21448:2022 (SOTIF)	ISO/SAE 21434:2021
Question answered	What if the E/E system malfunctions?	What if the function works as specified but is insufficient?	What if someone attacks the E/E system?
Hazard cause	Random hardware faults, systematic faults	Functional insufficiencies plus triggering conditions, foreseeable misuse	Threat scenarios realised through attack paths
Edition and structure	2nd edition, 12 parts	1st edition as IS, 13 clauses plus Annexes A to D	1st edition, 15 clauses plus annexes
Predecessor	ISO 26262:2011, derived from IEC 61508	ISO/PAS 21448:2019	SAE J3061:2016
Core analysis	HARA	Hazard identification, functional insufficiency and triggering-condition analysis	TARA
Risk metric	ASIL A to D or QM, from S, E and C	Acceptance criteria for residual risk, validation targets	Impact and attack feasibility, combined into risk value
Integrity scaling	ASIL drives method tables and hardware metrics	No integrity level	Optional CAL 1 to 4, informative
Quantitative hardware targets	Yes, SPFM, LFM, PMHF in Part 5	No	No
Top-level requirement	Safety goal	Acceptable residual risk for the intended functionality	Cybersecurity goal, cybersecurity claim
Lifecycle shape	V-model, development centric	Iterative loop with known and unknown scenario evaluation	V-model plus continual activities after SOP
Post-production focus	Field monitoring, production, decommissioning	Operation phase activities, field monitoring of triggering conditions	Monitoring, vulnerability management, incident response, end of support
Typical regulatory hook	Referenced by OEM contracts and assessors, not a UN regulation itself	Referenced in ADAS and ADS assessments	Process evidence for UN R155 CSMS, related to R156
Typical evidence	FMEDA, FTA, DFA, verification reports, confirmation reviews	Scenario catalogues, simulation and road test campaigns, coverage arguments	TARA reports, penetration tests, vulnerability records

Three rows deserve a closer look because they generate the most confusion: ASIL decomposition, the hardware metrics, and CAL.

ASIL decomposition, done correctly

ASIL decomposition is defined in ISO 26262-9. It lets you implement a safety requirement with redundant, sufficiently independent elements, each carrying a lower ASIL. The permitted schemes for an ASIL D requirement are D(D) plus QM(D), C(D) plus A(D), and B(D) plus B(D). For ASIL C the options are C(C) plus QM(C) and B(C) plus A(C). For ASIL B they are B(B) plus QM(B) and A(B) plus A(B). The letter in brackets records the original ASIL, which still governs some activities.

Three conditions make decomposition legitimate. First, the redundant elements must each be capable of achieving the safety goal on their own. Second, you must show sufficient independence through a dependent failure analysis (DFA) that covers common-cause and cascading failures. Third, decomposition does not reduce the hardware metric targets, which still apply at the level of the original safety goal.

The trap is decomposing two channels that share a power supply, a clock, a sensor or a software library. On paper you have B(D) plus B(D). In practice a single brown-out takes out both. The DFA is where decomposition succeeds or fails, and it is usually the weakest document in the safety case.

Hardware architectural metrics and PMHF

ISO 26262-5 defines three quantitative hardware evaluations. The single-point fault metric (SPFM) measures how well the hardware is protected against single-point and residual faults. The latent fault metric (LFM) measures coverage of multiple-point faults that could stay hidden. The probabilistic metric for random hardware failures (PMHF) estimates the residual rate at which random hardware faults violate a safety goal.

The commonly applied target values from Part 5 are as follows. ASIL B: SPFM at least 90 percent, LFM at least 60 percent, PMHF below 10^-7 per hour (100 FIT). ASIL C: SPFM at least 97 percent, LFM at least 80 percent, PMHF below 10^-7 per hour. ASIL D: SPFM at least 99 percent, LFM at least 90 percent, PMHF below 10^-8 per hour (10 FIT). The standard presents these as possible sources for target derivation, and some OEMs set tighter budgets for individual ECUs because a vehicle-level safety goal is shared across several items.

None of this has an equivalent in SOTIF or 21434. A perception insufficiency has no failure rate in FIT, and attack feasibility is not a probability. Attempts to translate a SOTIF validation target into a PMHF-like number usually smuggle in assumptions that the standard does not support.

SOTIF scenario areas and triggering conditions

ISO 21448 organises its argument around four scenario areas: known safe, known unsafe, unknown unsafe and unknown safe. The goal of SOTIF activities is to shrink the known unsafe area by design changes, and to shrink the unknown unsafe area by discovering scenarios through analysis, simulation and testing until the residual risk meets the acceptance criteria.

A triggering condition is a specific condition of a scenario that activates a functional insufficiency and leads to hazardous behaviour. Low sun on a wet road, a tunnel exit, a truck with a high ground clearance, retro-reflective road furniture, or a driver who leans on the accelerator while ACC is active are all triggering-condition candidates. The analysis in Clause 7 pairs each potential insufficiency of specification or performance with the conditions that can trigger it.

The point to internalise is that SOTIF validation is never complete in the way a 26262 test campaign is complete. You argue that the residual risk of the unknown unsafe area is acceptably low, using exposure-weighted evidence. That is a fundamentally statistical and scenario-coverage argument.

TARA and CAL mechanics

A 21434 TARA starts with asset identification: data, functions and components whose compromise causes damage. For each asset, cybersecurity properties such as confidentiality, integrity and availability are considered. Damage scenarios describe the adverse consequence, and threat scenarios describe how a property could be compromised.

Impact rating uses four categories: safety, financial, operational and privacy. Attack path analysis then decomposes each threat scenario into steps, and attack feasibility is rated. The standard describes three approaches: attack-potential based (elapsed time, specialist expertise, knowledge of the item, window of opportunity, equipment), CVSS based, and attack-vector based. Impact and feasibility combine into a risk value, which drives a treatment decision and, where risk is reduced, cybersecurity goals.

CAL is a separate dial. It expresses how much assurance you want that the item is protected, scaling the rigour of verification activities such as penetration testing depth. Because CAL lives in an informative annex, organisations define their own determination tables, usually from impact and attack vector. Treat any CAL-to-ASIL mapping as an internal convention, not a requirement of either standard.

Worked Example: Automatic Emergency Braking Under All Three Standards

Abstract comparison only goes so far. Let us walk one ADAS feature through all three lifecycles and watch the handoffs. The feature is a motorway-capable automatic emergency braking (AEB) function using a front camera and a front radar, fused in a dedicated ADAS domain controller, commanding deceleration through the brake ECU over the vehicle network.

All ratings below are illustrative. Real ASILs depend on the item definition, the operational situations catalogued and the OEM’s own exposure and controllability rationale, and different manufacturers legitimately reach different values for similar functions.

Figure 2: Where the three lifecycles exchange work products for the AEB example. The item definition is shared, HARA and TARA cross-reference each other, SOTIF findings feed functional modifications, and all three converge in one integrated safety case.

The figure shows a single item definition at the top. From it, three analyses run in parallel. The HARA produces safety goals. The SOTIF hazard and triggering-condition analysis produces functional modifications and validation targets. The TARA produces cybersecurity goals. The arrows between them are the interfaces most programmes forget to formalise.

Step 1: one item definition, three readers

The item definition describes the function, its boundaries, interfaces, operating modes and the operational design domain (ODD). For AEB it states the speed range, the object types it should react to, the actuators it commands, and the driver override behaviour.

All three standards need this description. ISO 26262-3 calls it the item definition. ISO 21448 Clause 5 needs a specification of the intended functionality, its known limits and the ODD. ISO/SAE 21434 Clause 9 calls the analysed object the item and needs its boundary and operational environment. Writing three different descriptions guarantees three inconsistent analyses. Write one, version it, and make it the root of the traceability graph.

Step 2: HARA and safety goals

The HARA lists malfunctioning behaviours at vehicle level, combines them with operational situations, and rates hazardous events. For AEB the two classic malfunctions are unintended braking and missing braking.

Unintended full braking at motorway speed with following traffic is severe and hard for the following driver to control. Many published analyses rate it at a high ASIL, often C or D, though the exact result depends on exposure and controllability arguments. Missing braking is frequently rated lower, because AEB is an assistance function and the driver remains responsible for braking. An illustrative outcome:

SG1: Avoid unintended deceleration above a defined threshold. Illustrative ASIL D.
SG2: Avoid loss of the commanded emergency deceleration once triggered. Illustrative ASIL B.

The threshold in SG1 is a design value the team must justify, typically from controllability studies. I am deliberately not quoting a number because it is programme-specific.

Step 3: functional safety concept and ASIL decomposition

SG1 at ASIL D is expensive to implement in a single channel. A common architecture decomposes it. The main ADAS path, perception and planning on a high-performance SoC, carries B(D). An independent plausibility monitor on a separate safety MCU, checking the brake request against simple radar-only criteria, carries B(D). The brake ECU arbitrates and only executes a full brake request that both channels agree on.

Figure 3: An illustrative B(D) plus B(D) decomposition for the unintended-braking safety goal. The DFA must cover shared power, clocks, sensor inputs and the network path to the brake ECU.

This decomposition is legitimate only if the DFA shows sufficient independence. The two channels in Figure 3 share the radar sensor, which is a coupling factor. The design response might be to validate radar data integrity end to end, use a separate power rail for the monitor, and run the monitor’s software on a different toolchain. Every shared element becomes either a mitigation or an explicit argument.

Note what decomposition does not do. The hardware metrics for SG1 are still ASIL D targets for the item. The monitor MCU and the SoC each contribute failure rates to the FMEDA, and the combined result must still meet the SG1 PMHF budget.

Step 4: SOTIF analysis on the same function

Now assume the hardware never faults. The SOTIF analysis asks which insufficiencies of perception or decision logic, under which triggering conditions, cause the same harms.

For unintended braking, candidate triggering conditions include overhead structures and gantries that produce strong radar returns, metal plates on the road surface, steam or spray clouds that the camera classifies as obstacles, and painted or projected images. For missing braking, candidates include low-contrast pedestrians at night, stationary vehicles partially occluded in a curve, and unusual object shapes such as a vehicle transporting a load that overhangs its outline.

Clause 8 modifications might include requiring camera and radar confirmation before a full brake, limiting deceleration when only one sensor confirms, or restricting the ODD. Notice that the first modification is also the plausibility monitor from Step 3. That overlap is healthy. One mechanism can serve both a safety goal and a SOTIF risk, but the argument must state both purposes and must not double-count credit.

Validation targets come from the acceptance criteria. A team might argue that the rate of unintended AEB interventions must be no higher than a benchmark derived from human driving or from a predecessor system, then compute the volume of representative driving and simulation needed to show that with a stated confidence. The derivation is the work product. Any specific number is a programme decision, not a figure from the standard.

Step 5: TARA on the same function

The TARA asks how an attacker could cause unintended braking or suppress braking. Assets include the brake request message, the radar and camera data streams, the calibration parameters, and the domain controller’s firmware.

A threat scenario might be spoofing of the brake request on the in-vehicle network after compromise of a connected ECU. The damage scenario is the same harm as SG1, so its safety impact is severe. Attack feasibility depends on the attack path: remote entry through cellular, lateral movement through the gateway, then message injection. The risk value leads to a cybersecurity goal such as protecting the integrity and authenticity of brake requests between the domain controller and the brake ECU. Typical controls are secure onboard communication with message authentication, gateway filtering, secure boot and authenticated updates.

Two further threat scenarios deserve attention because they cross into SOTIF territory. Physical sensor attacks, such as radar spoofing or adversarial patches aimed at the camera network, do not compromise any E/E integrity property. They exploit perception limits. They belong in the TARA as threats and in the SOTIF analysis as triggering conditions, and the mitigation is usually a SOTIF-style functional modification rather than cryptography.

Step 6: the integration points

Three interfaces turn the separate analyses into one argument.

First, HARA to TARA. Every safety goal should be checked against the TARA: can an attacker violate it? If yes, the TARA must contain the corresponding threat scenario with a safety impact rating at least as severe as the HARA implies. Conversely, safety-relevant cybersecurity goals must be visible to the safety team so that, for example, a message authentication failure triggers the correct safe state.

Second, SOTIF to HARA. Functional modifications from SOTIF can create new E/E elements, such as the plausibility monitor, which then need ASIL allocation. Restricting the ODD changes exposure assumptions in the HARA.

Third, the safe-state conflict. Cybersecurity responses such as rejecting unauthenticated frames can cause loss of a function. The safety concept must define what the brake ECU does when authenticated requests stop arriving, and that degraded behaviour must itself be analysed under SOTIF for driver confusion and misuse.

Supporting Processes: Tool Qualification, Lineage and the AI Gap

The headline analyses get the attention, but auditors spend much of their time on supporting processes. This is where the three standards differ in ways that cost real money.

Tool qualification in ISO 26262-8

ISO 26262-8 Clause 11 governs confidence in software tools. Each tool use case is classified by tool impact (TI1 or TI2), meaning whether a malfunction of the tool could introduce or fail to detect an error in a safety-related element, and by tool error detection (TD1 to TD3), meaning how likely the error is to be caught downstream. Those combine into a tool confidence level, TCL1 to TCL3. TCL1 tools need no qualification. TCL2 and TCL3 tools need qualification methods chosen by ASIL: increased confidence from use, evaluation of the tool development process, validation of the tool, or development according to a safety standard.

The classification is per use case, not per tool. A compiler used for the ASIL D monitor in our AEB example, with no back-to-back testing against the model, may land at TCL3. The same compiler used for QM infotainment code needs nothing. Teams that qualify tools globally waste effort, and teams that classify once and forget miss the fact that a change in their verification flow changes TD and therefore TCL.

ISO 21448 has no equivalent clause, yet SOTIF arguments depend heavily on simulation tools, scenario generators and sensor models. The credibility of a simulation campaign is argued through model validation and correlation with real data, guidance on which appears in the standard’s informative annexes. Teams frequently borrow the 26262-8 logic and apply it to their simulation stack, which is sensible but should be presented as a chosen method, not a requirement.

ISO/SAE 21434 does not define tool qualification either, but it does require attention to the cybersecurity of the development environment and to supplier management in Clause 7. Fuzzers, static analysers and TARA tools are typically managed under general quality procedures.

Relation to IEC 61508

ISO 26262 is a sector adaptation of IEC 61508, and the family resemblance is strong: lifecycle, management of functional safety, hazard analysis, architectural metrics, and tables of methods graded by integrity. The differences are instructive. IEC 61508 uses SIL 1 to 4 with target failure measures expressed as PFD for low-demand mode or PFH for high-demand and continuous mode. ISO 26262 uses ASIL A to D with targets derived from S, E and C, and treats the car as a continuous-demand system for PMHF purposes. ASIL and SIL are not directly convertible, although informal correspondences circulate in industry.

For readers coming from machinery, the comparison with ISO 13849 performance levels, MTTFd, DC and PL calculation is useful. ISO 13849 uses Categories and diagnostic coverage in a way that resembles the 26262 SPFM and LFM logic, but with a much simpler calculation path. None of these industrial standards has a SOTIF counterpart, because their machines do not interpret an open world through perception.

Machine learning and ISO/PAS 8800

Perception networks break assumptions in all three standards. ISO 26262-6 assumes software requirements can be specified and verified against code. A neural network’s behaviour is learned from data, so the requirement-to-code trace that 26262 relies on largely disappears. SOTIF absorbs much of the risk, because a misclassification is a functional insufficiency, but ISO 21448 gives only general guidance on data and model validation.

ISO/PAS 8800:2024 targets this gap. It addresses safety-related systems that include AI elements, focusing mainly on machine learning, and covers risks from output insufficiencies, systematic errors and random hardware faults in AI elements. It explicitly frames itself as supporting a safety assurance argument alongside the existing standards rather than replacing them. As a Publicly Available Specification it carries less consensus weight than an International Standard, and the ISO catalogue already lists it as to be revised.

What is changing: ISO 26262 edition 3

Work on a third edition of ISO 26262 has been under way since around 2023. Practitioner reporting from mid-2026 described committee drafts in circulation, with a draft international standard expected in late 2027 and publication around 2028. Expected themes include alignment with machine learning guidance, fail-operational architectures and predictive maintenance. This timeline and scope are unverified until ISO publishes the DIS, and dates for ISO standards routinely slip. Plan against ISO 26262:2018, which remains the current edition, and track the drafts through your national standards body.

Trade-offs, Gotchas, and What Goes Wrong

The standards are individually coherent. The failures happen when organisations run them as three departments with three tools, three item descriptions and three review boards. These are the patterns I see most often.

Silo HARA and TARA. The safety team rates unintended braking as ASIL D, and the security team rates the brake-request spoofing threat with a moderate safety impact because their impact table uses different severity language. The two documents never meet. An assessor finds the inconsistency late, and the fix ripples through cybersecurity goals and controls. The cure is a shared severity vocabulary and a mandatory cross-check of every safety goal against the threat catalogue.

Decomposition without independence. Teams claim B(D) plus B(D) and then route both channels through one switch, one power converter or one middleware stack. The DFA is written after the architecture is frozen, so it argues the design rather than testing it. Run the DFA during the technical safety concept, not after.

Treating SOTIF as a test phase. SOTIF starts at specification. If the first SOTIF activity is a validation drive campaign, the triggering-condition analysis has been skipped, and the campaign has no principled way to argue coverage of the unknown unsafe area. Mileage without a scenario model is anecdote.

Fabricated precision. A validation target expressed to three significant figures, derived from a single human-driver crash statistic and an assumed Poisson model, looks rigorous and is often indefensible. State assumptions, show sensitivity, and keep the derivation reviewable.

Security controls that break safety. Message authentication adds latency and can drop frames under counter resynchronisation faults. A brake ECU that silently discards a late, authenticated emergency request has traded a security problem for a safety one. Timing budgets for authenticated paths must be inside the fault-tolerant time interval of the safety goal.

Over-the-air updates as an afterthought. UN Regulation 156 requires a software update management system, and every update reopens the safety case for the changed elements. Without impact analysis that spans all three standards, an update that retrains the perception network can quietly invalidate SOTIF evidence while passing every 26262 regression test.

Figure 4: After start of production, field data, vulnerability reports and fleet triggering-condition events must route into one impact analysis before any change or over-the-air update is released.

Figure 4 shows the loop that most organisations lack. Fleet telemetry reveals new triggering conditions, threat intelligence reveals new vulnerabilities, and field returns reveal hardware failure rates. Each input should land in a single change impact analysis that asks all three questions before an update goes out under R156. Data architecture helps: a standard signal model such as the one described in our post on Vehicle Signal Specification and Eclipse Kuksa as a software-defined vehicle data layer makes it easier to capture comparable field evidence across vehicle lines.

There is also a cost trade-off. Doing all three properly can add substantial engineering effort to an ADAS programme, and the temptation is to share work products until they mean nothing. Shared is good where the content is genuinely shared, such as the item definition and the architecture. Separate is necessary where the reasoning differs, such as exposure for HARA, feasibility for TARA and acceptance criteria for SOTIF.

Practical Recommendations

Start from causes, not components. For every vehicle-level harm in your feature, list the fault routes, the insufficiency routes and the attack routes, then assign each to its standard. This one table prevents most silo failures and becomes the backbone of the safety case.

Govern with one model. Use a single item definition, one architecture model and one requirements database with typed links: safety goal, SOTIF acceptance criterion, cybersecurity goal. Model-based tools help, but a disciplined requirements tool with enforced link types is enough.

Agree vocabulary early. Align the HARA severity classes with the safety impact category in the TARA, and write down how they correspond. Decide your CAL determination method and document it as an organisational convention.

Fund the operation phase. Field monitoring, triggering-condition discovery, vulnerability management and update impact analysis are recurring costs for the life of the vehicle. Budget them at programme start, not after SOP.

A checklist for the next ADAS feature:

One versioned item definition with ODD, interfaces and operating modes.
HARA, SOTIF hazard analysis and TARA cross-referenced by harm.
DFA performed before any ASIL decomposition is accepted.
Hardware metric targets traced to the original safety goal ASIL.
Triggering-condition catalogue with a coverage argument and a derivation for each validation target.
Authenticated communication timing verified inside the fault-tolerant time interval.
Tool classification per use case, refreshed when the verification flow changes.
One change impact procedure covering all three standards before every OTA release.

Frequently Asked Questions

What is the main difference between ISO 26262 and SOTIF?

ISO 26262 addresses hazards caused by malfunctions of electrical and electronic systems, meaning random hardware faults and systematic design or software faults. ISO 21448, known as SOTIF, addresses hazards that occur when nothing has failed but the intended function is insufficient for the situation, for example a camera that misclassifies an object in low sun. The two are complementary. An ADAS feature typically needs both, because a fault-free implementation of an inadequate specification is still unsafe, and an adequate specification implemented on faulty hardware is unsafe too.

Does SOTIF use ASIL levels?

No. ISO 21448 deliberately does not define an integrity level. Instead, the developer defines acceptance criteria for residual risk and derives validation targets, such as scenario coverage goals or volumes of representative driving, that demonstrate the criteria are met. The standard explains how to justify and argue those targets but does not prescribe numbers. ASILs from the ISO 26262 HARA may still apply to E/E elements that SOTIF modifications introduce, such as an added plausibility monitor, but the SOTIF argument itself is not graded by ASIL.

Is ISO/SAE 21434 mandatory?

The standard itself is voluntary. UN Regulation 155 is what creates the obligation in markets that apply it, such as the EU, by requiring a certified cybersecurity management system and vehicle type approval evidence. ISO/SAE 21434 is widely used to demonstrate the processes behind that management system, so in practice most manufacturers and suppliers serving those markets adopt it. In the EU, R155 applied to new vehicle types from July 2022 and to existing types from July 2024, according to the UK Vehicle Certification Agency’s published schedule.

How does ASIL decomposition work?

ASIL decomposition, defined in ISO 26262-9, splits a safety requirement across redundant elements that are sufficiently independent, so each element can carry a lower ASIL. An ASIL D requirement can become B(D) plus B(D), C(D) plus A(D), or D(D) plus QM(D). The original ASIL in brackets still governs certain activities, and hardware metric targets remain those of the original safety goal. Decomposition is valid only when a dependent failure analysis shows that common-cause and cascading failures cannot defeat both elements together.

Is CAL the cybersecurity equivalent of ASIL?

Not really. The cybersecurity assurance level in ISO/SAE 21434 is defined in an informative annex, runs from CAL 1 to CAL 4, and scales the rigour of cybersecurity assurance activities. It is optional, and organisations choose their own determination method, often from impact and attack vector. ASIL is normative and derived from severity, exposure and controllability. The two answer different questions, so a mapping between them is an internal convention rather than a requirement of either standard.

Where does AI and machine learning fit?

Machine-learned perception mostly raises SOTIF issues, because a misclassification is a functional insufficiency rather than a fault. ISO 26262 still applies to the hardware and conventional software around the model, and ISO/SAE 21434 applies to threats such as model tampering or adversarial inputs. ISO/PAS 8800:2024 adds guidance specifically for AI elements in road vehicles, covering data, model development and safety assurance arguments. It complements rather than replaces the three main standards, and its PAS status means it is expected to be revised.

ISO 26262 vs SOTIF (ISO 21448) vs ISO/SAE 21434: Functional Safety, Intended Functionality and Cybersecurity Compared (2026)