What breaks when car software updates are not code signed?

Why This Matters for Security Teams

Car software updates are not just maintenance files. They are executable trust decisions that can change braking logic, battery management, infotainment, telematics, and diagnostic behaviour. When an update is not code signed, the vehicle cannot reliably prove who produced it or whether the payload was altered in transit. That undermines the update chain at the exact point where integrity matters most.

This is why software supply chain guidance now treats signing as a baseline control rather than a nice-to-have. The risk is not limited to malicious outsiders; it also includes misrouted builds, compromised release infrastructure, and tampered third-party packages. NIST’s NIST Cybersecurity Framework 2.0 emphasises protecting system integrity across the full lifecycle, while NHIMG’s research on non-human identity governance shows how often machine trust paths are undercontrolled. In practice, many security teams discover update integrity failures only after an unsigned package has already reached a staging fleet or a fielded vehicle.

How It Works in Practice

Code signing adds cryptographic proof to the software release process. A build pipeline signs the update package with a private key held in a controlled signing environment, and the vehicle verifies that signature before installation. If the package is modified after release, signature verification fails. If the package comes from an untrusted source, it fails as well. That makes authenticity and integrity enforceable at the point of install, not just assumed during transfer.

For vehicle software, the signing workflow usually needs several layers:

• Signed build artifacts created from a controlled CI/CD pipeline.
• Hardware-backed key protection, ideally isolated from routine developer access.
• Version checks to block rollback to older vulnerable firmware.
• Separate trust validation for bootloaders, ECUs, telematics units, and OTA delivery services.
• Revocation and key-rotation procedures so a compromised signing key does not remain trusted indefinitely.

This is also an identity problem. The update package should be treated as a non-human workload with its own trust boundary, not as an anonymous blob. That is why NHIMG’s guide to non-human identities is relevant here: if the system cannot identify the producer of the update, it cannot make a defensible trust decision. Current guidance suggests aligning code signing with zero trust principles, where every update is verified at runtime rather than accepted because it arrived through an expected channel. These controls tend to break down in distributed vehicle fleets when legacy ECUs cannot validate modern signatures or when update gateways accept unsigned emergency patches under operational pressure.

Common Variations and Edge Cases

Tighter signing controls often increase operational overhead, requiring organisations to balance release speed against trust assurance. That tradeoff is real in automotive environments, especially when suppliers, tiered integrators, and regional service centres all touch the release path.

There is no universal standard for every vehicle architecture yet, but current best practice is clear on a few edge cases. Emergency patches still need signature validation, even if the signing process is accelerated. Offline update scenarios also need a verification path, since removable media and dealership tooling can become infection vectors. And when multiple vendors contribute firmware, the trust model must define whose key signs which component, how revocation is handled, and how compatibility is enforced across vehicle models.

NHIMG’s reporting on the Schneider Electric credentials breach is a useful reminder that compromised machine trust can have broad downstream impact once access paths are abused. For update signing, the same lesson applies: if the signing key, release pipeline, or verification logic is weak, the entire control collapses. Security teams should treat unsigned updates as a release-blocking defect, not a tolerance to be monitored after deployment.

Related resources from NHI Mgmt Group

• How should security teams protect code signing keys used for firmware and software updates?
• What breaks when supply-chain trust is based mainly on package popularity?
• What do security teams get wrong about vulnerability severity in AI-assisted code?
• When should organisations use virtual patching instead of waiting for a code fix?