Evidence boundary. Bendix documents a 2024 EC-80 ECU action for towing applications. VehicleSec 2026 research reports that the firmware update removed code containing exploitable flaws in J1587 PID processing and interrupt handling on the J2497 interface. The public research does not establish that cybersecurity was the reason the recall was initiated. The safety-to-cyber handoff proposed here is an engineering governance recommendation.

The same implementation weakness can enter through two assurance processes

The Bendix EC80 case is useful because it shows how safety and cybersecurity can observe the same code through different questions. A safety process can ask whether electrical noise, low signal quality or malformed inputs can drive a controller into an unsafe or degraded state. A cybersecurity process asks whether an adversary can intentionally create the triggering input, reach the affected interface and repeat the failure on demand.

At VehicleSec 2026, Ben Gardiner of NMFTA presented a differential reverse-engineering analysis of the EC80 firmware update. The work isolated changes on the legacy J2497 PLC4TRUCKS interface, including J1587 PID processing and interrupt handling. The researchers report that the removed functionality contained a write-where primitive and denial-of-service conditions. They validated the findings on a bench and in a moving truck, where exploitation caused loss of the speedometer, dynamic steering and automatic shifting.

That does not turn the safety recall into a cybersecurity recall after the fact. It shows something more useful: a corrective action can remove a condition that is exploitable even when adversarial behavior was not the original assurance question.

What this diagram shows

A safety symptom and a cyber exploit can converge on the same implementation defect. The missing control is often the handoff that recognises when a corrective action deserves adversarial review.

Safety-to-cyber handoffDo not merge the disciplines. Trigger the right second question when the affected code crosses an adversarial boundary.
Existing assurance path Shared implementation weakness
One defect, two questions
Safety stimulusNoise or malformed PLC inputCan accidental conditions trigger failure?
→
Trust breakParser / interrupt weaknessThe same code can process attacker-controlled input
→
Cyber questionReachability + controllabilityCan an adversary create the condition deliberately?
→
GovernanceTargeted cyber reviewEscalate only when predefined triggers are met
Decision gate

Did the safety corrective action modify code that parses, authenticates, routes or acts on externally influenced input?

YESRoute the change to a targeted cybersecurity review.
NODo not create a generic cyber gate without evidence of an adversarial boundary.

Reachability is what turns a safety defect into a security decision

The practical discriminator is not severity alone. It is whether the corrected behavior sits on a path an adversary can influence. NMFTA has previously documented that J2497 trailer receivers can be affected by remote RF-induced signals and has argued for reducing the functionality carried over the legacy interface. That matters because a parser defect that exists only behind a physically controlled manufacturing tool presents a different attack problem from the same defect on an interface that can be influenced from a trailer, maintenance device, telematics component or adjacent vehicle network.

The review therefore needs to reconstruct the real path, not simply relabel the defect. Which ECU can originate the input? What equipment bridges into the bus? Is the interface reachable in service, only during maintenance, or only in a specific vehicle configuration? Does the corrected code handle lengths, addresses, state transitions, memory writes or diagnostic actions that an attacker could manipulate?

This is where ISO/SAE 21434 is useful as a lifecycle discipline. It provides the framework for cybersecurity risk management across vehicle E/E systems and their lifecycle. The operational value, however, comes from the organisation defining when evidence generated by another engineering process should reopen the adversarial question.

A handoff trigger is cheaper than reopening every historical recall

Requiring a complete threat analysis for every safety recall would be difficult to scale and would dilute attention from the changes that actually modify an attack surface. Safety and cybersecurity teams also work with different evidence, tooling and competencies. The objective should not be to make one team perform the other's discipline.

A better mechanism is a narrow handoff rule. Trigger cybersecurity review when a safety corrective action changes a parser, communication stack, diagnostic service, memory-handling routine, externally influenced state machine, authentication or authorisation path, update mechanism, or interface that can be reached through another ECU or external device. The safety team only needs to identify the trigger. The cybersecurity team then determines adversarial reachability, exploitability and whether the correction changes the TARA, monitoring assumptions or post-development evidence.

The same logic should operate in the other direction. A cybersecurity finding that can alter braking, steering, motion, energy, pressure or another safety-relevant function should have a defined path into safety impact assessment. The control is not organisational convergence. It is bidirectional evidence routing.

A safety fix and a security fix can change the same code for different reasons. Mature assurance recognises when one discipline has generated evidence that must trigger the other.
The decision
Define a safety-to-cyber handoff trigger based on affected interfaces and adversarial reachability, rather than adding cybersecurity review to every safety corrective action.
Operational checks
  • Flag corrective actions that touch parsers, communications, diagnostics, memory handling, update logic or externally influenced state machines.
  • Map whether the affected input can be reached through another ECU, trailer, telematics unit, maintenance tool or aftermarket device.
  • Separate accidental-trigger evidence from the question of whether an adversary can generate the same condition intentionally.
  • Record whether the correction changes an existing TARA, cybersecurity claim, monitoring assumption or field-response obligation.
  • Create the reciprocal route from cybersecurity findings into functional-safety impact assessment when physical functions can be affected.
Where to go next

Continue this decision.

Recommended next · Automotive · Product Security · Supply ChainAftermarket Security Devices Can Become Part of the Vehicle Attack Surface

Dealer-installed security hardware can cross the vehicle trust boundary without being governed like an OEM security component.

→
Prefer audio? Open the companion episode →
Explore further

More on this topic

Automotive · Trust BoundariesThe Aftermarket Can Become Part of the Vehicle Trust BoundaryRead →Automotive · DetectionAn Automotive IDPS Alert Is a Decision Problem, Not a Detection ProblemRead →Automotive · Software IntegrityHow a Software-Defined Vehicle Could Inherit Compromise Before DeliveryRead →
Antonio González, PhD
Written by

Antonio González, PhD

Cybersecurity practitioner focused on product security, OT/ICS and cyber-physical systems. Cybersecurity Under Pressure translates incident evidence into engineering and business decisions.

About →LinkedIn ↗
Source record

Sources & further reading

6 cited sourcesHow we source →
← All analysisCompanion episode →