Topic starter
25/06/2026 10:34 pm
TL;DR: Connected cars expand the attack surface because onboard systems, software updates, and back-end services all depend on trusted device identity, and DigiCert argues PKI is the control layer that makes those exchanges verifiable and tamper-resistant. Encryption and code signing help, but without certificate-backed trust the vehicle remains another exposed endpoint.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “Connected Cars Need a Security Solution: Use PKI”.
By the numbers:
- Roughly a quarter billion connected cars will be on our roads by 2020.
- There were already 21 million connected cars out there when the article was published.
Key questions
Q: How should organisations secure connected cars with PKI?
A: Organisations should use PKI to authenticate vehicle components, sign firmware, and encrypt communications between the car and external services.
Q: Why do connected cars create identity and trust problems beyond traditional endpoints?
A: Connected cars combine embedded devices, remote services, and software updates in a single environment, so trust has to work across multiple layers at once.
Q: What breaks when car software updates are not code signed?
A: Without code signing, the vehicle has no reliable way to verify who produced an update or whether it was altered before installation.
Practitioner guidance
- Map vehicle trust boundaries Identify which onboard systems, external services, and update paths must trust one another, then assign certificate scope to those boundaries rather than to the vehicle as a single flat trust domain.
- Govern code-signing keys as privileged credentials Treat software signing keys as high-risk identities with controlled issuance, storage, review, and revocation, because every trusted update depends on those credentials remaining uncompromised.
- Require verified update chains Only allow firmware and software updates that can be traced to a trusted signing authority, and block any update path that cannot prove origin and integrity before installation.
Bottom line: Connected cars expand the security problem from isolated endpoints to distributed machine identities that must prove themselves before they can communicate or update.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 11:09 pm
Connected cars are a machine identity problem before they are a vehicle problem. The article is really describing a trust architecture for distributed devices that must authenticate each other continuously across external services, updates, and internal controllers. That places connected cars squarely in NHI governance territory, where identity issuance, certificate trust, and revocation are the control plane. The practitioner takeaway is that automotive security programmes need machine identity governance, not just perimeter controls.
A few things that frame the scale:
- 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.
A question worth separating out:
Q: What is the difference between encrypting car communications and verifying device identity?
A: Encryption protects the contents of communication, while device identity proves who is sending or receiving it. Connected cars need both because encrypted traffic is still risky if the endpoint cannot be trusted. PKI supplies the identity layer that makes encryption meaningful in a fleet of distributed embedded systems.
👉 Read our full editorial: PKI is the missing trust layer for connected car security