Connected devices operate continuously, often at scale, and may be produced, deployed, and operated by different teams. That makes device identity a lifecycle issue spanning enrolment, secure communication, monitoring, and retirement. If those controls are fragmented, the device becomes a standing trust object rather than a governed identity.
Why This Matters for Security Teams
Connected devices create a different identity problem because they are not occasional actors like users. They are always on, often numerous, and may be owned, provisioned, patched, monitored, and retired by different teams. That breaks the simple idea that identity governance is a joiner-mover-leaver exercise. For devices, identity is a lifecycle control surface spanning manufacturing, enrolment, secure comms, telemetry, and decommissioning.
Security teams also inherit a larger trust burden than they do for human users. NHIMG’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which helps explain why device identity goes wrong at scale. The issue is not just authentication. It is whether each device has a durable, verifiable, revocable identity that can be governed across its entire life. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity, asset inventory, and continuous monitoring must work together. In practice, many security teams encounter device sprawl and stale credentials only after a fleet has already been deployed without a coherent retirement path.
How It Works in Practice
Device identity governance starts before a device ever connects. The organisation needs a trust anchor for enrolment, a way to prove device provenance, and a policy for what the device may do once onboarded. Unlike users, devices do not benefit from interactive approval flows, so the control plane must be automated. That usually means unique device identities, cryptographic certificates or workload tokens, and policy tied to device class, location, firmware state, and business function.
In mature environments, governance is treated as a lifecycle pipeline rather than a one-time registration event. The practical steps usually include:
- pre-provisioning or secure enrolment with unique identity material
- certificate or secret rotation on a fixed schedule
- continuous validation of firmware, posture, and ownership
- telemetry that links each device to its current state and risk
- revocation and quarantine when a device is lost, retired, or compromised
This is where NHI-specific guidance becomes more useful than human IAM patterns. NHIMG’s Lifecycle Processes for Managing NHIs places emphasis on rotation, offboarding, and visibility, which are the same pressure points for connected devices. The reason is simple: a device identity that is never rotated or retired becomes a standing trust object. That is especially dangerous in distributed environments where devices authenticate to APIs, brokers, gateways, and internal services without human review. A standards-based control model such as EU Cyber Resilience Act compliance can help drive secure-by-design expectations, but the operational work still sits in inventory accuracy, automated issuance, and revocation discipline. These controls tend to break down when device ownership is split across product, operations, and security because no single team owns the full identity lifecycle.
Common Variations and Edge Cases
Tighter device identity control often increases operational overhead, requiring organisations to balance stronger assurance against field support, uptime, and manufacturing constraints. That tradeoff is most visible in legacy fleets, industrial systems, and low-power edge devices that cannot easily support modern certificate rotation or continuous attestation.
There is no universal standard for every device category yet. Best practice is evolving toward context-aware governance, but constrained environments may need risk-tiered controls instead of uniform enforcement. For example, a high-value gateway may justify short-lived credentials, hardware-backed keys, and continuous posture checks, while a sensor with minimal compute may rely on gateway-mediated trust and segmented network controls. The key is to avoid granting the same standing access to every device simply because it is hard to manage at scale.
Edge cases also appear when devices are operated by third parties, resold, or embedded in customer environments. In those scenarios, offboarding is often the weakest point, and NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both underscore the risk of missed rotation, poor visibility, and inadequate revocation. The practical rule is to treat device identity as continuously governed infrastructure, not as a one-time asset tag. That distinction matters most when a compromised device can still authenticate long after the team responsible for it has moved on.
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-01 | Device identities need unique issuance, rotation, and revocation across their lifecycle. |
| NIST CSF 2.0 | PR.AA-01 | Connected devices require identity, inventory, and access controls to stay in sync. |
| NIST AI RMF | Lifecycle accountability and monitoring are essential when autonomous devices act continuously. |
Assign each device a unique identity, rotate credentials, and revoke trust immediately on retirement or compromise.
