Inspect the update path first, then the cloud services that talk to the fleet, then diagnostic and wireless access, then third-party software inside the vehicle. That order follows where an attacker can reach many vehicles at once. Safety engineers should review every finding before any change reaches a road.
This is an orientation for defenders, not a threat report. It names no manufacturer and describes no incident.
Why start with updates?
A vehicle fleet is a distributed system with one shared pipeline: the software update path. If someone can alter what goes to the vehicles, the effect scales. If updates fail to verify, the effect scales too.
Check how builds are produced and signed, who can sign, where the keys live, how the vehicle verifies a package before applying it and what happens if verification fails. Ask what the rollback story is and whether a bad release can be halted fleet wide.
UNECE regulations are often cited here: R155 on cyber security and cyber security management systems, and R156 on software updates. We could not retrieve the UNECE text for this post, so confirm scope and dates from the primary source before relying on this summary.
What comes second?
Backend and fleet services. Telematics, mobile apps and fleet portals are ordinary web services with accounts, APIs and databases. Review authentication, authorization between customers, API exposure and secrets handling. A flaw here may expose many vehicles without touching any in-car code.
Diagnostic and physical access. Service ports and diagnostic tools are meant for trusted technicians. Check what they can do, whether access is authenticated and how service tools themselves are protected.
Wireless interfaces. Cellular, Bluetooth, Wi-Fi and key fob links each have their own pairing and protocol assumptions. Inventory them and ask which are reachable without user action.
What is third in line?
Third party and open source software. A vehicle's software stack combines supplier modules, operating systems and libraries. You cannot assess what you cannot list. CISA describes an SBOM as a nested inventory of the ingredients that make up software components. Ask suppliers for one per software release, and ask how they will tell you when a component has a known vulnerability.
For the machine learning parts, add model and dataset provenance to the inventory. Treat model files as artifacts with owners, versions and integrity checks.
How do safety and security meet?
NIST's SP 800-82 Revision 3 covers operational technology including transportation systems among its examples, and it stresses performance, reliability and safety requirements next to security. The same principle applies to vehicles: a patch is also a safety change. Run it through the same validation as any other release, and keep security and safety engineers in the same review.
What should the first review produce?
A short report with an architecture sketch, a list of external interfaces, the update pipeline description, a component inventory with known gaps, and a ranked list of questions for suppliers. Aim for something an engineer can act on in a week, not a binder.
What to do
- Draw the update pipeline from build to vehicle and mark every signature and verification point.
- Review who can publish a release and how keys are protected.
- Inventory backend services, APIs and mobile apps, then test authorization between customers.
- List diagnostic and wireless interfaces and what each can do.
- Request component lists from suppliers for each software release.
- Check secrets in repositories, build logs and service tooling.
- Review rollback and fleet halt procedures.
- Pair every finding with a safety review before any fix ships.
Quick check
Why look at the update path before in-car code?
It is shared by every vehicle, so a weakness there has the widest reach.
Which regulations apply?
UNECE R155 and R156 are commonly cited for cyber security management and software updates. Confirm scope and dates in the primary text, since we could not retrieve it.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, fetched 18 October 2026
- Software Bill of Materials (SBOM), CISA, fetched 18 October 2026
Last reviewed: 18 October 2026.
