What Is ISO 26262? A Guide to Functional Safety in Automotive

Software-related vehicle recalls accounted for roughly 46% of recalled vehicles in the United States in 2024, up from about 14% in 2023. A growing share of those recalls trace back to electrical or electronic system malfunctions that can put drivers, passengers, or anyone near the vehicle at risk. ISO 26262 exists to keep those failures out of production.

The standard gives engineers, quality leads, and compliance officers a shared development playbook for safety-critical E/E systems. This guide walks through how ISO 26262 adapts IEC 61508 for road vehicles, how Automotive Safety Integrity Levels (ASILs) decide how much rigor each system needs, and where most programs run into trouble coordinating safety evidence across OEM and supplier boundaries.

What Is the ISO 26262 Functional Safety Standard?

ISO 26262, formally titled Road Vehicles, Functional Safety, applies to safety-related electrical and electronic (E/E) systems installed in series production road vehicles. The standard spans 12 parts published by ISO and uses an automotive-specific, risk-based approach built around ASILs, aimed at keeping residual risk reasonable from concept through production, operation, and decommissioning.

Compliance is not generally mandated by law for vehicle homologation, but OEMs almost always treat it as a contractual gate to market. They request proof from Tier 1 suppliers, who request the same evidence from their own supply base, so the standard ends up flowing through the entire chain.

How ISO 26262 Adapts IEC 61508 for Road Vehicles

ISO 26262 takes the general functional-safety logic of IEC 61508 and tunes it for automotive E/E. The biggest change is that Safety Integrity Levels (SIL 1 through 4) are replaced with Automotive Safety Integrity Levels (ASIL A through D) plus a quality management (QM) tier, and risk is assessed through severity, exposure, and controllability, three parameters specific to road-vehicle scenarios.

The standard also decouples hazard risk from probabilistic failure rate and swaps the “safety function” concept for a “safety goal.” On the lifecycle side, it moves teams from a flexible managed safety lifecycle onto a prescriptive V-model and introduces automotive-specific hardware metrics: single-point fault metric (SPFM), latent fault metric (LFM), and probabilistic metric for random hardware failures (PMHF).

What Changed in the 2018 Second Edition

The 2018 second edition widened the standard in four practical ways:

1. Vehicle scope expansion: Coverage now includes additional vehicle categories beyond passenger cars, and the original 3,500 kg mass limit has been removed.
2. Motorcycle adaptation (Part 12): A new normative part introduces Motorcycle Safety Integrity Levels (MSILs).
3. Semiconductor guidance (Part 11): A new informative part provides semiconductor-specific development guidance.
4. Hardware metric targets: Updated targets make higher-ASIL hardware compliance more achievable.

Commercial trucks and motorcycles now sit inside the same standard as passenger cars, and semiconductor suppliers have explicit guidance for the first time.

Why ISO 26262 Compliance Matters for Automotive Programs

ISO 26262 matters because functional safety failures turn into financial and regulatory problems fast. In November 2024, the National Highway Traffic Safety Administration (NHTSA) issued a $165 million civil penalty against Ford for failures in a rearview camera recall, the second-largest civil penalty in the agency’s history, behind only the Takata airbag consent order.

Three forces in particular are raising the stakes on functional safety today:

• Rising software complexity in connected and electric vehicles: Modern vehicles run on dozens of electronic control units (ECUs) and tens of millions of lines of code, with driver assistance and automation layering more safety-relevant code paths on top of that footprint.
• Federal compliance clocks on perception and braking: NHTSA’s FMVSS No. 127 requires Automatic Emergency Braking (AEB) with pedestrian detection on all new light vehicles by September 2029, which puts ISO 26262 work products squarely in the homologation conversation.
• Liability, recalls, and supplier qualification pressure: Software recalls have grown in recent years, and gaps now show up as warranty cost, regulatory penalty, and lost supplier qualification. ASPICE (Automotive SPICE) process assessments and ISO 26262 compliance are common contract prerequisites for Tier 1 and Tier 2 suppliers.

Together, these pressures mean the work products ISO 26262 calls for are increasingly the same evidence buyers and regulators ask to see.

The 12 Parts of the ISO 26262 Standard

ISO 26262 is organized into 12 parts covering vocabulary, management, development, production, and adaptation, with ten normative parts and two informative ones. Most teams only touch a handful of them day to day, but knowing which part owns which work product saves real time during an audit.

Vocabulary and Management of Functional Safety

Parts 1 and 2 define the shared language and the management approach for everything that follows. Part 2 covers safety plan creation, the safety case, functional safety assessment, and the Development Interface Agreement (DIA) between OEMs and suppliers.

System, Hardware, and Software Development

Parts 3 through 6 carry most of the development work that ends up in the safety case. Part 3 covers item definition, Hazard Analysis and Risk Assessment (HARA), and the functional safety concept, and Part 4 takes that work into system-level development and the technical safety concept. From there, Part 5 specifies hardware design with quantitative metric targets (SPFM, LFM, PMHF), while Part 6 handles software architecture, unit design, implementation, and verification.

Production, Supporting Processes, and Motorcycle Adaptations

Parts 7 through 12 extend the standard beyond core development into production, support, analysis, and adaptations. Part 7 addresses production, operation, service, and decommissioning, and Part 8 covers configuration management, change management, and tool qualification.

Part 9 defines ASIL decomposition and safety analyses, Parts 10 and 11 are informative guidelines (general and semiconductor-specific), and Part 12 provides normative motorcycle adaptations with MSILs.

How ASIL Levels Determine Safety Rigor Under ISO 26262

The assigned ASIL decides how much documentation and testing rigor a system needs. The five classifications range from QM (no safety measures required) through ASIL A (lowest safety rigor) to ASIL D (highest, applied to systems like airbags, anti-lock brakes, and electric power steering).

Run Hazard Analysis and Risk Assessment to Set the ASIL

HARA is where ASIL determination begins, and ISO 26262 requires it in the concept phase for any compliant development. The process moves from item definition through operational situation and hazard identification, landing on an ASIL for each hazardous event. A weak item definition almost always shows up later as a HARA that missed vehicle-level hazards, so the analysis has to evaluate raw item behavior before any mitigating design measures are factored in.

Score Severity, Exposure, and Controllability to Land the ASIL

Three independent parameters decide the ASIL for each hazardous event:

1. Severity (S0 through S3): Measures harm to persons, from no injuries (S0, always QM) to life-threatening or fatal injuries (S3).
2. Exposure (E0 through E4): Likelihood that the vehicle operates in a scenario where the hazardous event could occur, from incredibly unlikely (E0, always QM) to high probability (E4).
3. Controllability (C0 through C3): Whether the driver or other road users can avoid harm, from controllable in general (C0, always QM) to difficult to control or uncontrollable (C3).

The combination S3 + E4 + C3 yields ASIL D, and if any parameter reaches its zero class (S0, E0, or C0), the result is QM regardless of the other values. A forward crash avoidance system rated S3 + E4 can still land at ASIL B if controllability is C1, because the driver can act reliably when warned.

Decompose ASILs Across Redundant Architectures

ASIL decomposition lets teams assign lower ASILs to individual architectural elements when those elements provide redundant safety coverage through sufficiently independent paths. An ASIL D safety goal for electric power steering, for example, can be satisfied by two ASIL B(D) channels: a primary torque control path and an independent monitoring path, each carrying a lower development burden while the combined system still meets the original goal.

The catch is that teams have to demonstrate diverse redundancy through formal Dependent Failure Analysis (DFA). Decomposition itself only applies to the safety requirements derived from a safety goal; the safety goal keeps its original ASIL.

The ISO 26262 Functional Safety Lifecycle Explained

ISO 26262 runs on a V-model lifecycle, where every specification phase on the left has a matching verification phase on the right. Every artifact written at the top of the V has to be answered by an artifact at the bottom, and the safety case lives or dies by those pairings.

Item Definition and Safety Goals at the Concept Phase

The concept phase turns an item definition into safety goals. The item definition in Part 3, Clause 5 describes the system’s functions, interfaces, environmental conditions, and known hazards. HARA produces the safety goals, and those goals have to be expressed as functional objectives that describe what must not happen at the vehicle level, leaving the technical implementation for later phases.

Functional and Technical Safety Requirements

Functional Safety Requirements (FSRs) lay out the high-level strategies for achieving safety through system behavior. Technical Safety Requirements (TSRs) push those strategies down to concrete rules allocated to specific system elements like ECUs, sensors, actuators, and software modules. The FSR-to-TSR boundary is where many programs lose traceability, since a clean FSR often turns into half a dozen TSRs spread across hardware and software owners.

Verification, Validation, and the Safety Case

The safety case only holds up when verification and validation are both complete and traceable. Verification answers whether the system was built correctly. Validation is the harder question of whether the right system got built in the first place, and every link in the bidirectional trace chain has to stay intact for the safety case to argue that the item actually meets its safety goals.

Common Challenges in Meeting the ISO 26262 Functional Safety Standard

The hardest ISO 26262 problems almost always show up at organizational boundaries, not inside any single engineering team. Running the standard across a multi-tier automotive supply chain is where most programs start to struggle, and three issues come up again and again:

• Bidirectional traceability across multi-tier supplier networks: End-to-end traceability is the audit finding most teams hear about, because every layer in the chain runs its own tools and formats and the chain fractures right at the org boundary. The OEM owns the overall safety case but delegates downstream verification to Tier 1 suppliers, so no single entity can confirm the full trace chain is intact across every tier.
• Change impact analysis on the safety case: When a safety requirement shifts mid-program, scoping the full impact across a complex, multi-artifact safety case is the real work, and change impact analysis becomes essential. Document-centric processes compound the problem because changes in one document do not automatically update linked documents.
• Coordinating ISO 26262 with SOTIF, ASPICE, and ISO 21434: A typical advanced driver assistance systems (ADAS) program addresses ISO 26262 for E/E malfunctions, ISO 21448 (SOTIF) for functional insufficiencies in nominal operation, and ISO/SAE 21434 for cybersecurity threats. Each of those uses a different analytical framework, so the same team often ends up coordinating multiple safety and security methods inside one program.

Tooling that can hold those three threads in one connected environment is where most of the practical gain shows up.

How Jama Connect® Supports ISO 26262 Functional Safety

Traceability gaps and change-management breakdowns are some of the hardest ISO 26262 problems to control across supplier networks. Jama Connect®, a cloud-based requirements management and traceability system, ships with an automotive framework pre-mapped to ISO 26262 work products, so safety teams aren’t building that scaffolding from scratch.

Live Traceability™ keeps safety requirements, hardware artifacts, software items, and verification evidence connected with a bidirectional trace chain from hazard analysis through allocation, design, and test. When an upstream item changes, every downstream artifact is automatically flagged as suspect, so teams see the impact before a gap turns into a defect.

Jama Connect Interchange™, an add-on for ReqIF-based requirements exchange, moves work cleanly across OEM and supplier boundaries. That matters most on programs running ISO 26262 alongside ASPICE, where the safety case has to stay coherent across organizations that never share an environment.

Keep ISO 26262 Evidence Connected

ISO 26262 holds together when teams keep safety goals, requirements, verification evidence, and change decisions connected across the full development lifecycle. In multi-tier automotive programs, functional safety has to live inside the daily engineering workflow, because rebuilding the safety case at audit time almost always surfaces gaps the team can’t close in time.

Jama Connect is the requirements and traceability environment that keeps hazard analyses, safety requirements, hardware artifacts, and verification evidence linked in one place, with bidirectional traceability that updates as work moves through the V-model. Every downstream artifact gets flagged automatically when an upstream item shifts, so the safety case stays current as the program runs. Teams preparing for an ISO 26262 audit can see how that works on their own programs with a free 30-day trial.

Frequently Asked Questions About the ISO 26262 Functional Safety Standard

How is ISO 26262 different from IEC 61508?

ISO 26262 is the road-vehicle adaptation of IEC 61508. It classifies risk through severity, exposure, and controllability on a prescriptive V-model lifecycle. Automotive E/E teams work directly from ISO 26262, while suppliers building components across industries still treat IEC 61508 as the parent standard, and Jama Connect ships with frameworks for both so one set of safety artifacts can carry parallel audits.

Does ISO 26262 apply to advanced driver assistance systems (ADAS) and autonomous vehicle systems?

ISO 26262 applies directly to ADAS and covers hazards from malfunctioning E/E behavior, such as sensor faults in LiDAR, radar, or camera systems. Hazards arising from correctly functioning systems with performance limitations are addressed by ISO 21448 (SOTIF). Most teams therefore use ISO 26262 for malfunction-based hazards and SOTIF for intended-function limits in the same ADAS or autonomous program.

Who is required to comply with the ISO 26262 functional safety standard?

ISO 26262 is a voluntary international standard. Compliance usually flows through the full supply chain by contract, with OEMs requesting proof from Tier 1 suppliers, who request evidence from Tier 2 and lower-tier component and semiconductor vendors.

How long does it typically take to achieve ISO 26262 compliance?

ISO 26262 compliance runs across the full product development lifecycle, from item definition through production release. The timeline tracks system complexity, team maturity, and the scope of safety-related functionality. Tools like Jama Connect keep safety requirements and evidence linked across the V-model so audit prep stays off the critical path, and teams can try the workflow with a free 30-day trial. 

This article was authored by Mario Maldari and published on May 15, 2026.