TL;DR: IoT devices are arriving faster than organisations can inventory, authenticate, and update them, leaving machine identities untracked, misconfigured, or expired and creating outages, compliance pressure, and attack paths, according to Keyfactor. The core problem is not device count alone, but the assumption that manual PKI and fragmented visibility can still govern trust at fleet scale.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: IoT security has become a machine identity governance problem because device growth is outpacing inventory, certificate management, and authentication controls.
Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern device trust across operational technology, edge, cloud, and hybrid estates where manual PKI and spreadsheet tracking fail.
By the numbers:
- There is a more than 40% surge in IoT, BYO mobile, and other devices being used in company networks.
Context
IoT security is a machine identity problem when devices outnumber the systems used to track, authenticate, and renew their credentials. As fleets grow across cars, hospital equipment, industrial sensors, and cloud-connected systems, every device adds another certificate and another lifecycle obligation.
The governance gap is not simply device count. It is the mismatch between long-lived operational devices and security processes that still assume manual visibility, periodic review, and human-paced certificate handling. In that model, expired or unknown identities become outages, access paths, and compliance failures.
Keyfactor argues that IoT device trust now depends on continuous discovery, lifecycle automation, and crypto-agility rather than isolated PKI administration. That starting position is typical across modern IoT programmes that have expanded faster than their identity governance discipline.
Key questions
Q: What breaks when bots and IoT devices are left out of identity governance?
A: When bots and IoT devices are excluded from identity governance, organisations lose visibility into non-human access, approvals, and privilege scope. That creates orphaned accounts, over-permissioned automation, and unmanaged machine-to-machine trust. The result is weaker auditability and a larger attack surface, especially when those identities interact with business-critical systems.
A: PKI alone does not prevent outages if certificate ownership, renewal, and monitoring are fragmented. IoT environments often mix internal tools, third-party tools, and legacy processes, which leaves gaps in visibility and automation. When certificates expire or are mismanaged, devices can lose trust, production can stop, and recovery becomes expensive. A functioning programme needs end-to-end certificate control.
Q: How can security teams know if cloud identity governance is actually working?
A: The clearest signals are fewer unresolved access findings, shorter evidence-collection cycles, lower counts of stale keys, and reduced reliance on manual review. If teams still spend days reconstructing access state, governance is not operating continuously. Effective programmes can show current MFA coverage, role scope, and credential age on demand.
Q: How should security teams govern trust for IoT devices across edge and cloud environments?
A: Treat every device as a governed identity with an owner, a certificate lifecycle, and a revocation path. Mutual authentication should be required before any device can influence operations, and trust must extend from onboarding through retirement. In mixed OT and cloud environments, identity assurance is the control that keeps device data and commands reliable.
Technical breakdown
Why IoT certificates fail at fleet scale
IoT devices rely on cryptographic identity to prove authenticity and secure communications. Each device introduces at least one machine identity, often through certificates that must be issued, renewed, rotated, and revoked across long-lived deployments. The failure mode is not cryptography itself, but the operational model around it. Manual PKI, siloed certificate authority tooling, and ad hoc tracking cannot reliably keep pace with thousands or hundreds of thousands of devices. When certificates expire or identities are not tracked, the result is service disruption, access loss, or an identity that remains trusted long after it should have been retired.
Practical implication: move certificate lifecycle handling out of manual workflows and into governed automation tied to device inventory.
How fragmented visibility creates trust gaps
A connected device estate can span cloud, edge, legacy, and embedded environments at the same time, which makes identity inventory harder than application inventory. If teams do not know where certificates exist, they cannot know which identities are active, retired, duplicated, or overdue for renewal. Fragmentation also weakens incident response because unknown identities are harder to assess and isolate. In NHI terms, visibility is not a reporting nicety. It is the precondition for deciding which machine identities are still legitimate and which ones represent unmanaged trust exposure.
Practical implication: establish a single, continuously updated inventory of device certificates and ownership across all connected environments.
Why crypto-agility matters for long-lived IoT fleets
IoT devices often remain deployed for years, while cryptographic standards, threats, and compliance expectations change much faster. That creates a lifecycle mismatch: the device stays in service, but the trust model around it must evolve. Crypto-agility is the ability to reissue or update certificates and related cryptographic settings without replacing the device fleet. This is increasingly important where regulators and buyers expect continuous proof of security rather than one-time assurance. The technical challenge is not only adopting stronger algorithms later, but making reissuance feasible across devices that may be difficult to access physically or operationally.
Practical implication: design IoT identity programmes so certificate and algorithm changes can be rolled across fleets without manual intervention.
Threat narrative
Attacker objective: The attacker seeks a low-friction foothold through insecure devices and their identities, then uses that access to move through the network or disrupt operations.
- Entry occurs when a poorly secured IoT device is introduced with weak default credentials or unpatched firmware, creating a trust foothold on the network.
- Credential abuse follows when the device identity is unknown, misconfigured, or expired, allowing an attacker to exploit weak or stale trust relationships rather than strong authentication.
- Impact emerges when outages, unauthorized access, or lateral movement reach operational systems, production processes, or safety-critical functions.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
IoT trust has become an identity lifecycle problem, not a device count problem. The operational failure is not that organisations own too many devices, but that they cannot reliably govern the identities attached to them. When certificates, ownership, and renewal state are fragmented, the programme loses the ability to say what is trusted, by whom, and for how long. Practitioners should treat fleet trust as a governed lifecycle rather than an inventory exercise.
Manual PKI is the wrong control model once devices are deployed at scale. Spreadsheets and isolated certificate authority tools assume a manageable population and a human review cadence. That assumption breaks once devices are continuously added across cloud, edge, and legacy environments. The implication is that IoT governance has to move from exception handling to continuous identity operations.
Unknown or expired machine identities create identity blast radius. When one certificate outage can interrupt production, healthcare, or connected vehicle services, the impact is no longer limited to one device. A single weak trust point can become a service-wide dependency. Practitioners need to think in terms of blast radius, ownership, and revocation scope, not just device hygiene.
Crypto-agility is becoming part of identity governance, not just cryptography. IoT fleets can last longer than the cryptographic assumptions that originally protected them. That means trust programmes need a repeatable way to reissue identity across the fleet when standards or risk conditions change. The practitioner conclusion is simple: if a device cannot be reissued at scale, it cannot be trusted at scale.
Machine identity oversight now sits at the intersection of uptime, compliance, and network trust. IoT governance failures no longer remain confined to security teams because outages and regulatory proof obligations now sit on the same control plane. That convergence means IAM, infrastructure, and operational owners all need the same identity picture. The field should stop treating IoT security as a point solution and start treating it as shared trust infrastructure.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
IoT device trust is now a fleet identity problem. Programmes that treat connected devices as isolated endpoints will continue to miss the deeper issue, which is whether each device has a visible owner, a valid credential state, and a repeatable lifecycle. The control point has shifted from patching devices to governing machine identities as a persistent estate.
Certificate governance has to become operational, not periodic. When fleets span cloud, edge, and embedded systems, certificate expiry can no longer be managed as a calendar task. Teams need continuous discovery and renewal workflows that reflect the real pace of device onboarding and retirement.
Crypto-agility is a trust requirement for long-lived fleets. Devices outlive many of the cryptographic assumptions they ship with, so identity programmes need a path to reissue certificates and update algorithms without replacing the estate. That is the difference between maintaining device trust and merely documenting it.
For practitioners
- Build a unified device identity inventory Track every IoT certificate, device owner, and lifecycle state across cloud, edge, and legacy environments so trust gaps are visible before renewal or incident time.
- Automate certificate renewal and revocation Replace spreadsheet-driven expiry monitoring with automated issuance, renewal, and revocation for every device identity that can affect uptime or trust.
- Map devices to business-critical services Prioritise certificates attached to production lines, healthcare systems, connected vehicles, and other uptime-sensitive services where expiry becomes operational impact.
- Design for crypto-agility across fleets Plan for reissuing certificates and updating cryptographic settings at fleet scale so long-lived devices can keep pace with changing standards.
- Align IoT governance with broader NHI strategy Treat connected devices as part of the same machine identity estate as workloads and service accounts, with ownership, renewal, and offboarding controls linked together.
Key takeaways
- IoT security fails when organisations cannot govern the machine identities attached to every connected device.
- Outages and compliance pressure are symptoms of a deeper visibility and lifecycle problem across certificates and ownership.
- Automation, continuous discovery, and crypto-agility are the controls that make fleet-scale device trust manageable.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Expired and unknown device identities need governed retirement as fleets change. |
| NHI-05 — Overprivileged NHI | IoT devices often retain more trust than their current function requires. | |
| NHI-07 — Long-Lived Secrets | Long-lived certificates are central to the expiry and renewal risks described here. | |
| Recommendation — Track device offboarding so retired IoT identities do not remain trusted after use. Review IoT identity scope and reduce certificate trust to the minimum required service path. Shorten IoT certificate lifetimes where operationally possible and automate renewal. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issue, renewal, and revocation are authenticator lifecycle controls. |
| Recommendation — Apply authenticator management to automate IoT credential issuance, renewal, and revocation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing which devices are trusted and authorised. |
| Recommendation — Map IoT device trust decisions to PR.AA-05 and enforce entitlement scope across the fleet. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Weak IoT identities can give attackers access that is then used to move further into networks. |
| Recommendation — Map insecure devices to TA0006 and TA0008 so exposed credentials and movement paths are prioritised. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
- Continuous discovery: Continuous discovery is the ongoing process of detecting identities as they appear, change, or disappear across environments. For AI agents and other NHIs, it prevents inventory drift and keeps ownership, privilege, and lifecycle controls aligned with the live environment.
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.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org