PKI is the trust layer IoT authentication still depends on

At a glance

What this is: This is an analysis of why PKI remains central to IoT authentication and device trust, with the core finding that scalable identity and certificate management is the control plane for connected devices.

Why it matters: It matters because IoT programmes collapse without provable device identity, and the same lifecycle, credential, and access-governance lessons apply to NHI, autonomous systems, and human-facing trust chains.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read DigiCert's post on PKI for IoT device authentication

Context

PKI in IoT is the problem of proving that a device, service, or user is allowed to communicate before data starts moving. In practice, that means device identity, certificate issuance, trust anchors, and revocation all have to work at machine scale, or the connected environment becomes easy to spoof, hijack, or misroute.

The identity security question is bigger than certificates alone. IoT programmes inherit the same governance pressure seen in NHI environments: discovery, provisioning, rotation, expiration, and offboarding determine whether device trust is durable or temporary, and whether security teams can actually govern the fleet rather than merely observe it.

For teams running connected medical devices, industrial systems, or platform services, the key issue is not whether PKI is familiar. It is whether certificate lifecycle management is treated as an operational control, with visibility and automation strong enough to keep pace with device growth and cross-platform deployment.

Key questions

Q: How should security teams authenticate IoT devices at scale?

A: Use PKI with per-device certificates, centralized issuance, and automated renewal so authentication does not rely on shared secrets or manual provisioning. The control objective is to make device identity verifiable across cloud, edge, and embedded environments while preserving revocation and monitoring as normal operational functions.

Q: Why do IoT programmes need certificate lifecycle management?

A: Because device identity is only useful if it can be discovered, rotated, renewed, and revoked on time. Without lifecycle management, certificates outlive the devices and services they protect, leaving stale trust in place and creating a long tail of exposure that scales with fleet growth.

Q: What breaks when connected devices use weak authentication?

A: Attackers can impersonate devices, tamper with messages, suppress alarms, or move from one trusted system to another through a compromised trust relationship. In IoT, weak authentication is not just an access problem. It can become an operational and physical safety problem.

Q: How do certificate management failures affect Zero Trust for IoT?

A: Zero Trust depends on strong, verifiable identity at the point of access. When certificates are expired, misconfigured, or untracked, policy decisions become unreliable because the platform cannot tell whether a device is legitimate. That undermines continuous verification and weakens the entire trust model.

Technical breakdown

Why PKI fits IoT authentication better than shared secrets

PKI gives each device a unique cryptographic identity instead of a shared password or static key. That matters in IoT because fleets are heterogeneous, long-lived, and often distributed across cloud, edge, and embedded systems. A certificate binds identity to a private key and lets systems authenticate without exposing reusable secrets in transit. The architecture also supports encryption and trust chaining across protocols, which is why it scales better than manual credential models when millions of devices need consistent, verifiable access.

Practical implication: replace shared secrets with per-device certificates wherever identity assurance must survive scale and device turnover.

Certificate lifecycle management is the real control surface

The article’s central technical point is that IoT trust depends on lifecycle handling as much as on issuance. Discovery identifies what exists, provisioning assigns trusted credentials, monitoring checks expiry and configuration, and revocation removes trust when a device is retired or compromised. If any one of those steps is weak, the environment accumulates stale trust. That is a classic machine identity problem: credentials remain valid longer than the business relationship or security posture that justified them.

Practical implication: manage certificates as living identities, not one-time setup artifacts, and tie them to inventory and revocation workflows.

How PKI supports multi-protocol, cross-platform IoT estates

IoT deployments often mix public Internet services, private networks, edge devices, and manufacturing systems. PKI works across those boundaries because it is an open standard that can be applied consistently even when the underlying protocols differ. The article points to centralized certificate management, OCSP checking, and API-driven administration as the operational layer that makes this feasible. The architectural goal is trust portability: the same identity model should work whether the device is talking to a cloud service, an internal platform, or another embedded system.

Practical implication: standardise certificate management across platforms so identity controls do not fragment as devices move between environments.

Threat narrative

Attacker objective: The attacker seeks to exploit weak device identity to control communications, manipulate operational data, or disrupt critical connected systems.

1. Entry occurs when a connected device or industrial system lacks strong authentication and can be impersonated or reached through weak trust controls.
2. Escalation occurs when trusted communications, once established, can be abused to alter data in transit, suppress alarms, or extend control beyond the intended device boundary.
3. Impact occurs when attackers use compromised device trust to disrupt operations, endanger patients, or trigger physical and business consequences at scale.

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 control plane for IoT, not just an encryption feature. The article correctly frames the problem as one of trust, because connected devices need verifiable identity before they can be allowed to speak, act, or exchange data. In NHI terms, certificates are not auxiliary protection. They are the mechanism that lets security teams distinguish legitimate devices from impersonation at machine scale. Practitioners should treat PKI as core identity infrastructure, not a crypto add-on.

Device trust fails when lifecycle governance is weaker than device growth. IoT environments expand faster than manual certificate administration can keep up, which means expiration, revocation, and provisioning become the actual failure points. That maps directly to NHI lifecycle governance: if teams cannot inventory devices, rotate credentials, and remove trust when devices change state, the environment accumulates stale access. The practical conclusion is that lifecycle discipline determines whether PKI is operational or merely theoretical.

Certificate sprawl creates an identity blast radius that is easy to underestimate. The more devices and protocols a programme supports, the more trust anchors, issuance paths, and monitoring points it has to govern. That broadens the attack surface in the same way excessive NHIs do in enterprise environments. The named concept here is certificate lifecycle drift: certificates remain valid in places where the organisation no longer has clear operational ownership. Practitioners should expect the blast radius to grow unless trust inventories are maintained continuously.

IoT authentication exposes the same governance gap seen across service accounts and workload identity. The article’s emphasis on scalability mirrors a broader identity pattern: machine identities outlive projects, devices, and sometimes business units, unless lifecycle controls are explicit. That is why PKI, NHI governance, and asset management must be designed together rather than as separate programmes. Teams that split those responsibilities usually end up with trusted devices no one can fully account for.

Zero Trust for connected devices depends on provable identity, not network location. The article’s focus on authenticating every device aligns with the zero-trust premise that trust must be continuously verified. In connected environments, that means identity must travel with the device across networks, manufacturing stages, and deployment contexts. The practitioner conclusion is straightforward: if a device cannot prove who it is, zero-trust policy cannot safely decide what it may do.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly machine identity oversight degrades when environments scale beyond manual control.
• For a broader view of lifecycle risk, see Ultimate Guide to NHIs , Key Research and Survey Results, which maps the visibility and rotation gap across enterprise identity programmes.

What this signals

Certificate lifecycle drift: as connected estates grow, the real risk is not initial issuance but the point where devices, services, and certificates stop sharing the same owner or lifecycle state. Teams that cannot prove inventory, renewal, and revocation for each trust anchor will eventually inherit stale access that no policy review can clean up after the fact.

The IoT lesson extends beyond embedded systems. Any programme that manages machine identities through fragmented ownership will see the same pattern: trust expands faster than governance, and the first symptom is usually an expired or orphaned credential rather than an obvious breach. That is why certificate operations and identity governance now need to be treated as one control domain.

For practitioners, the next maturity step is to connect PKI administration to identity inventory and operational risk reporting. When certificate state is visible alongside device ownership and business criticality, teams can finally prioritise which trust failures matter most instead of reacting to every expiry as a separate event.

For practitioners

• Inventory device identities before expanding PKI rollout Build a complete register of connected devices, services, and certificate-bearing systems so discovery and provisioning are tied to known assets rather than ad hoc enrollment.
• Automate certificate lifecycle events Tie issuance, renewal, expiration alerts, and revocation to platform workflows so certificates do not outlive the devices or services they protect.
• Separate trust by device class and environment Use distinct policies for medical devices, industrial systems, edge services, and public-facing endpoints so one compromise does not imply universal trust.
• Monitor for expired or misconfigured certificates continuously Track expiration, unauthorized certificates, and configuration drift in the same operational view so stale trust is detected before it becomes an outage or intrusion path.

Key takeaways

• PKI remains the strongest scalable model for IoT authentication because it gives each device a verifiable identity instead of relying on reusable secrets.
• The main failure mode is lifecycle drift, where certificates outlive the devices and services they were meant to protect and create stale trust.
• Practitioners should treat device identity, certificate operations, and asset inventory as one governance problem, not three separate teams' responsibilities.

Key terms

• Public Key Infrastructure: Public Key Infrastructure is the system used to issue, manage, and validate digital certificates that bind an identity to a cryptographic key. In IoT, PKI lets organisations authenticate devices at scale without relying on shared secrets, while also supporting encryption and revocation across diverse platforms.
• Machine Identity: Machine identity is the set of credentials and trust attributes that lets a non-human system prove who it is to another system. In connected environments, it usually takes the form of certificates, keys, or tokens that must be provisioned, monitored, and retired like any other identity.
• Certificate Lifecycle Management: Certificate lifecycle management is the operational control of issuing, renewing, monitoring, and revoking certificates over time. It is the difference between one-time trust setup and durable governance, because certificates that are not tracked and retired correctly become stale access paths.
• Device Trust: Device trust is the assurance that a connected device is genuine, authorised, and operating within expected boundaries. In IoT, trust must be continuously maintained through identity verification and lifecycle controls, not assumed because a device is already on the network.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.

This post draws on content published by DigiCert: PKI: Solving the IoT Authentication Problem. Read the original.