Automotive PKI and key management for OTA

Why a vehicle needs to prove things to itself

An over-the-air update is a stranger arriving at the door. The vehicle has to decide, frequently without a live connection to anyone who can vouch for it, whether that stranger is genuine before letting it change how the vehicle behaves. Public-key infrastructure (PKI) is how it makes that decision. It lets the vehicle verify a digital signature against a chain of trust it already carries, so that authenticity does not depend on a shared secret that could leak.

This matters because UN R156 does not merely suggest that updates be trustworthy — it expects a Software Update Management System that protects the integrity and authenticity of updates end to end. PKI is the mechanism most programmes reach for to satisfy that, and it is the same mechanism that underpins a secure OTA update workflow, V2X message trust and EV charging authentication.

What PKI actually does in a vehicle

At its simplest, PKI pairs a private key that signs with a public key that verifies. The private key stays in protected infrastructure; the public key, or a certificate chain rooted in a trusted authority, travels with the vehicle. Three uses dominate:

• Signing software updates. The build is signed in the back-end; the vehicle verifies the signature before install.
• Authenticating ECUs and diagnostic tools. Certificates let components and testers prove identity, closing gaps that weak diagnostic access leaves open.
• Trusting V2X and charging peers. Messages from other vehicles, roadside units and chargers are authenticated against a shared trust hierarchy.

The signing side of OTA is only half the picture. The vehicle must also be able to reject anything that does not verify, and to do so even when the attacker controls the delivery channel. A signature that verifies against a trusted root is proof of origin and integrity at once; an altered package simply fails to verify.

The lifecycle is the hard part

Designing a signing scheme is straightforward. Keeping the keys safe across a vehicle programme that runs for a decade or more is where effort goes. Key management is a lifecycle, and each stage has its own failure mode.

Stage	What it means	Where it fails
Generation	Keys created with proper entropy, in a controlled environment	Weak randomness; keys generated on general-purpose hardware
Storage	Private keys held in an HSM; on-ECU keys in secure hardware	Plaintext keys in a database, laptop, or build server
Distribution / injection	Keys injected into ECUs, usually at the plant	Exposure on the assembly line; shared keys across units
Rotation	Keys replaced on a schedule or on suspicion of compromise	No mechanism to roll keys without a recall
Revocation	A compromised key or certificate marked untrusted	No revocation path; vehicle keeps trusting a bad key
Destruction	Retired keys securely deleted	Copies linger in backups and old tooling

Hardware security modules (HSMs) protect the private keys that sign updates, so that even a breach of the signing service does not yield the key itself. On the vehicle side, secure hardware protects the keys an ECU uses to verify and to authenticate. The principle throughout is that a key should be unique where it can be — per ECU rather than per model range — so that compromising one unit does not compromise a fleet.

Rotation and revocation are the parts programmes most often defer, and most regret deferring. If there is no way to roll a signing key or revoke a certificate without touching every vehicle, then the day a key is suspected of compromise becomes a recall rather than an update. The ability to revoke and re-establish trust remotely is itself a design requirement, not a contingency.

The plant is inside the boundary

Key injection happens where the ECU is built and flashed, which means the manufacturing environment is part of the PKI's attack surface. A signing scheme that is immaculate in the back-end is undone if keys are exposed at end-of-line, or if the same key is written to every unit. This is why PKI and key management cannot be discussed apart from IEC 62443 and the vehicle plant: the flashing stations, the key stores and the operators handling credentials at volume are all in scope. IT/OT convergence is not an abstraction here — the plant OT, the back-end IT and the vehicle share one trust chain, and the weakest link sets the strength of the whole.

Beyond OTA: V2X and charging

The same infrastructure extends outward. V2X security relies on a PKI that issues pseudonym certificates so vehicles can authenticate one another's messages without being trackable, and cooperative-ITS ecosystems stand or fall on the health of that hierarchy. EV charging under ISO 15118 uses certificate-based mutual authentication between vehicle and charger. In each case the pattern is identical: trust is established through certificates rooted in a managed authority, and the security is only as good as the lifecycle behind those certificates.

How it reads in an assessment

A UN R156 assessment looks for evidence that update integrity and authenticity are protected, and that the organisation manages the keys behind them across the lifecycle — not just that a signing step exists. ISO 24089, the software-update engineering standard beneath R156, and the process substance of ISO/SAE 21434 frame this as engineering with records, not a slide describing a signature. An assessor who asks how a compromised signing key would be rotated is asking a fair question, and the answer needs to be a documented, tested process.

The AutoSifu view

We design the PKI and key lifecycle so it produces the evidence an assessment needs, and we do it on a single route with CIRT — compliance, solutioning and CoC/VTA support — so the trust architecture and its records are built to be assessed, not retrofitted. With the approval body in the room, questions about rotation, revocation and plant-side key handling get answered against a real design rather than a diagram.