What is ISO 26262 for?

ISO 26262 is the international horizontal standard for functional safety (FuSa) applied to the electrical and electronic systems of road vehicles. It defines a safety lifecycle, roles, work products and verification techniques aimed at controlling the risk of malfunctioning behaviour, that is, random hardware failures and systematic faults of both hardware and software that could lead to hazardous situations. The 2nd edition published in 2018 replaces the 1st edition of 2011 and explicitly extends the scope to trucks, buses and motorcycles.

What are the ASIL levels?

ASIL stands for Automotive Safety Integrity Level. Four levels are defined in increasing order of rigour, ASIL A, B, C and D, plus a QM (Quality Managed) category when no functional safety requirement in the meaning of the standard applies. The level is determined by combining three parameters at the end of the HARA, Severity (S1 to S3), Exposure (E1 to E4) and Controllability (C1 to C3). ASIL D, the most demanding, typically applies to scenarios combining potentially life-threatening injury, frequent exposure and low driver capability to recover the situation.

HARA stands for Hazard Analysis and Risk Assessment. Its method is described in Part 3 of ISO 26262 (Concept phase). The scope is the item, the system or function under analysis, as defined in the item definition. Use scenarios are decomposed, hazards identified, and each hazard / scenario pair is rated in terms of S, E and C. The combination yields an ASIL per scenario, from which Safety Goals derived, which the design must preserve.

What is the difference between ISO 26262 and IEC 61508?

IEC 61508 is the generic parent standard for functional safety, applicable to electrical, electronic and programmable systems in any industry that does not have a dedicated sector-specific standard. ISO 26262 is its automotive derivative, adapting the principles to series production, the OEM / supplier chain and the vehicle environment. The two standards use different integrity scales, SIL 1 to 4 for IEC 61508 and ASIL A to D for ISO 26262; the mapping is not mathematical and must be justified case by case.

What does SOTIF (ISO 21448) cover?

ISO 21448 (Safety Of The Intended Functionality, SOTIF) addresses residual risks that are not malfunctions within the meaning of ISO 26262, but limitations of the intended function, for example sensor limits in degraded conditions or use cases not anticipated at design time. SOTIF has become central with driver assistance and automated driving (ADAS, AD). The two standards are complementary, ISO 26262 targets malfunctions, ISO 21448 targets limits of the intended function.

How does ISO 26262 articulate with vehicle cybersecurity?

Vehicle cybersecurity is handled separately by ISO/SAE 21434 (Road vehicles, Cybersecurity engineering), typically applied in parallel with ISO 26262. ISO/SAE 21434 feeds compliance with UN-ECE R155 (cybersecurity management) and R156 (software update management), both mandatory at type approval since July 2022 (new vehicle types) and July 2024 (vehicles in production). A cyber threat may trigger a functional safety consequence, and explicit coordination between the two teams is expected.

SEooC, Safety Element out of Context, refers to a safety element developed without precise knowledge of the final item it will be integrated into. Part 10 (guideline) describes the mechanism. The supplier (often a semiconductor vendor or an RTOS publisher) makes assumptions about the target use case (Assumed Use Case) and the target ASIL, and delivers the element together with a Safety Manual. At integration time, the integrator verifies that the SEooC assumptions remain valid for the actual case.

What confirmation measures are required?

Three cumulative measures are defined in Part 2 (management). The Confirmation Review verifies that a specific work product satisfies its intent and the standard. The Functional Safety Audit checks the effective application of safety processes. The Functional Safety Assessment (FSA) evaluates whether the overall demonstration is sufficient, typically conducted by a Functional Safety Assessor independent from the project. The required level of independence (I0, I1, I2, I3) increases with ASIL.

ISO 26262: automotive functional safety

Author Hugues Orgitello Last updated 27 May 2026 ~13 min read

Guide · ISO 26262

ISO 26262 is the international horizontal standard for functional safety (FuSa) applied to the electrical and electronic systems of road vehicles. First published in 2011 and revised in 2018 (2nd edition), it is today the universally adopted reference used by vehicle manufacturers (OEMs) and their suppliers (Tier 1, Tier 2) to structure the management of electronic malfunctions that could lead to hazardous situations. This page presents the standard's origin, its relationship with the generic parent IEC 61508 and with its sibling standards (SOTIF ISO 21448, cybersecurity ISO/SAE 21434), the twelve-part structure, the ASIL classification mechanism, the safety lifecycle, the Safety Element out of Context concept, and the required confirmation measures.

A sector-specific derivative of IEC 61508

ISO 26262 is not an isolated text. It is one of the main sector-specific derivatives of IEC 61508 (Functional safety of electrical/electronic/programmable electronic safety-related systems), the generic standard for functional safety published by the IEC. IEC 61508 provides the common conceptual framework (SIL, lifecycle, separation between random and systematic failures), and each sector derives its adapted standard from it: ISO 26262 for automotive, IEC 61511 for process industries, EN 50128 / EN 50657 for on-board railway software, DO-178C for civil aviation software (under FAA / EASA oversight), and IEC 62061 for machinery.

The shift from generic IEC 61508 to the automotive ISO 26262 reflects several adaptations specific to the sector:

a tailored risk scale (ASIL A to D) calibrated to vehicle scenarios, rather than to the frequencies and error probabilities typical of process industries,
the explicit introduction of HARA as a mandatory input to the safety concept, where IEC 61508 remains more abstract on the upstream risk analysis method,
a structural acknowledgement of the automotive supply chain, OEM, Tier 1, Tier 2, with formalised interface work products (Hardware-Software Interface, Development Interface Agreement, Safety Manual),
the treatment of permanent and transient random failures of semiconductors as a first-class topic, which led to a dedicated Part 11 on semiconductors in 2018,
a more integrated handling of embedded software, complementary to but not redundant with other software standards.

The 1st edition of 2011 covered passenger cars and light vehicles up to 3.5 tonnes. The 2nd edition of 2018 extends the scope to trucks, buses and coaches, and adds a Part 12 specific to motorcycles. The 2nd edition is the current single reference.

The twelve parts of ISO 26262

ISO 26262 is divided into twelve parts published together, each targeting a portion of the lifecycle or a type of analysis. Part numbers are explicit in the cross-references throughout the safety dossier.

Part	Title	Indicative content
Part 1	Vocabulary	Vocabulary, definitions, acronyms; the common terminology base (ASIL, item, element, fault, error, failure, HARA, FSC, TSC, SEooC, and so on)
Part 2	Management of functional safety	Safety management at organisational and project level; roles (Functional Safety Manager, Functional Safety Assessor), Safety Culture, planning, work products, confirmation measures
Part 3	Concept phase	Item definition, Hazard Analysis and Risk Assessment (HARA), Safety Goals, Functional Safety Concept (FSC)
Part 4	System level	System-level safety specification, Technical Safety Concept (TSC), technical safety requirements, system integration and testing, validation against the Safety Goals
Part 5	Hardware level	Hardware requirements, quantitative analysis of random failures (PMHF, SPFM, LFM), Hardware Safety Requirements, hardware integration and testing
Part 6	Software level	Software requirements, software architecture, design, verification, integration and testing; tables of techniques recommended by ASIL
Part 7	Production, operation, service and decommissioning	Series production under safety control, maintenance, decommissioning; link to IATF 16949 (quality)
Part 8	Supporting processes	Cross-cutting processes, requirements management, configuration, change, documentation, software tool qualification (Tool Confidence Level), qualification of software and hardware components, criteria for integrating pre-qualified components
Part 9	ASIL-oriented and safety-oriented analyses	ASIL decomposition, analysis of common-cause failures and dependent failures, criteria for the coexistence of elements of different criticality on the same ECU
Part 10	Guideline on ISO 26262	Guidelines and application examples, including the framework for Safety Element out of Context (SEooC)
Part 11	Guidelines on application of ISO 26262 to semiconductors	A guide specific to semiconductors, added in the 2nd edition to address the specifics of SoC, MCU, ASIC, whose failure modes and supply chain differ considerably from discrete hardware
Part 12	Adaptation of ISO 26262 for motorcycles	Adaptation for motorcycles (motorcycle ASIL, risk scenarios, relaxed or specific requirements), added in the 2nd edition

Parts 3 to 7 form the backbone of the safety V-cycle. Part 8 contains cross-cutting chapters frequently cited (tool qualification, qualification of pre-qualified components). Parts 9 to 12 are thematic annexes.

ASIL classification (S, E, C)

ASIL stands for Automotive Safety Integrity Level. Four increasing levels are defined (A, B, C, D), plus a QM (Quality Managed) category for scenarios that do not impose a functional safety requirement within the meaning of the standard and remain managed under quality (IATF 16949).

The ASIL level of a Safety Goal results from the combination, inside the HARA, of three independent parameters.

Parameter	Symbols	Interpretation
Severity	S0, S1, S2, S3	Severity of potential consequences, from no injury (S0) to life-threatening or fatal injuries (S3)
Exposure	E0, E1, E2, E3, E4	Probability that the operational scenario occurs, from incredible (E0) to very frequent (E4)
Controllability	C0, C1, C2, C3	Capacity of the driver (or any concerned third party) to control the hazardous situation and avoid harm, from very controllable (C0) to difficult to control (C3)

The combination is tabulated in Part 3 (ASIL determination table). Combinations yielding a very low risk result in QM; combinations cumulating severity, exposure and low controllability result in ASIL D.

Severity	Exposure	C1	C2	C3
S1	E1	QM	QM	QM
S1	E2	QM	QM	QM
S1	E3	QM	QM	A
S1	E4	QM	A	B
S2	E1	QM	QM	QM
S2	E2	QM	QM	A
S2	E3	QM	A	B
S2	E4	A	B	C
S3	E1	QM	QM	A
S3	E2	QM	A	B
S3	E3	A	B	C
S3	E4	B	C	D

This Part 3 table is, in practice, the most reproduced passage of ISO 26262 in the pedagogical literature. It deserves to be read with two caveats: (1) the S, E and C classes are standard-defined classes whose assignment relies on normative examples but remains subject to interpretation and must be documented; (2) the rating is done per scenario, not per global item, since a single item may carry Safety Goals of different ASILs depending on the hazards analysed.

ASIL decomposition

Part 9 introduces the ASIL decomposition mechanism. A high-level requirement can be derived into two lower-level requirements carried by sufficiently independent elements, through redundancy and separation of common cause. The admitted decompositions are denoted as ASIL X (Y), for example:

ASIL D can be decomposed into ASIL B (D) + ASIL B (D), or ASIL C (D) + ASIL A (D), or ASIL D (D) + ASIL QM (D),
ASIL C can be decomposed into ASIL B (C) + ASIL A (C), or ASIL C (C) + QM (C),
and so on down to ASIL A.

Decomposition is not a free relaxation of rigour. It is conditional on a formal demonstration of independence between the decomposing elements (absence of common-cause failures, physical and logical separation, independent qualification). In practice, decomposition makes the design of an ASIL D Safety Goal realistic by relying on two independent ASIL B channels, for example a command channel and a monitoring channel.

The safety lifecycle

ISO 26262 organises the product lifecycle in formally chained phases. The structure follows the V-cycle used in most functional safety standards. The typical sequence, simplified here, comprises the following steps.

Item Definition (Part 3). Functional description, boundaries, interfaces, operational environment, use assumptions.
HARA (Part 3). Identification of hazards, scenarios, S/E/C rating, derivation of Safety Goals and their ASIL.
Functional Safety Concept (FSC, Part 3). Safety strategy at functional level, derivation of Functional Safety Requirements (FSR), allocation to elements (ECUs, sensors, actuators).
Technical Safety Concept (TSC, Part 4). Technical specification of safety requirements (TSR), system architecture, hardware and software allocation, definition of the Hardware-Software Interface (HSI agreement).
Hardware development (Part 5). Design, quantitative analysis of random failures (PMHF computation, SPFM and LFM metrics), verification, hardware integration.
Software development (Part 6). Specification, architecture, detailed design, coding, verification and software integration; technique selection driven by ASIL.
System integration (Part 4). Progressive integration, verification of conformity to TSR and FSR, validation tests at system level.
Item-level validation (Part 4). Demonstration that Safety Goals are met in the target vehicle environment.
Production and operation (Part 7). Series ramp-up under safety control; coordination with the IATF 16949 quality system.
Maintenance, change, decommissioning (Part 7 and Part 8). Change management, software releases, controlled decommissioning.

Each phase produces work products explicitly named by the standard. The Safety Case consolidates the full set of work products and the chain of arguments demonstrating that the residual risk is acceptable. The Safety Case is not a final document tacked on at the end, it is built in parallel throughout the project.

Safety Element out of Context (SEooC)

The SEooC concept (Safety Element out of Context) is described in Part 10. It addresses an economic reality of the sector: a semiconductor supplier or an RTOS publisher does not develop a component for a specific vehicle project but for a market. They cannot, by construction, follow the HARA of an item whose details they do not know.

Part 10 organises the mechanism as follows:

the supplier formulates assumptions about the target use case (Assumed Use Case) and a target ASIL (for example a MCU SEooC at ASIL B or ASIL D),
they develop the element following the relevant requirements of Parts 4, 5 and 6 under those assumptions,
they deliver a Safety Manual describing the assumptions, the safety mechanisms implemented, integration constraints, diagnostics coverage, and hardware metrics obtained,
the integrator (typically the Tier 1 supplying an ECU to the OEM) verifies at integration time that the SEooC assumptions remain valid for the real item and derives their own safety requirements from the Safety Manual.

The SEooC mechanism is today a de facto standard for MCUs, SoCs and certified software libraries in the automotive market. Its correct use requires a careful reading of the Safety Manual, in particular of the assumptions and conditions of use, whose violation invalidates the safety argument.

ISO 26262 against its sibling standards

Several adjacent standards, frequently cited together, must be distinguished to avoid confusion.

Standard	Field	Relationship with ISO 26262
IEC 61508	Generic functional safety (SIL 1 to 4)	Generic parent standard; ISO 26262 is its automotive derivative. ASIL / SIL mapping is not mathematical and must be justified project by project.
ISO 21448	SOTIF, Safety Of The Intended Functionality	Sibling standard, addresses limitations of the intended function (sensor limits, use cases not anticipated at design time); particularly relevant to ADAS and automated driving. Complementary and not redundant.
ISO/SAE 21434	Vehicle cybersecurity	Sibling standard, addresses vehicle cybersecurity. Feeds compliance with UN-ECE R155 and R156. Requires explicit coordination with the FuSa team when a cyber threat can lead to a safety consequence.
IATF 16949	Quality, automotive	Automotive-specific quality management system (derived from ISO 9001). ISO 26262 and IATF 16949 are complementary: quality targets repeatable conformance, functional safety targets risk control. Part 7 of ISO 26262 makes the link with series production.

To these standards must be added the UN-ECE regulations (under the umbrella of the WP.29 forum at the UNECE), legally binding for type approval, in particular:

R155 on vehicle Cybersecurity Management System (CSMS),
R156 on Software Update Management System (SUMS),
the R157 family on Automated Lane Keeping Systems (ALKS).

On the EU side, Regulation (EU) 2019/2144 (General Safety Regulation, GSR) mandates a set of safety functions on new vehicles registered in the EU (intelligent speed assistance, autonomous emergency braking, blind spot monitoring, and so on), whose underlying design typically falls within ISO 26262. The GSR does not cite ISO 26262 as a harmonised standard in the sense of CE marking, because the vehicle approval framework rests on the type-approval Regulation (EU) 2018/858 and on UN-ECE regulations rather than on the CE marking mechanism.

The automotive supply chain

ISO 26262 formally recognises the industrial organisation of the sector, structured in three principal levels. This structure conditions the distribution of work products.

The OEM (vehicle manufacturer) holds the global responsibility for the vehicle and the integrated item. It performs the HARA and sets the Safety Goals and ASIL. It may subcontract the item, integrates deliveries and owns the final Safety Case.
The Tier 1 (first-rank supplier) receives the Safety Goals and Functional Safety Requirements from the OEM, and delivers a complete subsystem or ECU. It owns the Technical Safety Concept and derives requirements towards its own suppliers.
The Tier 2 (component supplier) typically delivers a semiconductor, an RTOS or a software library, generally as a SEooC. It delivers a Safety Manual and the associated metrics.

Several interface work products formalise exchanges between levels, including:

the Development Interface Agreement (DIA) which allocates responsibilities and activities between the parties,
the HSI Agreement (Hardware-Software Interface) which freezes the contract between the hardware team and the software team of a single element,
the Safety Manual of the SEooC, as described above.

On recent programmes, the OEM sometimes develops its own ECU (in-house), which temporarily erases the OEM / Tier 1 separation without invalidating the DIA logic, formalised then between internal teams.

Confirmation measures

Part 2 of ISO 26262 defines three cumulative confirmation measures, whose application is required from certain ASIL levels onwards and at graded levels of independence (I0, I1, I2, I3).

Confirmation Review. Review of a specific work product (HARA, FSC, TSC, and so on) by a qualified person independent from the author. The objective is to verify that the work product satisfies its intent and the requirements of the standard. The expected independence varies with ASIL: for ASIL D, the standard requires organisational independence (I3).
Functional Safety Audit. Audit of the effective application of the safety processes defined in the Safety Plan. The audit checks the "how it was done", not the "what was done". Conducted by an auditor independent from the project.
Functional Safety Assessment (FSA). Overall evaluation of whether the safety demonstration is sufficient, typically at the end of a phase or programme. The Functional Safety Assessor is independent from the project and forms a reasoned judgement on the complete Safety Case. For ASIL D, the expected independence is I3, that is, full organisational independence.

These three measures are distinct but articulated. A non-conformity found during a Confirmation Review is treated locally; a recurring non-conformity found during an audit may trigger process remediation; a negative FSA at the end of a programme prevents release to series production.

Links with other pages

ISO 26262 does not replace the general regulatory framework. Several connections are relevant:

for the CE marking framework of non-vehicle electronic products (radio, EMC, cyber), see the CE marking page;
for project timelines and the combination of certification phases, see the certification timeline;
for the full glossary of terms used here (ASIL, HARA, SEooC, Safety Goal, FSC, TSC, FSA), see the glossary.

Common pitfalls observed in the field

Without amounting to an implementation guide, several recurring mistakes appear in programme feedback:

Conflating ASIL and SIL. The IEC 61508 / ISO 26262 mapping is not mathematical. Importing a "SIL 2" component from an industrial project and treating it as ASIL B without a transfer analysis is a risky approximation.
Decorative HARA. The HARA is not a compliance deliverable, it is the input to the concept. A HARA carried out at the end of the project to retrofit ASIL levels onto an already frozen design is the most common upstream mistake.
Mis-integrated SEooC. Reusing an ASIL D MCU SEooC without re-reading the Safety Manual or verifying the validity of the use assumptions is a frequent cause of integration non-conformity. The Safety Manual is part of the integrator's safety dossier.
ASIL decomposition without independence demonstration. A decomposition is only valid if the independence of the elements is demonstrated (physical separation, logical separation, absence of common cause). A decomposition claimed without demonstration will not be accepted by a serious FSA.
FuSa / SOTIF confusion. A sensor limitation in degraded conditions (fog, glare) is not a malfunction within the meaning of ISO 26262. It falls under ISO 21448 (SOTIF). Trying to encode a SOTIF case as an ISO 26262 Safety Goal leads to results that do not hold.
FuSa / cybersecurity confusion. A cyber threat that can lead to a safety consequence must be treated both under ISO/SAE 21434 (threat scope, TARA, cyber risk treatment) and under ISO 26262 (safety consequence, Safety Goal). Coordination between the two teams is explicitly expected by both standards.
FuSa / quality (IATF 16949) confusion. Quality conformance does not absolve functional safety, and the reverse. The two systems coexist and reference each other (Part 7 of ISO 26262, link with IATF 16949).

Further pages

This page presents the general framework of ISO 26262. Several topics deserve dedicated pages:

HARA step by step, with documented examples of S/E/C rating,
the ASIL hardware metric (PMHF, SPFM, LFM) and its concrete computation,
ISO 21448 (SOTIF) and its articulation with ADAS and automated driving,
ISO/SAE 21434 and UN-ECE R155 / R156 regulations, under the angle of type approval,
software tool qualification (Tool Confidence Level) within the meaning of Part 8.

Sources & references

ISO 26262:2018, Road vehicles, Functional safety , ISO www.iso.org/standard/68383.html
ISO 21448:2022, Road vehicles, Safety of the intended functionality , ISO www.iso.org/standard/77490.html
ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering , ISO www.iso.org/standard/70918.html
UN-ECE WP.29, vehicle regulations including R155 and R156 , UNECE unece.org/transport/vehicle-regulations
Regulation (EU) 2019/2144 (General Safety Regulation, GSR) , EUR-Lex eur-lex.europa.eu/eli/reg/2019/2144/oj
IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems , IEC webstore.iec.ch/publication/22273