How do organisations know whether IoT certificate management is actually working?

Why This Matters for Security Teams

Certificate management is only “working” when it keeps device trust continuous without creating hidden operational debt. For IoT fleets, the real test is not whether certificates exist, but whether every device can be inventoried, renewed, revoked, and audited at scale. The gap usually appears when teams rely on manual tracking, exception handling, or after-hours renewal playbooks that do not survive growth.

NHI Management Group’s research on machine identity management found that only 38% of organisations have automated certificate lifecycle management in place, while 57% lack a complete inventory of machine identities in the first place. That matters because an incomplete inventory makes every renewal metric misleading. If the control plane cannot see the device, it cannot prove the certificate state. Current guidance from NIST Cybersecurity Framework 2.0 and SailPoint research on machine identity gaps both point to the same operational reality: visibility, automation, and evidence must move together.

In practice, many security teams discover certificate failure only after an expiry event, not through a deliberate assurance model.

How It Works in Practice

Organisations should evaluate certificate management as a lifecycle control, not a point-in-time issuance task. The core question is whether the programme can continuously prove coverage, renewal success, and revocation hygiene across every IoT device class. That means each device needs a verified identity record, a known certificate authority path, a defined renewal trigger, and audit evidence that renewal happened before expiry. When this is done well, operators can see whether certificates are short-lived, rotated automatically, and tied to the actual device workload rather than a static spreadsheet entry.

A practical operating model usually includes:

• complete device inventory mapped to certificate ownership and renewal policy
• automated renewal workflows with measurable success and failure rates
• expiry monitoring that flags risk days or weeks ahead of deadline
• revocation records that show when compromised or retired devices lost trust
• audit trails that link each certificate to a device class, policy, and approver

That is consistent with the control intent in NIST SP 800-53 Rev. 5, especially where organisations need evidence for access control, system integrity, and configuration management. It also aligns with the lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which frames machine identity governance as a continuous process rather than a one-time rollout. For operational validation, many teams now track renewal automation rate, inventory completeness, certificate-related outage frequency, and the percentage of exceptions that remain open past their expiry window. These controls tend to break down when IoT devices are offline for long periods, cannot be updated remotely, or rely on vendor-owned firmware that prevents standard renewal automation.

Common Variations and Edge Cases

Tighter certificate control often increases operational overhead, requiring organisations to balance stronger trust continuity against device constraints and maintenance windows. That tradeoff is especially visible in IoT environments where devices are intermittently connected, deployed in unsafe physical locations, or embedded in industrial systems that cannot tolerate frequent reconfiguration.

Best practice is evolving for mixed fleets. Some devices can support short-lived certificates and automated rotation; others require staggered renewal windows or brokered identity services because they cannot safely call home on demand. In those cases, the security team should still measure whether exceptions are shrinking over time, whether compensating controls are documented, and whether certificate age is bounded by policy rather than convenience. The presence of exceptions is not failure by itself. The problem is unmanaged exceptions that bypass auditability.

This is where the most meaningful indicators become simple: zero unknown devices, no surprise expiries, clear ownership for each certificate class, and evidence that revocation is as automated as issuance. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful for translating that evidence into audit language, while NHI Lifecycle Management Guide helps teams define what “managed” should mean across onboarding, rotation, and retirement. The approach becomes less reliable when legacy IoT estates mix multiple certificate authorities, undocumented ownership, and manual renewal approvals in the same workflow.

Related resources from NHI Mgmt Group

• How do organisations know whether NHI lifecycle management is actually working?
• How do organisations know whether certificate-based sign-in is actually working?
• How do organisations know whether their access management controls are actually working?
• How can organisations know whether Linux IoT security controls are actually working?