ISO 26262 vs MIL-STD-882E: same discipline, two worlds

MIL-STD-882 is the older of the two by four decades. It grew out of the US ballistic-missile programmes of the early 1960s, became a military standard in 1969, and today's edition — MIL-STD-882E, issued in 2012 and updated by a change notice in 2023 — is the US DoD's standard practice for system safety, invoked through contracts: a citation binds its mandatory core, and the task descriptions bind only when individually called out in the contract. ISO 26262 is the automotive industry's own answer, first published in 2011 and expanded in 2018 into twelve parts covering all series-production road vehicles except mopeds: an adaptation of IEC 61508 to vehicles, invoked by no procurement authority — it binds as the state of the art a manufacturer is expected to meet, flowed down the supply chain through customer–supplier agreements rather than government solicitation.

The deeper difference is what each standard looks at. MIL-STD-882E defines safety directly in terms of harm: a mishap is unintentional death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment — and a hazard is any real or potential condition that could lead there, whether a component failure, an unsafe interaction or an energetic material. ISO 26262 defines functional safety as the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of E/E systems — and stops there: damage to property or the environment, and hazards not caused by electronics misbehaving, are outside its scope. One standard covers a system's whole potential for causing harm; the other covers what happens when the electronics deviate from design intent.

MIL-STD-882E assesses each hazard on two axes. Severity: Catastrophic, Critical, Marginal or Negligible — graded by consequence, from death or irreversible environmental damage down to monetary thresholds. Probability: Frequent (A) down to Improbable (E), plus Eliminated (F) for hazards designed out entirely. The two combine into a Risk Assessment Code — 1A is a frequent catastrophe — and the code places the hazard in a risk level: High, Serious, Medium or Low. It is an assessment of the mishap risk itself, made per hazard and revisited through the system's life.

ISO 26262 asks three questions instead, in the hazard analysis and risk assessment: how severe would the harm be (S0–S3), how probable is the operational situation in which it could occur (exposure, E0–E4), and could a driver or others plausibly control it (C0–C3)? The answers combine into an ASIL — A to D, or QM when the quality system alone suffices. ASIL D arises from exactly one combination: life-threatening harm, high-probability situation, uncontrollable. And crucially, the ASIL does not grade the residual risk of the fleet — it grades the rigour of the development required, attaching to a safety goal and inherited by every requirement derived from it.

This is where translation between the worlds most often goes wrong. Exposure is the probability of the operational situation, not of the failure — a different quantity from MIL-STD-882E's mishap probability — and controllability has no counterpart in the defence matrix at all. No official mapping between ASILs and the 882E risk levels exists, and a 2025 SAE paper on leveraging ISO 26262 for MIL-STD-882E compliance states it outright: there is no direct alignment between the risk levels of the two standards. Crosswalks can be useful for discussion; they are not equivalences.

On software, the two standards reach the same conclusion from opposite directions. MIL-STD-882E says it explicitly: determining the probability of failure of a single software function is difficult at best and cannot be based on historical data — so software risk cannot rest on severity and probability alone. Instead, severity is crossed with the software control category — the degree of control the software exercises over the system — to yield a Software Criticality Index, SwCI 1 to 5, and each index prescribes level-of-rigour tasks: analysis of requirements, architecture, design and code, plus safety-specific testing, in decreasing depth as criticality falls. The standard is explicit that this matrix is not a risk assessment — and equally explicit about the consequence of skipping it: unperformed rigour at SwCI 1 is documented as a High contribution to system risk and put to the programme for decision.

ISO 26262 part 6 does the same thing with different furniture. Software carries no probabilistic targets — quantitative values exist only for random hardware failures — and integrity is bought through ASIL-graded method tables, where each technique is graded per ASIL — highly recommended, recommended, or left without recommendation: enforcement of low complexity, language subsets and strong typing for everyone; the heavier analyses and coverage criteria reserved for C and D. Different vocabulary, same engineering truth: you cannot test probability into software, so criticality has to buy process rigour.

MIL-STD-882E's evidence spine is the closed-loop Hazard Tracking System: a living record with defined minimum content — hazards, associated mishaps, risk assessments, mitigation measures, status, verification of risk reduction, and every risk acceptance decision. In Swedish defence practice the same instrument appears as H SystSäk 2022's TASK 106: a risk management process with continual follow-up and a consolidated picture of all identified hazards, documented in a risk log that follows the system through its whole life.

ISO 26262 compiles a safety case instead: an argument that functional safety is achieved, assembled progressively from the work products of the lifecycle and checked by confirmation measures — reviews, a functional safety audit and a functional safety assessment, with graded independence requirements for who may perform them. A record versus an argument is a real philosophical difference — but a safety case without a reliable record collapses, and a hazard log that cannot say which software and configuration is actually fielded proves nothing. Both worlds converge on the same dependency: knowing exactly what runs where, under configuration control, through the system's entire life — the through-life discipline we described in the defence diagnostics article.

In the defence world, residual risk is accepted by a named authority — before exposing people, equipment or the environment to a known hazard, the risk must be formally accepted at the level the DoD 5000-series instructions assign: the higher the risk, the more senior the accepting authority, with the user community's representative formally concurring before serious and high risks are accepted. Risk acceptance is a governance act with signatures on it, and the hazard tracking record is what the signature refers to.

ISO 26262 has no state acceptance authority anywhere in it. The loop closes inside the manufacturer: the functional safety assessment judges whether the item achieves functional safety, and release for production is the organisation's own decision. The regulatory teeth in automotive sit elsewhere — in type approval under the UNECE regulations — and ISO 26262 binds as the state of the art a manufacturer is measured against. For a supplier crossing between the worlds, this is the practical difference: in defence you deliver evidence into someone else's acceptance decision; in automotive you build and own the argument yourself. Both demand the same underlying record.

Sweden adds its own layer. H SystSäk 2022 — the Armed Forces' system safety handbook — builds its activity set largely on MIL-STD-882E: its sections mirror the standard's task series — planning, analysis, evaluation, verification — with a Swedish fifth section for the formal safety decisions, its adapted risk matrices lie close to the standard's tables, and the quantitative probability intervals A–F match it exactly. The handbook also states what happens when a supplier arrives with a different pedigree: if system safety work is carried out to another established standard, it may need to be complemented with, for example, the unique Swedish activities and a cross-reference list between the standards. That cross-reference list is, in miniature, exactly the translation this article describes.

For an organisation shaped by automotive functional safety, most of the muscle carries over: severity-driven rigour, verification and validation discipline, configuration control, and traceability from requirement to fielded system. What has to be learned is the rest: the wider mishap scope that counts equipment and environment as consequences, the governance of formal risk acceptance, and the Swedish activity set from SSPP to TASK 106. That is the journey we are on — we continuously learn from the frameworks that govern this domain, and how we work with standards sets out where we stand. The question an evaluator should ask any crossover supplier is not which standard they memorised, but whether their record — of hazards, versions, configurations and verifications — would survive either world's audit.