Why do IoT devices make certificate governance harder than server workloads?

Why This Matters for Security Teams

IoT certificate governance is harder than server certificate governance because the device estate behaves like a distributed identity population, not a controlled infrastructure tier. Devices ship with different chipsets, operating systems, boot constraints, and vendor update channels, so the usual assumptions behind server PKI break down quickly. NHI Management Group’s research on machine identity management shows how scale and visibility issues compound the problem, with The Critical Gaps in Machine Identity Management report highlighting that 57% of organisations lack a complete inventory of their machine identities.

That gap matters because certificates are only governable when ownership, renewal paths, and revocation handling are predictable. Server workloads often live in managed clusters with standardised automation, while IoT devices may be offline for long periods, sit behind field gateways, or run firmware that cannot safely tolerate frequent certificate changes. Guidance from the NIST Cybersecurity Framework 2.0 is helpful for risk management, but it does not remove the operational reality that many IoT fleets are physically exposed and operationally fragmented. In practice, many security teams encounter certificate expiry only after a remote device stops authenticating or a maintenance window has already closed, rather than through intentional lifecycle control.

How It Works in Practice

Effective IoT certificate governance starts by treating each device as a workload identity with a constrained lifecycle, not as a miniature server. The strongest pattern is to issue certificates automatically at provisioning, bind them to device identity, and renew them through device-safe channels before expiry. Where possible, use short-lived certificates, hardware-backed keys, and measured boot or attestation so the platform can verify what the device is and whether it is in a trusted state. The SPIFFE workload identity specification is useful here because it frames identity as cryptographic proof of workload or device presence, not just as a manually managed certificate file.

For IoT, the governance model also has to account for intermittent connectivity and constrained compute. A practical design usually includes:

• Automated enrollment at manufacturing, onboarding, or first boot.
• Central inventory of device identity, certificate issuer, expiry, and revocation status.
• Policy-based renewal windows that adapt to device uptime and network availability.
• Fallback revocation paths for lost, stolen, or decommissioned hardware.
• Segmentation so a single compromised certificate cannot laterally reach unrelated systems.

NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for aligning provisioning, rotation, and retirement with the identity lifecycle rather than with ad hoc device maintenance. The SailPoint research in The Critical Gaps in Machine Identity Management report also notes that 61% of organisations still rely on spreadsheets or manual tracking, which is a poor fit for fleets that cannot be renewed by hand at scale. These controls tend to break down when devices are offline for extended periods, because renewal and revocation depend on predictable check-in timing that many field devices cannot guarantee.

Common Variations and Edge Cases

Tighter certificate control often increases operational overhead, requiring organisations to balance stronger identity assurance against device uptime and support cost. That tradeoff is especially visible in IoT environments with long replacement cycles, vendor-locked firmware, or safety-critical functions where a failed renewal can interrupt production or monitoring.

Best practice is evolving for devices that cannot support modern rotation workflows. Some environments use long-lived certificates with compensating controls such as network isolation, attestation checks, and aggressive monitoring, but that approach should be treated as a risk acceptance decision rather than a mature state. Others rely on gateway-mediated trust, where the gateway holds the externally trusted certificate and the device authenticates to the gateway through a separate local mechanism. That can reduce certificate sprawl, but it also creates a concentration point that must be protected carefully.

Another edge case is decommissioning. IoT certificates are often harder to revoke than server certificates because devices may be lost, resold, or physically inaccessible. The Top 10 NHI Issues page covers why lifecycle failure is so common in machine identity programs, and the broader lesson applies here: if ownership and retirement are unclear, certificate governance becomes reactive. Organisations that operate mixed estates should separate guidance for cloud workloads, edge devices, and embedded systems rather than force one certificate policy across all of them.

Related resources from NHI Mgmt Group

• Why do shared devices make access governance harder?
• Why do AI agents make non-human identity governance harder?
• How can organizations secure their MCP server credentials?
• Why do non-human identities make privileged access governance harder?