A device identity is the unique security profile that lets an IoT asset prove what it is before it participates in a service chain. It supports authentication, authorization, and traceability, and it should be governed through lifecycle controls so the identity can be issued, scoped, and revoked when the device changes state.
Expanded Definition
IoT device identity is the cryptographic and policy-backed identity assigned to a connected device so it can authenticate itself, receive the right permissions, and be traced across a service chain. In NHI practice, that identity is not just a name or asset tag. It usually includes certificates, keys, attestation signals, metadata, and lifecycle rules that define when the device is valid, where it may connect, and what it may access.
Definitions vary across vendors when they collapse device identity, device posture, and device registration into one control plane. For NHI Management Group, the important distinction is that identity proves the device is expected and trustworthy enough to participate, while authorization determines what the device can do once admitted. That distinction aligns with the broader governance model described in the Ultimate Guide to NHIs and with access governance principles in the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating device onboarding as a one-time registration event, which occurs when certificates or shared secrets remain valid after firmware changes, ownership transfer, or decommissioning.
Examples and Use Cases
Implementing IoT Device Identity rigorously often introduces enrollment and certificate-lifecycle overhead, requiring organisations to weigh stronger trust boundaries against operational complexity at scale.
- Manufacturing sensors use unique device certificates so each unit can authenticate to a gateway without sharing credentials across a fleet.
- Smart building controllers present identity claims before they are allowed to submit telemetry or accept remote commands, reducing blind trust in network location.
- Connected medical devices use attestation-backed identity to prove the expected firmware and hardware profile before exchanging patient-related data.
- Fleet operators tie identity issuance to asset inventory and offboarding so retired devices cannot keep calling internal APIs after disposal.
- Supply-chain teams review device trust relationships alongside service-account exposure patterns described in the 52 NHI Breaches Analysis and the IETF’s RFC 9334 on Entity Attestation Token concepts.
For organisations trying to separate device identity from network access, the Top 10 NHI Issues article is a useful lens because it shows how identity drift, poor rotation, and weak visibility emerge in real deployments.
Why It Matters in NHI Security
IoT Device Identity matters because devices are often operationally persistent, remotely managed, and difficult to inspect physically once deployed. If identity is weak or reused, attackers can impersonate a device, pivot through trusted telemetry paths, or keep access long after the asset should have been revoked. The NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for device estates too, because unmanaged identities are rarely isolated from broader NHI risk. The same lifecycle failures that drive exposed secrets in enterprise systems also apply to device credentials, especially when provisioning is rushed or offboarding is incomplete.
Good device identity governance supports Zero Trust Architecture, but it only works when identity is bound to lifecycle state, not just deployment status. That means rotation, revocation, and asset reconciliation must be treated as security controls, not maintenance tasks. The Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both point toward the same operational need: trust must be continuously revalidated, not assumed forever.
Organisations typically encounter credential reuse, unrevoked access, or unexplained device traffic only after a fleet event or breach review, at which point IoT Device Identity becomes operationally unavoidable to address.
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-01 | Covers lifecycle governance for non-human identities, including device-issued credentials. |
| NIST CSF 2.0 | PR.AA | Addresses identity proofing and access control for devices in operational environments. |
| NIST Zero Trust (SP 800-207) | Zero Trust relies on per-request trust evaluation for device identities. |
Bind each IoT device identity to issuance, scope, rotation, and revocation controls across its full lifecycle.
