NIST IoT procurement rules raise the bar for device identity

At a glance

What this is: This is an analysis of how U.S. federal IoT procurement rules push device identity, updateability, and auditability into acquisition decisions.

Why it matters: It matters because IoT devices are NHIs with long lifecycles and broad blast radius, so procurement, identity, and lifecycle controls now have to be aligned before a device is deployed.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read GlobalSign's analysis of the IoT Cybersecurity Improvement Act and device identity

Context

The cybersecurity of IoT devices is no longer just a device engineering problem. For federal environments, procurement now has to account for identity, logging, updateability, and disclosure because connected devices behave as non-human identities with their own trust, access, and lifecycle issues.

The article explains how the IoT Cybersecurity Improvement Act and the NIST guidance series shift responsibility upstream into acquisition and governance. That matters for NHI programmes because a device that cannot be uniquely identified, updated, or audited is already a governance failure before it ever reaches production.

Key questions

Q: How should organisations govern IoT devices as part of identity security?

A: Treat IoT devices as governed identities, not just endpoints. Assign each device a unique identity, bind onboarding to certificate-based authentication, define revocation criteria, and track which service chains depend on that identity. The governance goal is to make device trust explicit, reviewable, and removable when the device is retired, compromised, or no longer authorised.

Q: Why do IoT fleets create more machine identity risk than traditional endpoints?

A: IoT fleets create more machine identity risk because devices often stay in service for years while their certificates, firmware, and trust assumptions age much faster. Fragmented visibility makes it hard to know which identities are active, retired, or misconfigured, so attackers and outages both exploit the same governance gap.

Q: What breaks when IoT devices cannot be patched or revoked?

A: The organisation loses the ability to control the device after deployment. Unpatchable devices accumulate risk over time, and unrevocable identities remain trusted even after compromise or replacement. That turns a single device flaw into a persistent governance problem across the environment.

Q: Who is accountable when a connected device becomes an entry point for attackers?

A: Accountability should sit with both the business owner of the device and the security team responsible for network enforcement. If a device can connect without review, no one truly owns the risk. Clear accountability means the organisation can isolate, investigate, and retire the device without delay or ambiguity.

Technical breakdown

How federal IoT procurement turns devices into identity objects

The article frames IoT devices as systems that need to be governed, not just installed. That is an identity problem because each device needs a unique identity, a way to be authenticated, and a defined access relationship to the network and supporting services. In NHI terms, the unit of trust is the device, not the user who bought it or the team that operates it. Once procurement begins specifying those controls, identity becomes part of the supply chain and lifecycle rather than a post-deployment security patch.

Practical implication: Practitioners should treat procurement language as an identity control point and require device identity, logging, and updateability before approval.

Why updateability and revocation matter for IoT NHIs

IoT devices often persist for years, which makes them vulnerable if they cannot be patched, reconfigured, or retired cleanly. The article highlights over-the-air updates and clear user controls because security depends on the ability to change the device state after purchase. That maps directly to NHI governance: if credentials, certificates, or device profiles cannot be rotated or revoked, the organisation inherits a standing identity with no practical offboarding path. The risk is compounded when devices are embedded in building systems, logistics, or industrial environments.

Practical implication: Security teams should verify that every device class supports remote update, revocation, and offboarding before it is allowed into the environment.

How NIST alignment changes the control model for connected devices

The NIST guidance referenced in the article ties IoT to broader control families rather than treating it as a standalone category. That is the right model because connected devices affect authentication, logging, configuration management, and resilience at the same time. For identity teams, this means NHI controls cannot stop at secret storage or certificates. They have to connect to the control framework that governs acquisition, configuration drift, audit logging, and recovery. Otherwise, the organisation creates a fragmented security model where procurement, operations, and IAM are not speaking the same language.

Practical implication: Map IoT onboarding and lifecycle controls to your existing NIST and IAM governance processes instead of creating an isolated device exception path.

Threat narrative

Attacker objective: The attacker objective is to use weakly governed IoT devices as durable footholds into enterprise or operational environments.

1. Entry occurs when an IoT device is acquired without unique identity, secure update paths, or clear security controls, leaving the device as an easy target in the environment.
2. Escalation happens when hardcoded or shared credentials, weak authentication, or unpatchable firmware allow attackers to abuse the device as a persistent non-human identity.
3. Impact follows when compromised IoT devices provide access to networks, physical systems, or operational data, expanding the blast radius beyond the device itself.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IoT procurement is now identity governance by another name. The article is right to place NIST guidance at the point of acquisition because a device that cannot be uniquely identified, updated, or retired is already failing as an NHI. That shifts the governance question from whether a device is connected to whether it can be controlled throughout its lifecycle. Practitioners should treat procurement as the first identity review, not the last.

Standing device trust is the real control gap. IoT programmes fail when devices are allowed to retain long-lived access without a credible revocation path, especially in environments that rely on certificates or embedded credentials. The article points toward unique device identity and secure updates, but the deeper issue is whether the organisation can actually remove trust when the device is compromised, replaced, or decommissioned. That is the difference between owned devices and governed devices.

Device identity must be tied to operational accountability. Building systems, vehicle telemetry, industrial sensors, and logistics hardware all create the same problem if ownership, patchability, and logging are not aligned. NIST-aligned procurement helps, but only if identity teams, supply chain owners, and operational technology teams share the same lifecycle record. Practitioners should expect policy drift unless onboarding and offboarding are explicitly assigned.

Unique device certificates are a control, not a strategy. The article points to PKI and per-device authentication as a better foundation, but identity assurance does not end at issuance. Certificates without logging, rotation, and offboarding still leave an enterprise with dormant NHIs that look controlled but behave as standing risk. The governance model must cover the full identity lifecycle, from factory to retirement.

IoT trust must be measured in revocation time, not vendor claims. If a device cannot be updated or invalidated quickly, the control model is weaker than it appears. That makes revocation latency, asset visibility, and certificate handling the practical metrics that matter for identity governance. Teams should use those measures to decide whether a device class belongs in the environment at all.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• From our research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• For the lifecycle side of this problem, see Ultimate Guide to NHIs , Standards for the control mapping that teams can extend into IoT procurement.

What this signals

Device identity will increasingly be judged by revocation speed and inventory quality. If a connected device cannot be tracked, updated, or retired quickly, it should be treated as an unmanaged identity with a physical footprint. That changes programme design: procurement, CMDB discipline, and certificate governance need to be measured together, not as separate projects.

The practical signal for identity teams is that IoT control gaps now show up earlier, in sourcing and vendor qualification, rather than later in incident response. Organisations that keep acquisition, security, and operations in separate lanes will keep rediscovering the same problem at deployment time. That is where control drift becomes visible.

As connected environments mature, the boundary between NHI governance and operational technology security will keep narrowing. Teams should expect more pressure to prove device ownership, updateability, and offboarding in the same way they already prove access review and credential hygiene for other NHIs.

For practitioners

• Add identity requirements to procurement language Require unique device identity, secure update capability, audit logging, and clear security disclosure in every IoT purchase specification. If a device cannot meet those requirements, it should not move into the approved inventory. Use the procurement review to force ownership of the identity lifecycle before deployment.
• Verify revocation and offboarding paths for every device class Confirm that certificates, credentials, and device profiles can be revoked when the device is replaced, compromised, or retired. Where revocation is not operationally realistic, classify the device as high-risk and limit where it can connect. This is especially important for embedded and hard-to-patch systems.
• Align IoT onboarding with existing NIST control families Map device onboarding, configuration, logging, and recovery to your broader governance model instead of creating an isolated IoT exception. Use NIST CSF and related control families to ensure the same review logic applies to connected devices, service accounts, and other NHIs.
• Track device visibility as a governance metric Build an inventory that shows which devices are active, who owns them, what identity they present, and whether they still receive updates. A device that is invisible to inventory or impossible to update should be treated as an unmanaged identity, not as a routine asset.
• Require PKI governance for devices that depend on certificates If the IoT programme relies on certificates, define issuance, rotation, and retirement rules before scale increases. Pair certificate policy with lifecycle records so the organisation knows when a device identity should be replaced rather than merely renewed.

Key takeaways

• IoT procurement is now an identity governance issue because device trust, updateability, and revocation determine whether the device can be controlled after deployment.
• The scale problem is visible in NHI governance more broadly, where only 5.7% of organisations report full visibility into their service accounts and hidden identity risk remains the norm.
• Practitioners should force identity, logging, and offboarding requirements into procurement so connected devices do not enter production as permanent trust liabilities.

Key terms

• IoT Device Identity: 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.
• Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
• Procurement Control Point: A governance checkpoint where security requirements are enforced before a device enters the environment. For IoT, this is where identity, updateability, logging, and revocation requirements should be validated so the organisation does not inherit unmanaged trust later.

What's in the full article

GlobalSign's full article covers the operational detail this post intentionally leaves for the source:

• The specific NIST SP 800-213 and SP 800-213A guidance points that federal buyers are expected to map into procurement.
• The article's examples of IoT use in government environments, including buildings, fleets, and logistics, which show where the policy pressure lands.
• The device identity and PKI angle in more depth, including why unique certificates are central to the security model.
• The article's discussion of how non-government IoT vendors can use the federal baseline as a market requirement rather than a one-off compliance check.

👉 GlobalSign's full post covers the NIST guidance, procurement impact, and PKI-related device identity detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.