Key takeaways
- Automotive compliance is usually captured as a snapshot at release or audit time, but resilience is a culture sustained across the full lifecycle and into incident response.
- Traceability tends to break first because it feels like paperwork, and the cost surfaces later in risk management when teams can no longer reconstruct why a requirement or a failed test mattered.
- A memory-safety policy is not the same as a memory-safe product. What reduces exploitability is what gets compiled into the binary, not what a development standard says.
- The attack surface now reaches past the vehicle to EV chargers, as Pwn2Own Automotive 2026’s 76 zero-days showed, and CISA’s BOD 26-04 reflects a broader move from raw severity scores toward exposure and exploitability.
- RunSafe focuses on runtime hardening that reduces the exploitability of compiled embedded software, adding a binary-level layer to an organization’s defense-in-depth.
In January, researchers at Pwn2Own Automotive 2026 disclosed 76 unique zero-day vulnerabilities and walked away with more than $1 million in prizes. The biggest payouts went to EV chargers, including the first public exploit of a supercharger. Many of the winning entries relied on memory-corruption bug classes that have plagued embedded software for decades, including stack-based buffer overflows and out-of-bounds writes.
The results land at an awkward moment for the industry. Automakers and suppliers are absorbing a stack of overlapping mandates at once. ISO 21434 for cybersecurity engineering, UN Regulation No. 155 for type approval, ISO 26262 for functional safety, ASPICE 4.0 for process capability, and the EU AI Act for systems that now ship machine learning inside and around the vehicle. The paperwork to satisfy all of it is enormous. The harder question is whether any of that documentation actually makes a car safer once it is on the road.
That gap, between what compliance demonstrates on paper and what resilience requires in the field, was the subject of a recent Mobex webinar produced by Automotive World. The panel brought together Tyson Benson, Process Owner and Cybersecurity Engineer at Clarios, and Dr. Joachim Fox, who recently led safety and cybersecurity governance for ZF’s automotive products and now chairs &ai Foundation, a foundation focused on the ethics of AI. Here is what came out of the conversation.
When Governance Outruns Engineering, the First Casualty Is Truth
Ask a governance leader what breaks first when expectations exceed what teams can deliver, and you might expect an answer about missed audits or incomplete artifacts. Fox went somewhere more uncomfortable.
“The first thing which breaks is truth,” he said. He was careful to explain that this is rarely about dishonesty. When expectations are unrealistic and a deadline is bearing down, engineers under pressure produce high-level, hard-to-verify answers because that is what the moment demands. The forms get filled in, while real visibility into risk erodes. As Fox put it, facts get diluted “if you don’t come with realistic expectations.”
Benson framed the same problem from the architecture side. In his view, “convergence has outrun accountability.” The software-defined vehicle has folded AI tooling, supply chain dependencies, developer environments, and connected interfaces into one shared risk surface. Ownership of that surface, though, is still scattered across product teams and tiers of suppliers, delegated and fragmented in ways that the standards assume but do not resolve.
Both speakers agreed that compliance is usually measured as a snapshot, captured at release time or during an audit. Resilience is something else. “Compliance is not a snapshot, but it’s a culture,” Fox said, a safety culture that has to persist through development and well past it, into incident response and into the unpredictable conditions an autonomous system meets on real roads. Organizations tend to know this, but implementing it is the hard part.
Traceability Breaks First, and the Bill Comes Due Later
If culture is the abstract failure point, traceability is the concrete one. It is one of the central goals of ASPICE, and it is also the requirement that tends to collapse soonest, because it feels like overhead. “It seems to be paperwork, and because it is felt often as being paperwork, it usually breaks first,” Fox said.
The danger is that the failure is invisible at first. When traceability lapses, the documentation breaks before the product does. The cost shows up later, in risk management, when a team can no longer reconstruct why a requirement existed, what a failed test was protecting against, or how a feature connects to the rest of the system. Without those links, understanding how a change ripples through the vehicle becomes guesswork.
Benson has watched teams fight this in practice. Engineers trained to write code are handed the additional job of decomposing customer requirements into functional and non-functional ones, splitting them across hardware and software, and threading the whole thing through a traceability tool such as JAMA. The work is real, and so is the resistance to it. His answer is not to police the process harder, but to show engineers that the effort produces a better, safer product rather than another box to check before an auditor arrives.
Fox made a parallel point about safety analysis. When an analysis keeps returning the same clean bill of health year after year, people stop believing in it, and governance has a responsibility to steer scarce attention toward the work that still changes outcomes.
What Actually Reduces Risk Lives in the Compiled Binary
The panel’s sharpest practical exchange came when the conversation turned from process to deployed systems. A memory-safety policy, Benson noted, is not the same as a memory-safe product. “An internal policy that you use memory-safe practices doesn’t reduce anything at runtime. What reduces the exploitability of that binary is what’s actually compiled into it.”
That is the distinction the Pwn2Own results illustrate. The bug classes that won prizes are exploitable in the field regardless of what a development standard says, and the attack surface keeps widening. Benson pointed to EV chargers as a boundary that many programs underestimated. “The security boundary has expanded because the attack surface has expanded to these chargers,” he said, describing exactly the shift the competition put on display when researchers compromised chargers from multiple manufacturers.
Fox laid out the defensive principle that should govern this space. Borrowing from functional safety’s idea of freedom from interference, cybersecurity relies on defense-in-depth and multiple independent layers, so that no single control failure is catastrophic. Authenticated diagnostic access, signed and secure software downloads, continuous signature checks on running code, and rollback protection against downgrades to vulnerable versions. The goal is that authorization breaking in one place does not hand an attacker the device.
Defense in depth at the binary level means hardening the software so that even when a memory-corruption flaw exists, an attacker cannot reliably turn it into working code execution. That hardening is compiled in, which is precisely the runtime layer Benson described as the thing that actually changes exploitability. It complements the layers Fox outlined rather than replacing them.
Regulators are moving in a compatible direction. CISA’s Binding Operational Directive 26-04, issued June 10, 2026, tells federal agencies to prioritize remediation by exposure, known exploitation, attacker automation, and post-exploitation impact rather than by severity scores alone. Benson welcomed the shift, recalling how often a CVSS rating of “nine point eight” triggers a reflexive alarm without the second look that asks whether the flaw is actually reachable. Treating a probabilistic AI suggestion or a raw severity number as a final answer, he warned, is “system one” thinking where the situation calls for “system two.”
The Responsibility Never Sits with the Machine
The through-line of the panel was that resilience is a capability an organization sustains, not a document it produces once. Fox argued for spending less time perfecting threat analyses for standardized, well-understood systems and more on the ability to respond fast when something breaks in the field, because adversaries and unforeseen conditions cannot all be modeled in advance.
That same logic shapes how the panelists think about AI in safety and security work. Used well, agentic tools can pre-review compliance documentation, run consistency checks, and help finally achieve the traceability that ASPICE has demanded for years. But the accountability does not transfer. “The responsibility lies never with the machine,” Fox said. If an AI review informs the decision to release a product, the person who released it owns that decision.
For the engineers and program owners carrying these mandates, that is the reassuring part. The work that matters most is the work they are already best positioned to do. Building products that hold up, and being ready to answer for them.
The full conversation, including the panel’s take on keeping humans meaningfully in the loop as AI enters the development pipeline, is available on demand from Automotive World.
