Imagine the Inter-process communication (IPC) layer on an Autonomous Driving (AD) stack exposes a Data Distribution Service (DDS) TCP socket, no authentication, reachable from any process on the compute platform. An attacker who can reach it can inject arbitrary messages into the planning, control, and perception stack, with no barrier. The entry point wasn’t in the TARA. It was two abstraction levels below the architecture diagrams used to build the threat model.
The gap between the system as modeled and the system as implemented is not a process failure. It’s structural. The threat modeling methods built around ISO 21434 were designed for traditional automotive architectures: bounded ECUs, clear external interfaces, customer-supplier hand-offs, architecture-level threat enumeration, breadth over depth. AD systems don’t fit that model, not because they’re more complex, but because they’re a different category of system, and the security thinking hasn’t caught up.
Automotive security has come a long way, from academic and white-hat research to industry-wide compliance frameworks. Mandated by ISO 21434 and UNECE R155, OEMs and tier suppliers must now apply rigorous security engineering processes across all ECUs and E/E architecture.
“All models are wrong, but some are useful.” The same applies to threat models. A sound threat model is the foundation for all security engineering activities that follow. Conventional threat models were built for connected vehicles with bounded, well-understood attack surfaces: CAN bus attacks, ECU firmware, development interfaces, V2X. AD systems are fundamentally different in the following ways:
- The software complexity is orders of magnitude higher: millions of lines of C++, AD middleware, custom IPC implementation, GPU inference pipelines running simultaneously
- The safety-security intersection is unique: an exploit doesn’t mean data theft, it means tons of machinery behaves unpredictably at highway speed
- Traditional TARA assumes relatively static system boundaries; an AD system has dynamic runtime behavior that changes the attack surface continuously
Traditional automotive security is built around the perimeter: keep attackers out, and you’re safe. It focuses on external interfaces: OBD ports, V2X, telematics, and on-board networks with external exposure. In an AD stack, the most dangerous attack paths are internal: falsified sensor data to the perception or localization sub-system, inter-process communication over shared memory, unauthenticated service interfaces, denial-of-service against safety-critical subsystems.
Perimeter thinking misses the most exploitable surface entirely. Every internal interface, every IPC channel, every shared memory segment operates on an implicit assumption that whatever is communicating with it is legitimate. That assumption was never designed to be verified. It was designed to be fast, deterministic, and safe: three properties that have nothing to do with security.
Systems designed for functional safety assume random physical faults. ASIL analysis doesn’t ask the question “what if the input is deliberately crafted?” The safety mechanisms built to handle random faults are precisely the entry points an attacker uses.
There is no bug to find and patch. The attack surface is the design itself.
Take the localization subsystem for example. It is designed to fuse sensor data gracefully under signal uncertainty, absorbing noisy or degraded measurements as plausible updates. GNSS spoofing exploits this directly: in a GNSS/IMU-based localization, a spoofed signal enters the fusion pipeline as a valid measurement. The localization estimate drifts. The planning module consumes that estimate as ground truth. It has no mechanism to question it. The vehicle routes against a map that no longer matches reality. In such a scenario, no component in the chain failed. Each did exactly what it was designed to do.
The same pattern holds for safety watchdogs. A watchdog that detects anomalies and triggers a safe state (a controlled stop, or a Minimal Risk Maneuver) is a reliable way to induce behavior on demand. An attacker who knows which failure modes the system handles gracefully knows which conditions to induce. Trigger the watchdog, trigger the safe state. It is a denial-of-service via the safety system itself, with no application-layer exploit required.
Architecture diagrams correctly show what components exist and how they interact logically. What is not shown is how third-party libraries handle malformed inputs, implementation decisions made under time pressure: authentication deferred, bounds checking absent, how shared memory segments are actually mapped, or which version of a dependency is running with a known vulnerability. The exploitable surface exists at a different level, typically sitting two or three abstraction levels below where any TARA is conducted.
The contrast is concrete. A TARA entry might read: “Attacker injects malformed sensor data into the localization module via the IPC interface.” In practice, the code reveals: sensor messages are deserialized using a library with no bounds checking on variable-length fields; the shared memory segment is mapped with permissive access; the subscriber interface has no authentication. All of this is invisible at the diagram level. All of it is exploitable.
This is the compliance trap. A TARA conducted at the architecture level looks complete: every documented system component is covered. In reality, that completeness is an artifact of the documentation, not a property of the actual system. A review only confirms that everything from the design documentation is modeled. But it says nothing about what isn’t documented. You can satisfy every ISO 21434 process requirement and still have a fully exposed IPC interface.
Security starts with building a sound threat model that can guide the design of security architecture and the implementation and testing of the security designs. If the ultimate goal is an AD stack that withstands cyber attacks, these approaches are essential to how the threat modeling work gets done.
- Map the attack surface first. The attack surface is not only the perimeter around the vehicle. It is what is actually exposed across all layers of the software stack: inter-process communication layer, shared memory, message queues, middleware connectors. Understand it deeply before modeling anything else.
- Treat safety-critical paths as highest-priority attack targets. Prioritize localization, planning, control: anything that feeds directly into vehicle behavior. An attacker who understands functional safety design can use it against you.
- Start offensive, then go defensive. Probe the system hands-on before finalizing the threat model. What you find in the code will invalidate half of the initial assumptions.
- Connect findings to the compliance framework, not the other way around. ISO 21434 processes should capture what you found, not constrain what you look for. An attacker does not follow your process definition to explore and exploit your system.
The deeper problem is structural. In most organizations, the security team operates like a consultant: handed design documentation, tasked to produce a TARA, never given access to the codebase. Security teams that attend developer interviews or workshops gain a secondary understanding of the system behavior at the code level, filtered through what developers choose to highlight, and bounded by the questions the security team knew to ask. A security engineer reading the code directly finds what no one thought to look for. Closing the gap requires engineers who can bridge offensive technical depth, production engineering reality, and compliance navigation in the same engagement. That combination is rare.
UNECE R155 and ISO 21434 have moved the automotive industry toward systematic security engineering, a genuine improvement over what came before. For AD systems today, where the failure mode is physical harm and the adversaries include nation-state actors and global competitors with enormous R&D investments, compliance sets a necessary floor, not the ceiling.
Robotaxi deployments have been live for two years. Autonomous trucking is in production trials. An attacker who finds the exposure first can steer a self-driving vehicle on a public road, with consequences no patch can undo. The first serious cybersecurity incident in a deployed AD system will arrive before most organizations have closed these gaps. What happens then will define how the industry and regulators respond. The time to close the gap is now, not after the incident that forces the conversation.
The question is whether the security work being done on AD systems goes several levels deeper than any architecture diagram shows, because that’s where the exposure is. It’s not whether the exposure is there. It’s whether security engineers have ever looked.