IoT device security depends on PKI across the device lifecycle

At a glance

What this is: This is an IoT device security analysis arguing that PKI and digital certificates should be embedded across the device lifecycle to support authentication, integrity, confidentiality, and secure updates.

Why it matters: It matters because IoT programmes, like NHI and broader identity work, fail when identity and trust are treated as add-ons instead of lifecycle controls.

👉 Read DigiCert's blog on IoT device security and PKI lifecycle controls

Context

IoT device security is the discipline of making connected devices authentic, tamper-resistant, and manageable across their full lifecycle. The article argues that public key infrastructure, digital certificates, and device identity should be part of design and manufacturing, not bolted on after deployment.

The security gap is familiar to identity teams: if a device cannot prove who it is, cannot receive updates securely, and cannot be distinguished from a counterfeit endpoint, the rest of the control stack is weakened. That makes IoT a lifecycle identity problem as much as a product security problem.

This is where the topic overlaps with broader NHI governance. Devices, service identities, and machine credentials all need durable identity, controlled provisioning, and revocation-aware operations when trust is no longer static.

Key questions

Q: How should security teams govern device identity in IoT fleets?

A: Security teams should govern IoT device identity with the same discipline they use for other machine identities: unique credentials, controlled issuance, monitored renewal, and explicit retirement. The goal is to make each device cryptographically provable, operationally traceable, and removable when the asset is no longer trusted.

Q: Why do IoT devices need certificates instead of shared secrets?

A: Certificates give each device a verifiable identity and support mutual authentication, while shared secrets are easier to copy, reuse, and expose at scale. In large IoT estates, certificate-based trust also makes it easier to separate authentic devices from clones, counterfeit endpoints, or compromised units.

Q: When does secure boot matter most for connected devices?

A: Secure boot matters whenever a device could be physically accessed, remotely updated, or deployed in an environment where attackers can tamper with firmware or configuration. It prevents untrusted code from becoming the first thing the device executes, which is critical for high-longevity fleets.

Q: What should organisations review before rolling IoT devices into production?

A: They should review how identity is issued, where certificates are stored, how updates are signed, and how revoked or retired devices are removed from trust relationships. If those answers are unclear, production deployment will expand the attack surface instead of controlling it.

Technical breakdown

How PKI establishes device identity in IoT environments

PKI binds a device to a cryptographic identity by issuing certificates that can be verified by cloud services, manufacturing systems, or update servers. In practice, this lets the organisation distinguish a genuine device from a cloned or rogue one without relying on shared secrets alone. Certificates can also support mutual authentication, so both ends of a connection prove identity before data moves. In IoT programmes, that matters because device fleets are long-lived, heterogeneous, and often deployed in places where manual recovery is unrealistic.

Practical implication: treat device certificates as the base identity control for IoT fleets, not as an optional add-on after deployment.

Why secure boot and signed updates depend on certificate trust

Secure boot and signed firmware updates rely on a chain of trust that starts in hardware or firmware and extends to the code a device accepts later. If the device cannot validate the signer, the update channel becomes an attack path for malware, tampering, or counterfeit firmware. PKI supports this by allowing the device to verify that software came from an authorised source and was not altered in transit. That is why update integrity is an identity issue, not just a patching issue.

Practical implication: require cryptographic signing and verification for every firmware and configuration update path.

Why lifecycle provisioning matters more than one-time enrollment

IoT trust breaks when identity is created once and never governed again. Devices may be provisioned before manufacturing, during supply chain handling, or after deployment, but the same certificate and lifecycle controls need to govern each phase. That includes certificate issuance, renewal, monitoring, and retirement when devices are decommissioned or transferred. Without that lifecycle view, identity sprawl appears in the device estate just as it does in service accounts and other NHIs.

Practical implication: align provisioning, renewal, and retirement with a defined certificate lifecycle rather than one-off onboarding.

Threat narrative

Attacker objective: The attacker aims to impersonate legitimate devices or tamper with device communications, updates, or telemetry at scale.

1. Entry occurs when a device, update path, or cloud service cannot distinguish a genuine IoT identity from a counterfeit or compromised one.
2. Escalation follows when unauthenticated or weakly authenticated devices accept firmware, configuration, or service connections that were never cryptographically validated.
3. Impact is achieved when attackers gain persistent control over device behaviour, data integrity, or fleet-wide trust relationships.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

PKI is the identity layer IoT security cannot outsource. The article’s core point is that device security depends on proving device identity, not just protecting the network around the device. That aligns with OWASP-NHI thinking: a device that cannot authenticate itself and its updates is operating outside durable governance. Practitioners should treat cryptographic identity as foundational, not supplemental.

IoT security fails when trust is created once and never governed again. Certificates, provisioning choices, and update trust are lifecycle controls, and lifecycle is where IoT programmes usually drift. The failure mode is not only weak authentication but unmanaged identity persistence across manufacturing, deployment, and retirement. Practitioners should audit where device trust outlives the conditions that created it.

Secure updates are an identity problem disguised as a maintenance task. Signed firmware, secure boot, and device authentication are all expressions of the same control expectation, which is that only authorised software should run on authorised hardware. When that expectation is missing, update channels become a privileged attack surface. Practitioners should govern update identity with the same rigour they apply to NHI credentials.

IoT device fleets should be governed like high-volume non-human identities. Every device, certificate, and service binding creates an entitlement footprint that must be monitored, rotated, and retired. The operational lesson is that fleet scale does not reduce governance needs; it raises them. Practitioners should design IoT trust as a managed identity programme, not as a one-time manufacturing feature.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
• From our research: 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%, according to The State of Non-Human Identity Security.
• That visibility gap is why lifecycle governance needs to extend from connected devices to certificates, service identities, and cloud trust relationships, as explored in 52 NHI Breaches Analysis.

What this signals

Device trust debt: when identity is embedded in hardware and firmware, every deferred renewal, missing revocation, or stale certificate becomes accumulated risk. Teams should expect IoT governance to converge with broader NHI lifecycle management because the same failure pattern repeats across devices, APIs, and service accounts.

The operational signal is not whether a device can connect, but whether it can still be trusted after topology changes, ownership changes, or software updates. That is where certificate lifecycle management becomes a control plane rather than an implementation detail.

For practitioners, the next step is to join device inventory, certificate inventory, and update integrity controls into one governance view, then measure exceptions instead of assuming the fleet is healthy.

For practitioners

• Bind device identity to cryptographic trust at provisioning Issue unique certificates or equivalent device identities during manufacturing or secure onboarding, and avoid shared credentials across fleets. Use enrollment workflows that can prove device authenticity before any cloud or update access is granted.
• Require signed firmware and verified update channels Make code signing mandatory for every software and configuration update path, and reject any update that cannot be verified against an authorised signer. This reduces the chance that a compromised channel becomes a fleet-wide persistence mechanism.
• Track certificate lifecycle from creation to retirement Monitor issuance, renewal, revocation, and decommissioning as a single lifecycle process so identity does not linger after a device is retired or reassigned. Tie this to asset inventory so dormant trust is visible before it becomes exposure.

Key takeaways

• IoT security fails when device identity is treated as a deployment detail instead of a lifecycle control.
• PKI, signed updates, and certificate governance address the specific trust problem that connected devices create at scale.
• Practitioners should connect provisioning, update integrity, and retirement controls so device trust can be proven and withdrawn.

Key terms

• Device Identity: A device identity is the cryptographic and operational proof that a connected device is the genuine asset it claims to be. In IoT environments, that proof is typically established with certificates, keys, and lifecycle controls that allow the device to authenticate, update, and communicate securely.
• Public Key Infrastructure: Public key infrastructure is the system for issuing, managing, and verifying digital certificates and the keys behind them. In IoT, it gives organisations a scalable way to authenticate devices, sign updates, and maintain trust across manufacturing, deployment, and retirement.
• Secure Boot: Secure boot is a startup control that ensures a device loads only trusted software at power-on. It protects the earliest execution path, which matters because a compromised boot chain can undermine every later control, including update verification and telemetry integrity.
• Certificate Lifecycle Management: Certificate lifecycle management is the process of issuing, renewing, monitoring, revoking, and retiring certificates in a controlled way. For IoT and other machine identities, it is the difference between durable trust and unmanaged credentials that linger beyond their intended use.

Deepen your knowledge

NHI governance, machine identity security, and workload 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 governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: This IoT Day, don’t forget to discuss device security. Read the original.