PKI is the missing trust layer for connected car security

At a glance

What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: PKI should serve as the trust layer for connected cars because certificate-backed identity is needed to verify devices, updates, and communications.

Why it matters: It matters because connected vehicles now behave like distributed identity environments, and IAM teams need to think about device trust, code signing, and certificate lifecycle as security controls, not implementation details.

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.

Context

Connected cars create a trust problem because they depend on external communications, remote updates, and software-mediated functions that must be authenticated before they are trusted. In identity terms, the challenge is not only whether the vehicle is secure, but whether the systems talking to it can prove who they are.

The article frames this as a PKI question rather than a purely automotive one. That matters for NHI governance because vehicles, backend services, update channels, and embedded components all behave like machine identities that need issuance, validation, and revocation rules.

The practical issue is familiar to IAM teams: scale, trust chaining, and lifecycle control become harder as endpoints multiply. Connected cars extend those problems into physical systems, where certificate-backed identity is being asked to protect both data and safety-critical functions.

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. The important point is that the car should trust cryptographic identity, not network location. That means certificates, revocation, and renewal must be operational controls, not one-time setup tasks.

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. A compromise in one subsystem can affect others if identity boundaries are too broad. That is why device identity, update integrity, and internal network segmentation all have to be governed together.

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. That creates a path for spoofed or tampered software to reach embedded systems. In practice, it turns software delivery into a trust assumption instead of a controlled security decision.

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.

Technical breakdown

Why connected cars need certificate-backed identity

A connected car is not a single system but a network of onboard computers, external services, and update channels that all need to trust each other. PKI provides that trust through certificates issued by a certificate authority, allowing one system to verify another before exchanging data or accepting an action. In this model, authentication is not just a login event. It is the mechanism that prevents spoofing, unauthorised command injection, and tampering across the car's internal and external communications.

Practical implication: Treat every vehicle-facing communication path as an identity problem, not just a network segmentation problem.

How code signing protects software updates in vehicles

Code signing turns software updates into verifiable artefacts by binding them to a trusted signer. The vehicle only accepts the update if the signature checks out, which helps stop malicious or altered firmware from reaching embedded systems. That is especially important in connected cars because software updates can touch entertainment systems, remote access functions, and safety-related components. Without signed updates, the vehicle cannot reliably distinguish manufacturer-authored code from attacker-controlled code.

Practical implication: Require signed update chains and verify that the signing trust root is governed like any other high-risk credential.

Why internal vehicle networks still need identity governance

The article notes that cars contain dozens of onboard computers and that some components, such as infotainment or Bluetooth systems, can become a foothold into more sensitive internal modules. That is an identity boundary problem as much as an access problem. Once a peripheral system is trusted too broadly, lateral movement inside the vehicle becomes possible. PKI reduces that risk by giving each system a way to prove its identity and limit who can talk to what, but only if certificate scope matches the real trust boundary.

Practical implication: Map certificate scope to actual in-vehicle trust boundaries so peripheral compromise cannot automatically become safety-critical access.

Threat narrative

Attacker objective: The attacker wants to use a weakly trusted connected-car component to reach vehicle functions that affect safety, convenience, or broader organisational systems.

1. Initial access can begin through a peripheral connected-car system such as infotainment or Bluetooth, where the article warns that exposed components may become a foothold into the vehicle.
2. From there, an attacker can exploit weak authentication or missing verification between onboard systems and move from a lower-trust module toward more sensitive functions.
3. The impact is potential control over remote unlock, start functions, or even safety-critical ECUs, which turns a digital compromise into physical risk.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Certificate-backed trust is the only scalable answer when the asset itself is a moving endpoint. A vehicle cannot rely on a human-mediated trust decision every time it exchanges data or accepts an update. PKI creates a repeatable, verifiable trust layer that works at machine speed and across billions of devices. For security teams, that means the certificate lifecycle becomes part of the operational security model, not a back-office crypto task.

Code signing is necessary but insufficient unless the signing trust chain is governed as an identity lifecycle. The article correctly treats signed updates as a core safeguard, but signed code only remains trustworthy if keys, certificates, and issuing authorities are controlled throughout their lifecycle. This is where many IoT and device programmes fail: they protect distribution but under-govern the identity that authorises the distribution. The practitioner implication is to govern signing authority with the same rigour as any privileged machine credential.

Identity blast radius: A connected car becomes dangerous when a low-trust subsystem can be used to inherit trust across the vehicle network. That is the governance concept this article surfaces most clearly. When infotainment, telematics, and safety-critical ECUs are not separated by tightly defined identity boundaries, one compromised component can expand the effective trust zone. The conclusion for practitioners is that trust scope, not just encryption, determines whether compromise stays local or becomes systemic.

Automotive PKI validates the direction of machine identity governance, but it also exposes how immature many device programmes still are. The article assumes an environment where identity can be issued, verified, and enforced across embedded systems at scale. That is the right model, but most organisations still lack equivalent discipline across certificates, signing keys, and offboarding of device trust. The practitioner implication is to align IoT and device identity programmes with the same lifecycle controls used for other high-risk machine identities.

From our research library:

• 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.

What this signals

Connected vehicle programmes should now be treated as identity programmes with physical consequences. Once onboard systems, telematics, and update channels all depend on trust relationships, certificate lifecycle governance becomes part of the core security operating model rather than a specialist crypto task.

Identity blast radius: The most important design question is no longer whether the vehicle encrypts traffic, but how far trust can spread once one subsystem is compromised. Practitioners should constrain that spread with narrow certificate scope, strong signing governance, and explicit separation between low-trust and safety-critical systems.

For practitioners

• 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.
• Separate low-trust and safety-critical systems Design in-vehicle networks so infotainment, Bluetooth, telematics, and safety-critical ECUs do not share broad trust relationships that let one compromise propagate laterally.

Key takeaways

• Connected cars expand the security problem from isolated endpoints to distributed machine identities that must prove themselves before they can communicate or update.
• PKI matters because it gives vehicles a way to verify source, integrity, and trust across software delivery and in-vehicle communications.
• The real governance issue is certificate lifecycle and trust scope, because weak identity boundaries can let a compromise spread from convenience systems to safety-critical controls.

Key terms

• Certificate Authority Services: Certificate Authority Services are the trust services that issue and manage digital certificates for users, applications, and machines. They anchor encrypted communication by proving identity and supporting certificate lifecycle controls such as issuance, renewal, revocation, and validation across enterprise systems.
• Code signing: Code signing is the process of attaching cryptographic proof to software so recipients can verify origin and integrity. In CI/CD, it turns release trust into an enforceable control instead of a human promise, and it only works when the signing step is mandatory and protected.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.