Teams should govern IoT device identities as managed identities with explicit ownership, lifecycle states, and revocation processes. PKI is only the trust mechanism. The governance model must cover issuance, renewal, replacement, retirement, and audit evidence so that a valid certificate never becomes an unmanaged standing trust relationship.
Why This Matters for Security Teams
PKI gives IoT devices cryptographic proof of identity, but it does not by itself define ownership, acceptable use, or retirement. That gap is where certificate sprawl turns into unmanaged trust. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is a reminder that validity and governance are not the same thing. For IoT fleets, the practical risk is that a legitimate certificate can continue authorizing a device long after the device is lost, repurposed, or no longer trusted.
Security teams often over-focus on certificate issuance while under-defining lifecycle controls. A device certificate should be treated as a managed identity artifact with a named owner, inventory record, policy scope, and revocation path. The NIST Cybersecurity Framework 2.0 is useful here because it frames identity as an ongoing risk management problem, not a one-time onboarding step. In practice, many teams discover certificate risk only after a device is decommissioned without revocation, rather than through intentional identity governance.
How It Works in Practice
Effective IoT PKI governance starts with separating the trust mechanism from the identity control model. PKI validates that a device holds a key pair and a certificate chain, but governance decides who approved issuance, what the device may access, how long the certificate is valid, and when trust must end. Best practice is to bind each certificate to a managed asset record, an accountable owner, and a specific purpose such as telemetry, remote support, or firmware update access.
Operationally, teams should define lifecycle states that map to identity controls: requested, issued, active, suspended, replaced, and retired. That lets certificate management support policy enforcement instead of merely proof of possession. Renewal should require re-validation of device status and ownership, not only automated reissue on expiry. Revocation also needs to be fast enough to matter in the field, especially when devices are widely distributed or intermittently connected. NHI Mgmt Group’s lifecycle guidance for managing NHIs is directly relevant here because the same lifecycle discipline applies to device certificates.
- Use unique device certificates, not shared credentials across a model or site.
- Store certificate ownership in inventory and CMDB records, not in tribal knowledge.
- Set certificate TTLs that reflect device class and risk, then enforce renewal review.
- Revoke on retirement, loss, compromise, or repurposing, not only on expiry.
- Log issuance, renewal, and revocation events for audit evidence and incident response.
Where IoT is integrated with zero trust, certificate validation should be paired with posture, location, and policy checks at connection time, not assumed to be sufficient on its own. This aligns with broader NHI risk patterns described in the Top 10 NHI Issues. These controls tend to break down when devices are deployed at scale with no reliable ownership record, because revocation and renewal cannot be enforced consistently.
Common Variations and Edge Cases
Tighter certificate governance often increases operational overhead, requiring organisations to balance cryptographic assurance against device uptime and field support constraints. That tradeoff becomes especially visible in low-connectivity environments, where devices may miss renewal windows or fail to reach revocation services. Current guidance suggests designing for short-lived trust where possible, but there is no universal standard for how short IoT certificate lifetimes should be across all device classes.
Edge cases also matter. Brownfield fleets may include devices that cannot support modern certificate rotation, which means compensating controls such as network segmentation, gateway mediation, and compensating monitoring become necessary. Shared hardware modules, outsourced manufacturing, and third-party installers add further complexity because certificate issuance may happen before the asset is fully under enterprise control. The regulatory and audit perspective on NHIs is useful when proving that governance exists beyond issuance logs.
Another common exception is certificate replacement during hardware refresh. Replacement should not inherit the old trust context automatically. A new certificate should trigger re-approval, re-ownership, and, where needed, re-attestation of device purpose. Teams also need to plan for compromised private keys, because a valid certificate with an exposed key is still an active identity risk. In regulated or safety-critical environments, this is where governance usually becomes a board-level evidence problem rather than a technical one.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses lifecycle control gaps like renewal, rotation, and revocation. |
| NIST CSF 2.0 | PR.AC-4 | Identity and access control must cover device trust and authorization. |
| NIST AI RMF | AI risk governance logic fits autonomous device trust and lifecycle accountability. |
Assign ownership, monitoring, and accountability to all device identities across their lifecycle.
