Safeguard
Security Guides•

ISO 26262 ASIL explained: how vehicle hazards are rated

ISO 26262 rates vehicle hazards on severity, exposure and controllability to set an ASIL from A to D. Here is how it works and why it matters for code.

Safeguard Security Team
3 min read

ISO 26262 is the functional safety standard for electrical and electronic systems in road vehicles. It rates each hazardous event on severity, exposure and controllability to assign an Automotive Safety Integrity Level, from ASIL A (least strict) to ASIL D (most strict), with QM below A.

Scope and history

The standard was published in 2011 and revised in 2018. It adapts IEC 61508 for automotive use. The 2011 edition covered passenger cars, and the 2018 edition extended to all road vehicles except mopeds. It defines functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical and electronic systems.

The three factors

At the start of the safety lifecycle a hazard analysis and risk assessment rates each hazardous event on:

  • Severity (S0 to S3): from no injuries to fatal injuries.
  • Exposure (E0 to E4): how often the operating conditions that could lead to injury occur.
  • Controllability (C0 to C3): how likely a driver is to prevent the injury.

ASIL D corresponds to the top rating in all three: S3, E4, C3. Each step down in any factor lowers the ASIL by one level. A fatal hazard that is very rare might still land at ASIL A. The ratings are informative, not prescriptive, so teams interpret them with guidance such as SAE J2980.

From rating to requirement

A safety goal inherits the ASIL of its hazard, and requirements derived from it inherit it in turn. Splitting a function across independent redundant components can sometimes lower the inherited level, which is called decomposition, though it needs care.

The parts of the standard

The 2018 edition has twelve parts, ten normative and two guidelines. They run from vocabulary and management of functional safety through concept, system, hardware and software development (Part 6) to production, service and supporting processes. Part 12 adapts the standard for motorcycles.

What this means for software

Part 6 covers product development at the software level. Safety requirements are allocated to software components, which are developed to the highest ASIL assigned to them. Supporting processes include building confidence in software tools, qualifying previously developed software, and using field service history as evidence.

That last point matters for third party code. A library with years of use is not automatically qualified, so the build inventory and the evidence behind each component deserve attention. A software bill of materials is a starting point for that inventory. Safeguard can generate and analyse SBOMs and scan dependencies, which supports the inventory but not the qualification argument itself.

Compare with other schemes

See SIL, PL and ASIL compared for how this scale sits beside the others.

Quick check

Is ASIL D always required for brakes?

The sources reviewed do not say. The level comes from rating each hazard, so it depends on the system and the analysis.

What does QM mean?

Quality management. Standard quality processes apply and no special ISO 26262 safety requirements.

Sources

A secondary summary that notes some parts may be outdated; check the standard.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.