ComparisonAutomotive & Assembly

ISO 26262, SOTIF and ISO/PAS 8800: which standard covers your machine-learning component

No single standard covers a machine-learning component on its own. ISO 26262 handles hazards from faults in the electronics and software around it, ISO 21448 (SOTIF) handles hazards from the model performing poorly when nothing has failed, and ISO/PAS 8800 adds AI-specific lifecycle and data requirements. UL 4600 asks for a safety case when no human driver supervises. Most ADAS programs need the first three together.

Reviewed 10 October 2026 7 min read

On this page

Four automotive safety standards side by side
Why a learned model breaks classic functional-safety assumptions
How the three standards meet on one perception component
Vocabulary the safety case will lean on
Choosing which standard leads for your component
Architecture tactics and the evidence each one needs
Pedestrian detection feeding automatic emergency braking
Questions and answers
Sources

Four automotive safety standards side by side

Aspect	ISO 26262	ISO 21448 (SOTIF)	ISO/PAS 8800	UL 4600
Hazard it addresses	Malfunctioning behavior of E/E systems from systematic or random hardware faults	Functional insufficiencies of the intended function and reasonably foreseeable misuse	Output insufficiencies, systematic errors and random hardware errors of AI elements	Any risk an autonomous product poses without human supervision
Approach	Prescriptive lifecycle with ASILs from hazard analysis	Scenario-driven: shrink known and unknown unsafe areas	Lifecycle requirements for AI elements and their data	Goal-based safety case of claims, argument and evidence
Key work products	Item definition, HARA, safety goals, technical safety concept	Triggering condition analysis, validation strategy, acceptance criteria	AI safety requirements, dataset specification, AI element verification	Safety case, safety performance indicators, field feedback
Status	Established; the current edition is published in twelve parts	Full International Standard	Publicly Available Specification, an interim ISO deliverable	Voluntary standard; its third edition added autonomous trucking
Gap for ML	Assumes behavior can be fully specified in requirements	Little on dataset construction or training	Does not detail specific methods such as deep neural networks	Says what to argue, not how to build the model

Scope descriptions follow the publishers' summaries²³⁴⁵. ISO/PAS 8800 is highlighted because it is the newest and the one most teams have not yet mapped into their process.

Why a learned model breaks classic functional-safety assumptions

Functional safety grew up around systems whose correct behavior can be written down. A brake controller has a specification; a fault is a deviation from it; ISO 26262 assigns an Automotive Safety Integrity Level (ASIL) to each safety goal and scales the rigor of development and verification to match².

A pedestrian detector has no such specification. Its behavior is defined by the data it was trained on, so it can be fault-free in every ISO 26262 sense and still miss a person in low sun or a wheelchair user it rarely saw in training. That is a performance insufficiency, not a malfunction, which is why ISO 21448 exists: it targets hazards from the intended function itself being insufficient³.

ISO/PAS 8800 closes the remaining gap by treating the AI element as something with its own lifecycle: requirements on the data, the training process, verification of the trained model and monitoring once deployed⁴. Teams that try to make the model ASIL D on its own usually stall; programs that progress assign the integrity to the architecture around it. ColdAI's automotive delivery process likewise puts safety-critical design against ISO 26262 and HIL/SIL validation ahead of physical vehicle integration¹.

How the three standards meet on one perception component

Item definition and HARA
ISO 26262: define the function, its hazards and safety goals with ASILs.
Triggering conditions
ISO 21448: list conditions such as glare, rain or unusual road users that could make perception insufficient.
AI safety requirements
ISO/PAS 8800: turn goals and triggers into requirements on the model and its data.
Dataset specification
Coverage of the operational design domain, labeling rules and independence of test data.
Safety architecture
Decomposition, redundant channels and runtime monitors that bound what the model can cause.
Verification and validation
Test known scenarios, search for unknown unsafe ones, and confirm acceptance criteria.
Field monitoring
Collect evidence of new triggering conditions and feed them back into requirements.

Conceptual flow showing where each standard contributes to one ML component's safety work. It is a simplification, not a complete lifecycle from any of the standards.

Vocabulary the safety case will lean on

Triggering condition: A specific circumstance of a scenario that starts a reaction of the system leading to hazardous behavior, such as a reflective truck panel read as open road.
Known and unknown unsafe scenarios: SOTIF's way of framing validation: reduce the unsafe scenarios you know about through design, and search systematically for the ones you do not.
ASIL decomposition: Splitting a safety requirement across sufficiently independent elements so each can be developed to a lower ASIL, provided independence is shown.
Operational design domain: The conditions under which a driving function is designed to work: road types, speeds, weather, lighting and geography.
Runtime monitor: An independent check that watches the model's inputs or outputs during operation and triggers a degraded mode when they look implausible.
Goal Structuring Notation: A graphical way to lay out a safety argument as claims, strategies, context and the evidence that supports each claim.

Choosing which standard leads for your component

If
The ML component influences braking, steering or acceleration and a driver supervises.
Then
Run ISO 26262 for the item, ISO 21448 for perception performance and ISO/PAS 8800 for the model and data, with one integrated safety argument.
Assessors will look for all three hazard types; separate documents with gaps between them are the usual finding.
If
The function operates without a human driver in some domain.
Then
Add a UL 4600-style safety case on top of the ISO work, with safety performance indicators monitored in the field.
Without a driver as fallback, the argument has to show the system itself handles every reasonably foreseeable situation.
If
The model only informs a human, for example a driver monitoring alert or a maintenance prediction.
Then
Classify it through HARA first; it may be QM (no ASIL) and need only proportionate SOTIF-style validation.
Applying full ASIL rigor to an advisory function wastes effort that the safety-relevant components need.
If
The model is used in a tool, such as auto-labeling training data.
Then
Treat it under ISO 26262 tool confidence rules and check its errors cannot propagate unseen into the dataset.
ISO/PAS 8800 does not give specific guidance for AI-based software tools, so the existing tool qualification route applies.

Architecture tactics and the evidence each one needs

Each tactic below lowers the integrity demanded of the model itself, but only if its own claim is backed by evidence.

Diverse redundant channels, such as camera plus radar

Early signalBoth channels were trained or tuned on the same data, or share a preprocessing step.

MitigationDemonstrate independence of sensors, data, software and failure modes before claiming decomposition.

Plausibility checks on model outputs

Early signalThe check is tuned so loosely it never fires in testing.

MitigationInject implausible outputs in HIL tests and show the check catches them within the fault-tolerant time.

Out-of-distribution or input-quality monitors

Early signalThe monitor was validated only on the same distribution as the model.

MitigationValidate it on deliberately shifted data such as new regions, weather and sensor degradation.

A safe fallback such as a minimal-risk maneuver

Early signalThe fallback depends on the same perception output it is meant to protect against.

MitigationBase the fallback on an independent, simpler sensing path with its own ASIL argument.

Pedestrian detection feeding automatic emergency braking

Hypothetical example

A hypothetical AEB safety concept

For example, a Tier 1 might develop camera-based pedestrian detection for an AEB function. HARA rates unintended full braking at speed and failure to brake for a pedestrian as separate safety goals with different ASILs, because the first is mostly about false positives and the second about misses.

The SOTIF analysis lists triggering conditions such as night, low sun, partial occlusion and children near parked cars. ISO/PAS 8800 work turns those into dataset coverage requirements and a held-out test set the training team never touches. The architecture fuses the camera with radar, and a plausibility monitor limits braking authority when the channels disagree.

The safety argument then claims acceptable residual risk across the operational design domain, with each claim pointing to test campaigns, HIL results and a plan for field monitoring.

Questions and answers

Do machine-learning training tools need ISO 26262 tool qualification?

Tools whose output could introduce or fail to detect errors in safety-related work products need a tool confidence assessment under ISO 26262, and that includes labeling, data pipeline and training tools. ISO/PAS 8800 does not add specific rules for software tools that use AI, so teams typically apply the existing classification and add checks such as sampling auto-labels for human review.

Can a model keep learning from field data after the vehicle is sold?

Not in the sense of updating itself in the vehicle. The current standards and type-approval rules assume a released, verified software version. Field data can feed a new training cycle, but the retrained model is a new release that goes through verification, safety case update and the software update process before reaching vehicles.

Does ISO/PAS 8800 replace ISO 26262 or ISO 21448?

No. It builds on them and covers what they leave out for AI elements: data, training, AI-specific verification and monitoring. A program still needs ISO 26262 for faults in the hardware and software around the model and ISO 21448 for performance insufficiencies at the function level.

Are these standards required for vehicle homologation?

The standards themselves are voluntary, but type-approval rules for driver assistance and automated driving increasingly ask manufacturers to demonstrate safety processes and validation, and these standards are the accepted way to show it. Customers also write them into supplier contracts, which makes them effectively mandatory for many Tier 1 programs.

Sources

Automotive & Assembly: delivery process and safety-critical design — ColdAI
ISO 26262-1:2018 Road vehicles — Functional safety — Part 1: Vocabulary — International Organization for Standardization · checked 10 October 2026
ISO 21448:2022 Road vehicles — Safety of the intended functionality — International Organization for Standardization · checked 10 October 2026
ISO/PAS 8800:2024 Road vehicles — Safety and artificial intelligence — International Organization for Standardization · checked 10 October 2026
UL 4600 Edition 3 updates incorporate autonomous trucking — UL Solutions · checked 10 October 2026

More in Automotive & Assembly

Back to Automotive & Assembly

Next step

Share your ML component's safety concept for a second opinion

Send the function description, current HARA and how the model's integrity is argued today. We will reply with where the three standards leave gaps in your argument and what evidence would close them.

Discuss an ML safety case