Once a vehicle can receive commands or updates from the cloud, the first security question isn't 'how do we encrypt the connection' — it's 'how do we know this vehicle is actually the vehicle it claims to be.' That's an identity problem before it's an encryption problem.
Certificates, Not Shared Secrets
A shared password or static key, once extracted from one vehicle, compromises every vehicle that uses the same credential. Certificate-based identity — where each device holds a unique key pair tied to a manufacturer-issued certificate — means compromising one vehicle doesn't compromise the fleet. It also makes revocation possible: a compromised device's certificate can be revoked without touching anyone else's.
Key Rotation Has to Be Operationally Realistic
Security best practice says rotate keys periodically. Fleet reality says you can't recall a vehicle for a service visit every time a key needs rotating. Rotation has to happen over the same OTA channel used for software updates, with the same staged-rollout discipline — because a botched key rotation can lock a vehicle out of the fleet just as effectively as a botched firmware update.
Monitoring Is the Part Most Programs Skip
Identity and encryption stop known bad actors from impersonating a vehicle. They don't tell you when something unexpected is happening on the vehicle network — an unauthorized ECU, an unusual pattern of diagnostic requests, traffic that doesn't match any known baseline. That requires continuous monitoring, not just strong credentials at the door.