Title: The Automotive Safety Standards Map: Beyond ISO 26262 | ISO 26262 Academy URL: https://iso26262.academy/blog/the-automotive-safety-standards-map-beyond-iso-26262 Description: ISO 26262 covers malfunctions. Sensor limits, attackers and machine learning each got their own standard. How the four fit together. --- [Technical](https://iso26262.academy/blog/category/technical) # The Automotive Safety Standards Map: Beyond ISO 26262 ![Driver's view down a wet motorway. Heavy spray from the traffic ahead hangs over the carriageway in a low backlit sun, and the painted lane markings fade out well before the cars do.](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/09/756ccadd-b332-4221-8ab0-862dea3176ef-1200.webp) A modern car can cause the same accident four different ways. Only one of them is a malfunction. Lane centering steers into the next lane. Same severity, same exposure, same controllability. One hazard. Now ask why. A solder joint opened. Or the camera worked perfectly and lost the markings in low sun. Or someone forged a steering frame on the bus. Or the model met a road marking that was never in its training data. ISO 26262 owns the first one, and it says so itself. The other three each got a document: ISO 21448, ISO/SAE 21434, ISO/PAS 8800. The hard part is not learning four standards. It is that one item definition and one hazard list have to feed four arguments that must not contradict each other. New article on where the backbone ends. ![ISO 26262 Academy](https://iso26262.academy/logo.png) ISO 26262 Academy By [Paul Danci](https://iso26262.academy/about) 3 September 2026 7 min read Share Text size The awkward part is not that there are four causes. It is that they share almost nothing: different mechanism, different analysis, different evidence, different team. ISO 26262 was written for one of them. It is still the backbone of automotive safety. It is no longer the whole argument. ## One hazard, four causes Take lane centering, which keeps a car between the painted lines on a motorway while the driver stays responsible for it. Four things work in series: a camera that sees the lines, a model that decides where the lane runs, a controller that turns that into a steering demand, and an actuator that obeys. Break any one and the outcome is identical. The car moves sideways at speed without being asked, and the severity, exposure and chance of catching it never change. ![One hazard box, unintended steering torque at motorway speed, fanning into four columns: a broken wire, low sun on a wet road, a forged bus frame and a marking pattern that was never in the training data. Each column names the analysis that finds it and the document that leads on it, with a note that the columns overlap.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/09/5ddd2374-2775-4466-aa27-142f40f008d7.svg) The cause, not the consequence, decides the analysis, the evidence and the team. Ask what produced it and the one hazard becomes four unrelated problems. A cracked joint sends the controller a torque value nothing ever measured. Glare off wet tarmac erases the lines while the camera meets every clause of its specification. A compromised gateway puts a counterfeit steering message on the bus. Or the model meets a lane marking absent from its training data and commits to the wrong one. Only the first is a malfunction. In the other three nothing misbehaved: each part did what it was built, trained or told to do, and the car still went where it should not. Which of the four it is settles the analysis that catches it, the evidence that closes it, and whose name is on it. The four are not sealed off from each other. ISO/PAS 8800 layers onto ISO 26262 and ISO 21448 rather than replacing them, so that unseen marking is an AI insufficiency and a SOTIF one at once, and a fault in the accelerator running the model is still ISO 26262 work. ## The fence ISO 26262 drew around itself ISO 26262 draws its territory narrowly: risk that comes from electrical and electronic systems malfunctioning, and only that. Two ideas carry the weight. _Malfunctioning behaviour_ covers any departure from specified behaviour, from a random hardware fault or a systematic one in the requirements, the design, the timing or the code. _E/E systems_ means electrical, electronic and programmable electronic, not mechanics or chemistry, unless a malfunction reaches them. ![The ISO 26262 definition of functional safety with the phrases 'malfunctioning behaviour' and 'E/E systems' underlined and explained, and below them the three things the standard places outside its scope: nominal performance, a deliberate attack, and shock, fire and fumes.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/09/b724effd-f699-43d6-8f9e-6449f450cf3a.svg) Every sibling standard exists because of something on the far side of this sentence. It is then explicit about what it leaves outside. It does not address the nominal performance of a function: a sensor specified for daylight that misses a pedestrian at night has not malfunctioned. It does not address electric shock, fire or toxic fumes unless a malfunction caused them. And its guidance on the interaction with cybersecurity sits in an informative annex, without saying how to engineer against an attacker. These were scoping decisions, not oversights. The usual reading is that they made a first edition possible, and that they held while safety-relevant electronics ran hand-written software with little outside exposure. Assistance systems stopped warning and started acting, vehicles became connected, perception moved to trained networks. Each of those shifts produced a document. Shock and fire never joined this map. Keep learning [Free course preview The Automotive Safety Standards Map](https://iso26262.academy/features/concepts/automotive-safety-standards-map) [Or test yourself with the 7-question demo exam](https://iso26262.academy/demo-exam) ## The siblings, and what kind of document each one is | Leading document | Hazard source | Published as | What the analysis looks for | | --- | --- | --- | --- | | **ISO 26262** | An E/E system malfunctions | International Standard, second edition 2018 | Random hardware faults, systematic faults | | **ISO 21448** | It reaches its performance limit | International Standard 2022, publicly available specification 2019 | Triggering conditions, and foreseeable misuse | | **ISO/SAE 21434** | Someone attacks it on purpose | International Standard 2021, jointly with SAE | Assets, threat scenarios, attack feasibility, risk treatment | | **ISO/PAS 8800** | A learned model meets what it never saw | Publicly available specification, 2024 | Data coverage, model evaluation, an AI assurance argument | Leading document, not exclusive one: ISO/PAS 8800 layers onto ISO 26262 and ISO 21448. A publicly available specification carries less consensus than an International Standard. Where ISO 21448 applies, the system is working. The hazard comes from a performance limitation, a specification that never anticipated the situation, or foreseeable misuse: a blinded sensor, an algorithm confused by a scene, a driver who misread the limits. Analysts hunt triggering conditions, not broken parts. ISO/SAE 21434 replaces the random fault with a motivated adversary. A failure rate says nothing about someone choosing where to push, so the analysis becomes assets, threat scenarios, attack feasibility and a treatment decision per risk. ISO/PAS 8800 covers what cannot be argued by reading the code. A learned model has no requirement traceable to a line of logic, so the argument moves to the data it was trained and tested on, the insufficiencies of its outputs, and the assurance case tying them together. ## The law that reads your safety case The standards themselves stay voluntary. What became compulsory is narrower. UN R155 and R156, in force since 2021 and applying to all new EU vehicles since July 2024, require certified cybersecurity and software update management systems; the second General Safety Regulation made a list of assistance systems mandatory on the same date. UN R157 covers automated lane keeping, not the supervised feature above. Search their normative text for ISO 26262 and you will not find it. The approval file gets built from its work products regardless, because that is where the state of the art sits. ## One item, four arguments ![A row of shared work products, item definition through safety case, feeding four argument columns: functional safety, SOTIF, cybersecurity and AI assurance. Below them, two notes showing a mitigation in one lane spending something in another.](https://academy-videos.fra1.digitaloceanspaces.com/blog/diagrams/2026/09/e5b17cfd-76bc-4e86-943e-0474402150fb.svg) Facts are written once, reasoning stays with whoever owns it, and every mitigation spends something in a neighbour’s lane. Two arrangements suggest themselves: run the lifecycles back to back, or side by side with a team on each. Both fail alike. The item definition feeds four analyses. Hazard severities become safety impact ratings in the threat assessment. Cybersecurity controls become failure modes and latency in the budget. SOTIF triggering conditions become data requirements for the AI lane. What works is one set of facts and four arguments. Anything factual about the item, where its boundary runs, what can go wrong, how it is built, gets written once and read by all four. What each lane keeps is the reasoning. Splitting the safety case four ways is the obvious move and the wrong one, because each argument retains a risk the other three need to see. It is also where mitigations collide. Authenticating bus messages buys integrity and spends part of the fault-tolerant time interval. Diagnostics for random hardware faults buy coverage and spend the compute headroom a perception model needs. Neither trade is visible from inside the lane that made it, which is why it belongs in the architecture phase. ## Where the backbone ends ISO 26262 has not been demoted. Its subject is still the E/E system that does the wrong thing, and the rest of the map exists because a system can do exactly the right thing and still hurt somebody. Knowing where it stops is now part of knowing it. The [Automotive Safety Standards Map](https://iso26262.academy/register?from=%2Fconcepts%2Fautomotive-safety-standards-map) concept page covers the territory in sixteen chapters: who writes the documents, how the lifecycles interlock, and one feature traced through every one. ## Abbreviations & Key Definitions - **E/E** - Electrical and Electronic, including programmable electronics. - **ISO 21448** - The standard for the Safety of the Intended Functionality. - **ISO 26262** - The standard for functional safety of road vehicles. - **ISO/PAS 8800** - The publicly available specification for safety and artificial intelligence. - **ISO/SAE 21434** - The standard for road vehicle cybersecurity engineering. - **SOTIF** - Safety of the Intended Functionality: hazards while the system performs as specified. - **UN R155, R156, R157** - UN regulations on cybersecurity, software updates and automated lane keeping. Photograph: spray on a wet autobahn, by Andreas Bunen, [CC BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/), via [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Wasser_Gefahr_Auf_Autobahn_(214467807).jpeg); cropped, and the crop is under the same licence. Related on the Platform [The Automotive Safety Standards Map Concept](https://iso26262.academy/features/concepts/automotive-safety-standards-map) [AV Safety: ISO 26262 + SOTIF + ML in Practice Concept](https://iso26262.academy/features/concepts/av-safety-iso-sotif-ml) [Safety and Cybersecurity Co-Engineering Concept](https://iso26262.academy/features/concepts/safety-cybersecurity-co-engineering) [Homologation, Regulations and Liability Concept](https://iso26262.academy/features/concepts/homologation-regulations) Last updated: 13 October 2026 Tags [automotive-standards](https://iso26262.academy/blog/tag/automotive-standards) [sotif](https://iso26262.academy/blog/tag/sotif) [cybersecurity](https://iso26262.academy/blog/tag/cybersecurity) [iso-26262](https://iso26262.academy/blog/tag/iso-26262) [ai-safety](https://iso26262.academy/blog/tag/ai-safety) Share this article ## Read the full Automotive Safety Standards Map From HARA to Safety Mechanisms - master every concept with clear, practical explanations and real-world examples. [Browse Concepts](https://iso26262.academy/features/concepts/automotive-safety-standards-map) ## Comments ## Related Articles [![Comparison table showing the differences between traditional ISO 26262 functional safety and ISO 21448 SOTIF hazard analysis methodologies.](https://iso26262.academy/_next/image?url=https%3A%2F%2Facademy-videos.fra1.digitaloceanspaces.com%2Fblog%2Fimages%2F2026%2F06%2Fdb32594d-6587-4e97-807b-bd4fa1b31233.webp&w=1920&q=75) Miscellaneous ### SOTIF for Functional Safety Engineers: An Exploratory Guide 6 min Jun 10](https://iso26262.academy/blog/sotif-functional-safety-engineers-iso-21448-guide) [![Plan view of a road. In the next lane an overtaking vehicle is drawn twice: a dashed grey outline where the mirror panel still shows it, and a solid red one further ahead where it actually is, with the gap between them marked.](https://academy-videos.fra1.digitaloceanspaces.com/blog/images/2026/08/5fd36744-ed9b-4e33-823d-b578c899b9ee-1200.webp) Technical ### Interior and Mirror Cameras: The Stale Frame Problem 8 min Aug 31](https://iso26262.academy/blog/interior-and-mirror-cameras-functional-safety) [![Demystifying AV Safety: Integrating ISO 26262, SOTIF, and ML](https://iso26262.academy/_next/image?url=https%3A%2F%2Facademy-videos.fra1.digitaloceanspaces.com%2Fblog%2Fimages%2F2026%2F06%2F29b296a6-9744-40d4-bc48-062f2befed1f.webp&w=1920&q=75) Technical ### Demystifying AV Safety: Integrating ISO 26262, SOTIF, and ML 8 min Jun 5](https://iso26262.academy/blog/av-safety-integrating-iso-26262-sotif-ml)