They should treat each device credential as a governed identity with an owner, a purpose, and a lifecycle. That means controlling issuance, rotation, renewal, and revocation, and pairing those controls with signed updates and traceable maintenance actions. In live OT and IoT environments, the goal is not isolation at any cost, but verifiable trust with minimal operational disruption.
Why This Matters for Security Teams
Device identities are not just technical artifacts in OT, IoT, and connected enterprise environments. They are the mechanism that lets sensors, gateways, controllers, and service appliances prove what they are, receive updates, and access downstream systems. If those identities are weakly issued or never retired, the result is not only credential sprawl but also persistent trust in devices that may already be compromised.
This is why guidance from NIST Cybersecurity Framework 2.0 remains relevant: inventory, access control, and recovery all depend on knowing which device is speaking, what it is allowed to do, and whether it still belongs in the environment. NHIMG research shows the issue is not hypothetical. In the Ultimate Guide to NHIs, NHIMG reports that only 5.7% of organisations have full visibility into their service accounts, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Security teams often treat device identity as a one-time provisioning task, but in practice the risk accumulates across maintenance windows, vendor access, firmware updates, and emergency bypasses. In practice, many security teams encounter device identity abuse only after a field device or edge gateway has already been used as a durable foothold.
How It Works in Practice
Protecting device identities starts with making each device credential a governed identity, not a shared secret. That means assigning an owner, defining the device’s purpose, and tying issuance to a verified onboarding event. For connected fleets, the strongest pattern is to pair device certificates or token-based workload credentials with secure boot, signed firmware, and attested update paths so the device can prove both its identity and its software state.
In operational terms, teams should separate identity lifecycle controls from network reachability. A device may remain online, but its identity can still be rotated, renewed, scoped, or revoked based on risk. This is especially important when third-party maintenance or integrator access is involved. NHIMG’s Schneider Electric credentials breach and JetBrains GitHub plugin token exposure are reminders that exposed machine credentials can persist far beyond the original compromise if rotation and offboarding are weak.
A practical control stack usually includes:
- Unique identity per device, with no shared certificates or global secrets.
- Short-lived credentials where the platform supports them, with automated renewal before expiry.
- Certificate or token rotation tied to maintenance events, not only calendar schedules.
- Revocation procedures that work even when the device cannot be physically retrieved.
- Logging that links every identity action to a named operator, vendor, or automation workflow.
For design guidance, security teams should map device identity to Zero Trust principles and document it alongside incident response and asset management. Best practice is evolving toward continuous verification, but there is no universal standard for every OT and IoT class yet; the right balance depends on uptime tolerance, device capability, and field-service realities. These controls tend to break down when legacy devices cannot support per-device certificates or secure remote revocation because identity and transport protections cannot be separated cleanly.
Common Variations and Edge Cases
Tighter device identity controls often increase operational overhead, requiring organisations to balance stronger assurance against maintenance complexity and downtime risk. That tradeoff is most visible in plants, hospitals, and distributed field environments where rebooting a device or replacing a certificate can interrupt a live process.
Some environments can support full certificate-based identity and automated renewal, while others can only support gateway-mediated trust or compensating controls. In those cases, current guidance suggests using a control plane that can front legacy devices, enforce policy at the edge, and maintain an auditable record of who approved exceptions. This is particularly relevant when a single device identity must support both telemetry and remote service access, because those use cases often deserve different privilege boundaries.
There is also a distinction between device identity and operator identity. A maintenance engineer may authenticate with strong human identity controls, but that does not make the device itself trustworthy. For that reason, The State of Non-Human Identity Security highlights a wider governance problem: organisations frequently lack visibility into machine identities and their connected access paths. The practical response is to treat device identities as living assets, retire them on decommission, and validate them continuously when they are used to reach critical systems.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Device credential rotation is central to preventing long-lived identity abuse. |
| NIST CSF 2.0 | PR.AA-01 | Asset and identity assurance depend on knowing which device is authentic. |
| NIST Zero Trust (SP 800-207) | ID | Zero Trust requires continuous verification of device identity, not network location. |
Inventory device identities and automate rotation, renewal, and revocation based on lifecycle risk.
