How should organisations govern IoT devices as part of identity security?

Treat IoT devices as governed identities, not just endpoints. Assign each device a unique identity, bind onboarding to certificate-based authentication, define revocation criteria, and track which service chains depend on that identity. The governance goal is to make device trust explicit, reviewable, and removable when the device is retired, compromised, or no longer authorised.

Why This Matters for Security Teams

IoT devices should be governed as identities because they authenticate, request access, and interact with services in ways that can either strengthen or weaken trust across the environment. The common mistake is to manage them as inventory alone, which leaves onboarding, rotation, revocation, and dependency tracking underdefined. That gap matters because a device identity can outlive the device, remain trusted after compromise, or be reused in ways that bypass operational oversight.

Current guidance suggests treating each device as a distinct identity with a lifecycle that is as explicit as a human account. That includes certificate-based onboarding, revocation criteria, and visibility into which applications, gateways, or control planes depend on the device. NHI Management Group’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which helps explain why device identities become durable risk rather than bounded trust.

Security teams also need a governance model that aligns with identity security frameworks such as the NIST Cybersecurity Framework 2.0. In practice, many security teams encounter device abuse only after a compromised sensor, gateway, or embedded service account has already been used to reach a trusted workload, rather than through intentional lifecycle review.

How It Works in Practice

Operationally, IoT governance starts by assigning each device a unique cryptographic identity and binding that identity to enrollment, policy, and monitoring. Certificate-based authentication is the most common baseline because it gives a strong proof of identity and supports revocation when the device is retired, patched, or suspected of compromise. Governance improves when the device identity is linked to asset ownership, firmware status, network zone, and the services that rely on it.

A practical program usually includes these steps:

• Issue identity at provisioning time through a controlled enrollment workflow.
• Use short-lived certificates or tightly managed renewal windows where possible.
• Maintain a dependency map showing which APIs, brokers, and workloads trust that device.
• Define revocation triggers for theft, drift, failed attestation, and decommissioning.
• Review device trust alongside patch state, location, and business criticality.

That lifecycle approach aligns with the Lifecycle Processes for Managing NHIs guidance and with identity-centric controls in the NIST Cybersecurity Framework 2.0. It also helps reduce the common failure mode where a valid device certificate continues to grant trust long after the physical device is no longer under control.

For organisations with large fleets, telemetry should feed both security operations and asset management so that anomalous behaviour is visible before trust is abused. These controls tend to break down in brownfield industrial, medical, or building-automation environments because legacy devices often cannot support modern certificate renewal, revocation, or per-device policy enforcement.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance stronger trust boundaries against device uptime, vendor constraints, and field-maintenance realities. Best practice is evolving for constrained IoT, and there is no universal standard for every protocol or sector.

Some environments can support mutual TLS, remote attestation, and automated revocation cleanly. Others rely on gateways, network segmentation, or proxy identities because the device itself cannot hold a modern certificate stack. In those cases, governance should focus on the trust boundary actually in use, not the ideal device model. That means the gateway, broker, or concentrator may become the governed identity, while the downstream device remains an attested asset with limited direct trust.

This is where risk framing matters. The Top 10 NHI Issues and the Regulatory and Audit Perspectives sections both reinforce the same point: identity governance must be provable, not assumed. For IoT, that means documenting who can issue trust, who can revoke it, and what evidence proves the device is still entitled to operate.

The practical edge case is that some vendors still require long-lived credentials or closed management planes, which increases residual risk even when the organisation has strong policy. In those cases, the right answer is compensating control plus a retirement plan, not pretending the device is fully governed when it is not.

Related resources from NHI Mgmt Group

• How should organisations govern domain names as part of identity security?
• How should security teams govern AI transformation across identity and access programmes?
• How should organisations govern device identity across manufacturing and deployment?
• How do organisations know if identity-driven workflow security is working?