Identity Of Things

What identity of things covers

Identity of things extends identity management to connected devices, sensors, appliances, and other physical or virtual things. The core idea is that each thing can be uniquely recognised, authenticated, and governed as a distinct actor, rather than treated as an anonymous endpoint. That makes trust decisions possible at scale across networks, clouds, and APIs.

The concept matters because large environments rarely fail from a single device type, they fail when too many things share the same trust assumptions. The moment devices can prove who or what they are, security teams can apply policy based on device identity, integrity, and intended role instead of relying only on location or network perimeter.

How device identity is established

Identity for things is usually anchored in cryptographic material such as certificates, keys, or device credentials. Those identifiers let a thing authenticate to infrastructure, present evidence of integrity, and obtain the permissions it needs for a specific service or workload. In mature environments, identity is lifecycle-managed from enrolment through rotation and revocation, not assigned once and forgotten.

This is closely related to device attestation, bootstrap trust, and provisioning workflows. A strong design separates the device's unique identity from the shared system it connects to, so compromise of one device does not automatically validate another. Where trust is weak, cloned identities, shared secrets, or reused credentials make device impersonation much easier.

Why identity matters for access and trust

Once a thing has a real identity, access control can move beyond crude network allow lists. The platform can distinguish between a legitimate sensor, a maintenance interface, and an unmanaged device, then grant only the actions each one needs. That supports least privilege for connected environments and reduces the blast radius of a stolen or misconfigured device identity.

Identity also gives operators a way to enforce trust boundaries across cloud services, APIs, and internal systems. A device that can prove its identity may still need additional policy checks before it is allowed to publish telemetry, receive commands, or join a management plane. In practice, identity is what turns “connected” into “trusted enough to interact.”

Operational implications across the device lifecycle

Identity of things is not only about login and access, it is also about inventory, ownership, and ongoing control. Organisations need to know which devices exist, which identity materials they use, who manages them, and when they should be retired. That becomes especially important when fleets are large, geographically distributed, or partly embedded in operational technology.

Lifecycle problems are common when devices ship with default credentials, when certificates never rotate, or when orphaned devices remain trusted after replacement. The security value of device identity depends on keeping the identity record current, because stale trust is often worse than no trust at all.

Risk and Threat Considerations

Identity of things creates a high-value trust anchor, so weak provisioning, shared credentials, or poor revocation can let an attacker impersonate a device, persist after compromise, or move laterally through connected services. The risk is not only data theft, but also command abuse, fraudulent telemetry, and silent loss of trust in fleets that were assumed to be authentic.

Failure mechanism: If device identities are cloned, never rotated, or not revoked when devices are decommissioned, attackers can reuse legitimate trust paths instead of breaking them. That is especially dangerous where certificates or keys are stored insecurely or where identity is accepted without checking device integrity or lifecycle status.

Impact: A compromised thing can become a durable access path into cloud, API, and operational environments, with consequences ranging from service disruption to unsafe physical actions. In large fleets, one weak identity process can scale into many trusted impostors.

Practitioner Guidance

Why practitioners should care: Treat identity of things as a control plane problem, not just a device-enrolment problem. The important question is whether each thing can be uniquely identified, rotated, revoked, and authorised in a way that matches its real risk and function.

Governance implication: Ownership must be explicit for device identity issuance, certificate renewal, and retirement. If nobody owns those decisions, orphaned trust accumulates quickly and device identities outlive the assets they were meant to protect.

Practitioner takeaway: The strongest deployments make device identity verifiable, short-lived where possible, and tightly linked to inventory and policy so that trust can be withdrawn as quickly as it is granted.

Related resources from NHI Mgmt Group

• What is a Non-Human Identity (NHI)?
• What is the difference between NHI and machine identity?
• What is the difference between an identity, a credential, and a secret?
• Why has identity replaced the network perimeter as the primary security boundary?