How should automotive and IIoT teams implement device identity and code signing across connected vehicle systems?

Teams should treat every ECU, update path, and external connection as part of one trust boundary. Use PKI to issue verifiable device identities, sign firmware and software before installation, and automate certificate lifecycle management so compromised or obsolete identities can be revoked quickly. The goal is not just authentication, but a control plane that can scale from manufacturing through end of life.

How device identity and code signing fit together in connected vehicle systems

device identity and code signing solve different parts of the same trust problem. Identity proves what an ECU, gateway, or update service claims to be. Code signing proves that firmware or software came from an approved source and was not altered. In connected vehicles and industrial IoT, both are needed because trust must survive manufacturing, field updates, service operations, and decommissioning.

That means teams should design identity and signing as a single control plane, not as separate projects. The most useful pattern is a verifiable device identity anchored in PKI, paired with signed software delivery and validation at install or boot. NHIMG’s Machine Identity, PKI and Certificate Lifecycle Guide is a good reference point for the lifecycle side of that design, because expiry, renewal, and revocation are part of the security model, not an afterthought.

In practice, this also means distinguishing device identity from artifact identity. A certificate can authenticate a device or service, while a signature vouches for a specific software image or update package. The control fails if either one is treated as static or manually managed. Connected vehicle environments have long lifetimes, intermittent connectivity, and many parties touching the platform, so lifecycle automation matters as much as the cryptography itself. See also SPIFFE workload identity specification for the broader pattern of cryptographically verifiable identity in machine-to-machine systems.

What teams need to engineer into the manufacturing-to-field lifecycle

The operating model should begin with identity issuance at manufacturing or first provisioning, continue through secure update delivery, and end with fast revocation when hardware is retired, compromised, or repurposed. If the environment uses multiple ECUs, suppliers, and regional service channels, the identity system must tolerate fragmented connectivity without losing assurance. That usually means short-lived or renewable certificates, hardware-backed key protection where feasible, and clear ownership of who can mint, renew, or revoke trust.

Code signing needs the same lifecycle discipline. Keys must be protected from build systems, update pipelines, and supplier handoffs, because the real attack surface is often the release process rather than the vehicle itself. Connected vehicle teams should also decide where verification happens, for example at download, at install, at boot, or at multiple points. The more safety-critical the component, the less acceptable it is to defer validation until the next restart or maintenance window.

NHIMG’s NHI Lifecycle Management Guide is relevant here because the same lifecycle discipline applies to machine identities that must be provisioned, rotated, and retired without drift. For software provenance and artifact integrity, a useful external baseline is the ISO/IEC 27002:2022 Information Security Controls guidance on implementation discipline, and the CSA Cloud Controls Matrix also maps well when build, signing, and delivery processes span cloud services.

Where connected vehicle teams usually get this wrong

The most common failure is to secure the endpoint but not the ecosystem around it. If manufacturing keys, build-signing keys, update servers, diagnostic tools, and field service access all share weak governance, then a strong on-device signature check will not stop compromise. Another common mistake is allowing identities to become effectively permanent. Long-lived certificates, shared signing keys, and weak inventory make revocation slow and uncertain, which turns a control into paperwork.

Teams also underestimate cross-supplier risk. Vehicle platforms often depend on tiered vendors, contract manufacturers, and remote maintenance channels, so the signing authority and the identity authority may sit in different organisations. That creates pressure to trust external tooling, external code, or externally managed certificates without enough inspection. NHIMG’s SolarWinds supply chain compromise is a reminder that software provenance failures can scale very quickly once a trusted release path is abused. For the identity side, OWASP Non-Human Identity Top 10 and NIST SP 800-63 Digital Identity Guidelines both reinforce the value of explicit lifecycle, assurance, and trust establishment rather than assumed identity.

Risk and Threat Considerations

Connected vehicle identity and signing failures are high impact because they can create a trusted path for malicious code, unauthorized updates, or silent long-term persistence. A weak revocation model can leave stolen or obsolete identities usable far beyond the point where the organisation thinks they have been disabled.

Failure mechanism: Attackers target signing keys, update infrastructure, supplier build pipelines, or service credentials so that malicious firmware or software appears legitimate to vehicles and gateways.

Impact: Compromise can spread at fleet scale, affecting safety, availability, confidentiality, and downstream maintenance trust. The same weakness can also prevent rapid containment because revoked identities or bad artifacts may still be accepted by poorly managed validation paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers lifecycle control for certificates and signing credentials used across devices and update systems.
	IA-9 — Service Identification and Authentication	Applies where devices, gateways, and update services authenticate machine-to-machine across the vehicle stack.
	SC-12 — Cryptographic Key Establishment and Management	Directly supports PKI, signing keys, and trust-anchor management for code signing and device identity.
Recommendation — Automate issuance, rotation, and revocation of signing and device-authenticating credentials. Enforce mutual authentication for ECU, gateway, and update-service communications. Protect signing keys and trust anchors with controlled key establishment and lifecycle management.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	Supports cryptographic protection of device identities and signed software in connected systems.
Recommendation — Define and operate cryptographic controls for signing, identity, and trust-anchor protection.

Practitioner Guidance

What to verify: Confirm that every trust decision has an explicit owner, an auditable key or certificate lifecycle, and a clear revocation path. If a team cannot prove where keys live, who can sign, and how verification is enforced on the device, the control is not ready for production.

Decision rule: If a certificate or signing key can affect production vehicles, treat it as a fleet-level security asset and protect it with the same rigor as privileged access. If the signing path is shared across suppliers, require additional segregation and independent verification before release.

Practitioner takeaway: The goal is not merely to authenticate devices or sign binaries, but to make trust revocable, observable, and durable across the full vehicle lifecycle.