PKI is the missing trust layer for connected car security

At a glance

What this is: This is a DigiCert blog post arguing that connected car security depends on PKI-backed device identity, code signing, and encryption.

Why it matters: It matters because automotive environments now behave like large fleets of networked endpoints, and IAM teams can apply the same trust, certification, and lifecycle discipline they use for machine identities.

By the numbers:

• Roughly a quarter billion connected cars will be on our roads by 2020.

👉 Read DigiCert's analysis of PKI for connected car security

Context

Connected car security is a trust problem before it is a transport problem. Each vehicle contains multiple onboard systems that exchange data with external services, so the core question is how to prove that software, updates, and telemetry come from a trusted source.

That makes automotive security an identity issue as much as a device issue. The article treats the car as another networked endpoint, which means certificate lifecycle, code signing, and authenticated communication become the controls that matter most for machine trust.

The starting position described here is typical of connected environments: innovation has expanded faster than a common security model, leaving the industry with many connected vehicles and no durable consensus on how to secure them.

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 vehicles create machine identity risk?

A: Connected vehicles behave like distributed machine environments because dozens of onboard systems exchange data with external services and may be targeted through peripheral interfaces. Once that happens, identity, signing, and lifecycle controls matter more than traditional device perimeter thinking. The risk grows when trust is implicit rather than certificate-backed.

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: Who is accountable for certificate lifecycle in connected vehicle security?

A: The teams operating the vehicle platform, its update pipeline, and its connected services are accountable for certificate issuance, renewal, revocation, and retirement. If those responsibilities are unclear, trust persists after ownership changes and attack paths remain open. Lifecycle ownership is part of the security model, not a back-office detail.

Technical breakdown

Why code signing matters for connected vehicle software

Code signing attaches a cryptographic proof to software so the receiving system can verify that the update originated from a trusted issuer and has not been modified in transit. In connected cars, that matters because software reaches the vehicle over external channels and can affect both infotainment and safety-adjacent systems. Public Key Infrastructure gives the car a way to trust the signer without trusting the network path. It also creates a revocation and certification model that is more durable than informal device checking.

Practical implication: require signed firmware and signed over-the-air updates before any vehicle software change is accepted.

How PKI separates trust from network reachability

PKI uses a certificate authority to issue certificates that bind identity to a device, service, or component. That identity proof lets systems encrypt traffic, authenticate peers, and resist spoofing even when communications cross untrusted networks. In the article’s model, this matters because the vehicle is not a single endpoint but a set of communicating systems, some of which must be isolated from others. The trust decision therefore shifts from network location to cryptographic identity.

Practical implication: anchor vehicle-to-cloud and vehicle-to-vehicle trust on certificates rather than IP-based trust assumptions.

Why compartmentalisation inside the vehicle still needs identity controls

The article notes that vehicle controls should be separated from infotainment systems. That separation reduces lateral movement, but it does not solve trust by itself because each subsystem still needs to prove who it is talking to and whether commands are authentic. In practice, internal segmentation and certificate-backed identity work together. Without both, a compromise in one peripheral system can still become a pathway to more sensitive components.

Practical implication: pair in-vehicle segmentation with authenticated component identity so one compromised subsystem cannot impersonate another.

Threat narrative

Attacker objective: The attacker aims to move from convenience features into trusted vehicle functions and ultimately compromise data, control, or safety.

1. Entry occurs when an attacker reaches a connected car through a vulnerable peripheral system such as infotainment or another externally reachable interface.
2. Escalation follows when the attacker abuses the trust gap between loosely connected vehicle systems and moves from the peripheral component toward more sensitive internal functions.
3. Impact occurs when unauthenticated or unsigned commands reach systems that can expose personal data, alter vehicle behaviour, or affect safety-critical operations.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Connected cars expose an identity problem disguised as a device problem. The article is correct to focus on PKI because the real issue is not connectivity alone but verifiable trust between many independently communicating systems. When vehicles exchange updates, commands, and telemetry across external networks, certificate-based identity becomes the minimum control that lets security teams distinguish authorised communication from spoofed traffic. Practitioners should treat connected vehicles as machine identities with lifecycle obligations, not as static hardware assets.

Code signing is the governance control that keeps software trust auditable. A vehicle update pipeline without signing turns software provenance into an assumption instead of a proof. That breaks the chain of accountability between the software producer, the delivery path, and the vehicle receiving the update. In identity terms, the update itself becomes the credential. Practitioners should evaluate whether every vehicle software path has a verifiable issuer, revocation path, and certificate lifecycle behind it.

In-vehicle segmentation only works when the subsystems have authenticated identities. Separating infotainment from control systems reduces blast radius, but the boundary remains porous if internal components can be impersonated or if trust is granted by network placement alone. That is why automotive security cannot stop at segmentation. The practical conclusion is that every internal interface with security relevance needs cryptographic identity, not just perimeter isolation.

PKI is the closest thing connected cars have to an identity governance layer. It gives operators a way to issue, validate, and retire trust for devices and embedded components over time, which is the same lifecycle challenge seen in broader machine identity programmes. The post’s strongest implication is that automotive security will keep failing wherever teams treat certificates as a narrow technical feature instead of a governed identity control. Practitioners should manage vehicle trust as an identity lifecycle, not as a one-time integration.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is a reminder that unmanaged machine trust is usually a visibility problem before it becomes an incident.
• For connected vehicle programmes, the next step is to examine Ultimate Guide to NHIs , The NHI Market for the broader governance model behind machine identity.

What this signals

Identity lifecycle is the missing discipline in connected device security. Automotive teams often discuss encryption and code signing, but the harder problem is ownership across issuance, rotation, revocation, and retirement. Once a vehicle or embedded component has a certificate, someone must be responsible for its lifecycle, or trust will outlive the context that created it.

That is why connected-car governance increasingly overlaps with machine identity management. Programmes that already manage service accounts, API keys, or workload certificates can apply the same operating model here, but they need stronger inventory discipline and clearer revocation triggers.

The useful next question is not whether PKI works in principle. It is whether the organisation can prove that every vehicle credential is visible, owned, and retired on a schedule that matches the asset’s real exposure window.

For practitioners

• Define certificate-backed trust for every vehicle interface Map which vehicle-to-cloud, vehicle-to-vehicle, and internal subsystem exchanges require authenticated identity, then require certificates or equivalent cryptographic proof before allowing communication.
• Require signed firmware and authenticated over-the-air updates Block any software delivery path that cannot prove source integrity, and make signature verification part of the acceptance logic in the vehicle update pipeline.
• Treat vehicle components as managed machine identities Assign ownership, renewal, revocation, and retirement responsibilities for certificates used by embedded systems, telemetry services, and external integrations.
• Separate network segmentation from trust policy Use internal partitioning to reduce blast radius, but do not rely on network location as proof of identity. Require authenticated peers before sensitive commands are accepted.

Key takeaways

• Connected cars are security-sensitive identity systems, not just connected products.
• PKI, code signing, and authenticated communication are the controls that make vehicle trust verifiable.
• Practitioners should manage vehicle certificates with the same lifecycle discipline they apply to other machine identities.

Key terms

• Public Key Infrastructure: Public Key Infrastructure is the trust framework that uses certificate authorities and certificates to bind identity to a device or service. In connected systems, it lets organisations authenticate peers, encrypt traffic, and verify software provenance without trusting the network itself.
• Code Signing: Code signing is the practice of attaching a cryptographic signature to software so the recipient can verify who produced it and whether it has been altered. In vehicle environments, it is a control for update integrity and trusted execution, not just a software release formality.
• Machine Identity: Machine identity is the cryptographic identity assigned to a non-human system such as a device, service, or embedded component. For connected cars, it covers certificates and related trust artifacts that prove which subsystem is communicating and whether that identity is still valid.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Connected Cars Need a Security Solution: Use PKI. Read the original.