Security teams should govern IoT device certificates with a single lifecycle process for issuance, renewal, revocation, and retirement. The practical test is whether every device identity is visible enough to be renewed before expiry and revoked when the device leaves service. If not, certificate management has become an uptime risk as well as a security risk.
Why This Matters for Security Teams
IoT device certificates are not a one-time provisioning task. They are the device’s operational identity, and once deployed at scale they become a lifecycle problem involving issuance, renewal, revocation, inventory, and retirement. That is why certificate governance needs to be treated as an identity control, not a device admin convenience. NIST Cybersecurity Framework 2.0 frames this as an asset, access, and resilience issue, not just a cryptographic one.
The practical risk is that certificate expiry can stop telemetry, disable control channels, or trigger fleet-wide outages before anyone notices. NHI guidance from NHI Management Group shows why lifecycle discipline matters: the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs connects identity visibility to renewal and retirement, while Ultimate Guide to NHIs — Regulatory and Audit Perspectives highlights the audit pressure that follows when ownership is unclear. In practice, many security teams encounter certificate failures only after devices have already gone offline, rather than through intentional renewal planning.
How It Works in Practice
Effective IoT certificate governance starts with a complete inventory of devices, their certificate authorities, issuance dates, expiry dates, and business owners. Without that baseline, renewal becomes guesswork. The next step is to automate the certificate lifecycle so devices can be renewed before expiry and revoked immediately when they are decommissioned, lost, or compromised. This is consistent with the identity governance discipline described in NIST CSF 2.0 and with the operational emphasis in the Top 10 NHI Issues.
At scale, good practice usually includes:
- Unique certificates per device, not shared credentials across a fleet.
- Short validity periods with automated renewal workflows.
- Central policy for issuance and revocation, with local enforcement at device enrollment.
- Clear ownership records so expired or retired devices can be traced quickly.
- Monitoring for certificate age, failed renewals, and orphaned identities.
Security teams should also align certificate controls with operational recovery. If a renewal fails, there should be a safe fallback path that preserves service continuity without extending certificate lifetimes indefinitely. That balance matters because IoT fleets often include constrained devices, offline devices, and legacy embedded systems that cannot support modern automation cleanly. The State of Non-Human Identity Security notes that only 38% of organisations have automated certificate lifecycle management in place, which helps explain why manual tracking still creates so much exposure. These controls tend to break down when devices are intermittently connected and cannot complete renewal before their certificate TTL expires.
Common Variations and Edge Cases
Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger identity assurance against device uptime and maintenance constraints. That tradeoff is most visible in factories, utilities, retail fleets, and medical environments where devices may be offline for long periods or have limited local storage and compute. Current guidance suggests that these environments need exception handling, not exception-free policy.
Best practice is evolving around several edge cases. Shared certificates should be eliminated where possible, but some legacy platforms cannot support per-device identity without firmware changes. Revocation is also not always straightforward: if a device cannot reliably reach revocation infrastructure, teams may need layered controls such as network segmentation, certificate pinning, and aggressive short TTLs. For compliance and audit, the key question is not whether every device is perfect, but whether the organisation can prove who owns it, when it expires, and how it will be retired. The Critical Gaps in Machine Identity Management report is a useful benchmark for the scale of this problem. In practice, the hardest failures appear when old devices, manual spreadsheets, and incomplete inventories meet a certificate expiry event at the same time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle and rotation failures that make device certificates expire or persist too long. |
| NIST CSF 2.0 | ID.AM-1 | Device certificate governance depends on accurate asset inventory and ownership visibility. |
| NIST CSF 2.0 | PR.AA-1 | Certificates are the device authentication mechanism and must be managed as such. |
Automate certificate issuance, renewal, and retirement, and remove any device credential that cannot be tracked end to end.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
