Why do unmanaged or long-lived device identities create risk in IoT programmes?

Unmanaged or long-lived identities create risk because they reduce the organisation’s ability to verify, revoke, and refresh trust over time. In IoT, that can leave devices authenticated long after their security posture changes. Short-lived certificates and regular checks reduce exposure, support revocation, and make it harder for compromised devices to remain trusted indefinitely.

Why unmanaged or long-lived device identities become a trust problem

Device identities are not just labels, they are the mechanism that lets an IoT platform decide whether a device should still be trusted. When those identities are unmanaged, or left valid for too long, the organisation loses the ability to tell which devices are current, which are retired, and which have been compromised. That creates stale trust, weak accountability, and gaps in revocation.

In IoT programmes this matters because devices are often deployed at scale, updated infrequently, and hard to inspect physically. A certificate or key that remains valid after the device’s condition has changed can keep granting access to systems, telemetry, or commands long after trust should have been withdrawn. That is why lifecycle control is part of the security model, not an administrative detail.

How long-lived identities increase exposure over the device lifecycle

The longer an identity lives, the more opportunities there are for drift: firmware changes, ownership changes, decommissioning errors, and secret exposure. If the identity is not refreshed or revalidated, the platform continues to accept a device based on an assumption that may no longer be true. Shorter cryptoperiods, routine re-enrolment, and explicit expiry reduce the window in which stale credentials can be abused.

Unmanaged identities also make it harder to distinguish normal fleet growth from orphaned access. In practice, that can mean duplicate identities, unused certificates, and devices that remain authorised after replacement or disposal. A clean lifecycle gives you a reliable inventory of what is trusted now, rather than what was trusted at some point in the past. For programme design, this is the same discipline that underpins broader non-human identity governance and the operating model described in the Identity Security Programme Guide.

Why revocation and isolation matter when devices are compromised

If a device credential is stolen, copied, or embedded into a cloned unit, the risk is not only initial compromise but persistence. Long-lived trust material can let an attacker continue authenticating even after the original issue has been discovered, especially if the platform lacks fast revocation or periodic revalidation. That is why device identity design must assume compromise is possible and make trust easy to withdraw.

The practical security question is whether the identity is bound tightly enough to the current device, current environment, and current state of the fleet. If not, the attacker may only need one successful theft to gain extended access. Revocation, rotation, and isolation controls reduce the blast radius, while regular attestation or re-checks help ensure a device is still entitled to be trusted. This is the same control logic reflected in OWASP Non-Human Identity Top 10 and the access-control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63 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 — Improper Offboarding	Long-lived device identities create stale trust after devices are retired or replaced.
	NHI-07 — Long-Lived Secrets	Device credentials that remain valid too long increase persistence and compromise exposure.
Recommendation — Expire and revoke device identities when assets leave service or change ownership. Shorten credential lifetimes and rotate device secrets on a defined schedule.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Device identities depend on managed authenticators, rotation, and revocation over time.
	IA-9 — Service Identification and Authentication	IoT devices authenticate as non-human entities, so machine-to-system trust must be controlled.
	AC-2 — Account Management	Device identities need lifecycle ownership, inventory, and removal when no longer needed.
Recommendation — Enforce authenticator lifecycle controls for device certificates, keys, and tokens. Bind device authentication to approved system identities and revalidate them regularly. Maintain an authoritative inventory and promptly disable obsolete device identities.
NIST SP 800-63	Digital Identity Guidelines	The topic is fundamentally about identity trust, reauthentication, and credential freshness.
Recommendation — Use identity assurance and reauthentication practices that force periodic trust renewal.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	Trust should be continuously verified rather than granted indefinitely to devices.
Recommendation — Continuously evaluate device trust and require revalidation before granting access.

Practitioner Guidance

What to prioritise: Treat device identity lifecycle as an inventory and trust problem first. If you cannot answer which devices are active, expired, retired, or unable to renew, you do not have control over trust.

What to verify: Confirm that every production device identity has an owner, an expiry or renewal path, and a documented revocation process. Pay special attention to shared certificates, baked-in keys, and devices that are difficult to update in the field.

Decision rule: If a device credential can still authenticate after the device is decommissioned, replaced, or suspected compromised, shorten the validity period and add a forced revalidation step before the next trust decision.

What good looks like: The fleet can be re-enrolled, rotated, or revoked in a controlled way, and trust is based on current state rather than historical enrolment alone.

Practitioner takeaway: IoT identity risk is usually not that devices have identities, it is that the organisation cannot reliably prove those identities still deserve trust.