ISO 21448 exists because ISO 26262 was not enough. That is not a criticism — it is a technical reality that every organisation developing advanced driver assistance systems or automated driving functions needs to understand clearly before their next programme starts.
Traditional functional safety covers what happens when hardware or software fails. Safety of the Intended Functionality — SOTIF — covers a different challenge: making sure the system performs safely even when every component works exactly as designed. An automatic braking system that mistakes a road marking for an obstacle is not a failure. It is a SOTIF problem. And ISO 21448 is the standard that gives engineering teams a structured way to find and address those gaps before vehicles reach the road.
Understanding who needs this standard — and why — is the first step toward building a compliant and defensible development process.
The gap that ISO 26262 does not cover
ISO 26262 and ISO 21448 govern two distinct and equally important categories of safety risk. ISO 26262 addresses risks caused by malfunctions: hardware failures, software faults, and systematic errors. ISO 21448 addresses risks that arise even when every component is functioning correctly, because the system’s intended functionality is itself insufficient to handle all real-world scenarios safely.
SOTIF applies to functionality that requires proper situational awareness in order to be safe. It is concerned with guaranteeing safety in the absence of a fault. A camera sensor that works correctly but cannot detect a pedestrian in heavy rain. An adaptive cruise control system that correctly follows its programmed logic but fails to account for a vehicle cutting in at close range. In both cases, no component has failed. The hazard comes from the gap between what the system was designed to handle and what the real world actually presents.
ISO 21448 was originally intended to be Part 14 of ISO 26262, but the scope of the problem grew large enough to demand a standalone standard. Published in 2022, it now covers SAE automation Levels 0 through 2, with guidance applicable to higher automation levels.
Who needs ISO 21448
The standard is not relevant to every organisation in the automotive supply chain equally. Its scope is precise. These are the four categories of organisation for which it is not optional.
OEMs developing ADAS and automated driving features. Automotive OEMs and Tier-1 suppliers designing electrical and electronic systems and automated driving functions are the primary target of ISO 21448. Any organisation releasing features that rely on perception, sensor fusion, or complex planning algorithms — adaptive cruise control, lane keeping assistance, automatic emergency braking, or higher-level automation — falls within scope. OEMs are leveraging SOTIF guidelines to establish robust safety frameworks, conducting comprehensive risk assessments, defining clear operational design domains, and implementing stringent validation processes.
Tier-1 and Tier-2 suppliers developing perception or decision-making components. Collaboration between OEMs and suppliers is essential to ensure seamless integration of SOTIF principles throughout the vehicle development lifecycle. A supplier developing a radar module, a camera processing unit, or a sensor fusion algorithm is contributing directly to the perception chain that ISO 21448 governs. OEMs are increasingly requiring that their Tier-1 partners demonstrate SOTIF alignment as a condition of programme participation, which cascades down through the supply chain.
Software and AI system developers. ISO/PAS 8800, published in December 2024, complements ISO 21448 with safety guidance specifically for AI-based systems. As machine learning components become central to perception and decision-making in ADAS, the boundary between software development and safety engineering has collapsed. Organisations developing AI-based automotive functions cannot rely on ISO 26262 alone — the probabilistic nature of machine learning outputs falls precisely within the territory that ISO 21448 was designed to address.
Organisations responsible for post-market monitoring. ISO 21448 requires operational monitoring: processes for observing field behaviour, detecting new SOTIF issues, and managing updates or mitigations after release. This means the standard’s obligations do not end at the point of homologation. Organisations that manage software updates, over-the-air deployments, or field data collection programmes are within scope for the operational phase requirements of the standard.
What compliance actually requires
SOTIF focuses on hazards that arise from the intended behaviour of automotive systems, even when no hardware or software failure exists. Unlike traditional safety standards that concentrate on fault detection and mitigation, SOTIF examines how functional limitations, sensor inaccuracies, and environmental uncertainty can lead to unsafe outcomes.
In practice, this translates into four interconnected workstreams: hazard identification at the system level for scenarios where correct behaviour produces unsafe outcomes; definition and documentation of the Operational Design Domain; structured verification and validation programmes including simulation, closed-track testing, and real-world scenario libraries; and post-market monitoring processes capable of detecting new SOTIF issues once the system is deployed.
By implementing ISO 21448 alongside ISO 26262, automotive developers achieve enhanced safety coverage across a wider range of scenarios, improved validation of perception and decision-making functions, full lifecycle risk assessment from concept to production, and regulatory and industry compliance for future mobility systems. The two standards are not alternatives. They are complementary layers of a complete safety framework.
Where Ariol Automotive operates
At AriolAutomotive, we work with OEMs, Tier-1 and Tier-2 suppliers, and software developers across international markets on the implementation of automotive safety and quality management standards, including ISO 21448, ISO 26262, and IATF 16949. Our work covers gap analysis, process design, documentation, and audit preparation across the full development lifecycle.
The organisations we work with range from established automotive suppliers extending their safety programme to new entrants bringing ADAS or software-defined vehicle functions to market for the first time. The starting point varies. The required outcome is the same: a safety process that meets international automotive standards and withstands independent technical scrutiny.
If your organisation is developing systems where safe operation depends on sensors and algorithms reading the environment correctly, ISO 21448 applies to you. The earlier it is integrated into the development process, the lower the cost and risk of doing so.
