IoT attack volume and device vulnerability outpace enterprise control

At a glance

What this is: This is a breakdown of IoT security statistics showing that attack volume, device vulnerability, and unsupported firmware are already outpacing many enterprise controls.

Why it matters: It matters to identity and security teams because connected devices expand the practical attack surface, create unmanaged access paths, and make segmentation, inventory, and patch governance central to risk reduction.

By the numbers:

• Connected devices now number over 21 billion globally and are projected to reach 39 billion by 2030.
• More than 50% of all IoT devices contain critical vulnerabilities that attackers can exploit immediately.
• Routers account for over 75% of all IoT-related cyberattacks.

Context

IoT security is fundamentally a governance problem because connected devices are often deployed faster than they can be inventoried, segmented, patched, or retired. As the device estate grows, the organisation inherits more unmanaged entry points, more embedded credentials, and more operational dependencies that conventional endpoint-led controls do not fully cover.

The first-order issue is not simply device count. It is whether teams can maintain device visibility, enforce access boundaries, and distinguish trustworthy connected assets from unmanaged or unsupported ones across IT, OT, and IoMT environments. That is where IoT becomes an identity-adjacent control problem as much as a network problem.

Key questions

Q: What breaks when smart devices are integrated without lifecycle governance?

A: The environment becomes dependent on fragile pairings, repeated manual reintegration, and unclear ownership of trust. When vendors update software or change device behaviour, security teams can lose visibility into which devices are still trusted, how they were approved, and whether they remain legitimate.

Q: Why do insecure IoT devices create broader enterprise risk?

A: Because once connected devices are inside a trusted environment, they can be used as entry points, persistence platforms, or sources of false data. Weak passwords, poor patching, and unclear ownership turn a single device into a systemic exposure. The risk is amplified when devices support operational systems, where disruption can affect revenue, safety, or service continuity.

Q: What are the signs that IoT segmentation is failing in practice?

A: Warning signs include camera traffic that suddenly scans subnets, talks to new internal hosts, or reaches services outside its normal video-management path. Another signal is when segmentation depends on exceptions, manual ACL growth, or MAC-based NAC workarounds. Those patterns show that policy is being maintained by memory and process rather than enforced by the network.

Q: How should organisations prioritise IoT remediation when device counts are high?

A: Prioritise devices that are both exposed and difficult to patch, especially routers, cameras, and unsupported controllers. Then focus on assets that sit at the boundary between business networks and operational systems, because those devices offer the highest likelihood of initial access and the widest downstream impact.

Technical breakdown

Why IoT devices become durable entry points

IoT devices frequently ship with fixed firmware, limited authentication, and weak update paths, which means their exposure window can remain open far longer than traditional endpoints. In practice, a vulnerable router, camera, or controller can become a persistent foothold because it is always on, always reachable, and often not monitored with the same rigor as user-managed assets. Unsupported firmware is especially problematic because it converts a fixable weakness into a permanent one. The issue is not just vulnerability count, but whether the device can ever be brought back into a governed state.

Practical implication: identify devices that cannot be patched or supported and remove or isolate them before they become permanent access paths.

How segmentation limits the blast radius of IoT compromise

Segmentation works by preventing a compromised device from talking freely to the rest of the environment. For IoT, that matters because the device estate often mixes business systems, operational technology, and identity-adjacent infrastructure such as access controls and cameras. Without strict network boundaries, an attacker who lands on a low-trust device can pivot toward higher-value systems, including management planes and sensitive data stores. Zero trust principles apply here not as a slogan, but as a practical constraint on east-west movement and device-to-device trust.

Practical implication: place IoT and OT devices into tightly scoped network zones with explicit allowlists for required communication only.

Why inventory and ownership are the real control plane for IoT

You cannot secure what you cannot enumerate. IoT environments fail first at inventory because device type, location, ownership, firmware status, and communication behaviour are often unknown or stale. That breaks patching, policy enforcement, and incident response, because teams cannot tell which devices are exposed, which are business-critical, or which are already beyond support. In identity terms, this is a lifecycle problem: if the device is not onboarded, assigned, maintained, and eventually decommissioned under governance, it behaves like an unmanaged identity with standing access to the network.

Practical implication: maintain authoritative asset records for every connected device and tie them to ownership, risk tier, and support status.

Threat narrative

Attacker objective: The attacker wants a low-friction foothold that enables broader access, operational disruption, or theft from higher-value systems behind the device.

1. Entry typically begins through an exposed or unsupported IoT device such as a router, camera, or controller with a known vulnerability.
2. Attackers then abuse the device's trust position or flat network placement to move toward adjacent systems and operational assets.
3. The impact is data theft, disruption, ransomware, or sabotage, with the device acting as the initial access path rather than the final target.

Breaches seen in the wild

• Verkada camera breach 2021: Admin credentials on Verkada's exposed Jenkins support server let hackers into a support interface and customer cameras at 97 customers.

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 security is now an access-governance problem, not only a device-hygiene problem. The article's numbers show that volume, vulnerability, and unsupported firmware are combining to create an environment where devices behave like semi-persistent identities with network reach. That means security teams must think in terms of trusted onboarding, ownership, and lifecycle control, not only vulnerability scans. Practitioners should treat connected devices as governed access participants, not passive hardware.

Unsupported firmware is the clearest example of controllable risk turning into structural exposure. Once a router or camera can no longer receive patches, the organisation has effectively accepted a permanent exception that attackers can wait out. That is a governance failure because the exposure outlives the remediation option. Teams should stop assuming patching alone can close the risk when the support lifecycle has already ended.

Device visibility is the named concept that separates resilient IoT programmes from fragile ones. Without an authoritative inventory, teams cannot assign risk, enforce segmentation, or prove that controls apply to the right asset. Visibility must include device type, firmware state, communication paths, and owner, otherwise every downstream control is operating on incomplete assumptions. Practitioners should make visibility the prerequisite for every other IoT security decision.

High-density sectors need zero trust boundaries that reflect device reality, not organisational charts. Healthcare, manufacturing, and energy all have dense fleets that mix operational, clinical, and business devices on the same infrastructure. The practical implication is that trust zones should be built around device function and exposure, then continuously validated, rather than inherited from broad VLAN design or flat network conventions.

What this signals

Device visibility is the programme-level control that determines whether IoT risk can be governed at all. When organisations cannot reliably enumerate connected devices, every other security activity becomes partial, reactive, or outdated. The operational response is to make inventory, ownership, and support status part of the security control plane rather than an asset-management afterthought.

Zero trust only becomes meaningful for IoT when network boundaries reflect device trust, not convenience. High-density environments such as healthcare and manufacturing cannot rely on flat connectivity and hope to contain compromise. Security leaders should expect segmentation, traffic baselining, and continuous validation to do the heavy lifting across connected-device estates.

For practitioners

• Build a complete connected-device inventory Classify every IoT, OT, and IoMT asset by owner, firmware status, exposure level, and business criticality so patching and segmentation decisions are based on facts, not discovery drift.
• Isolate unsupported and high-risk devices first Move routers, cameras, and controllers that cannot be patched or replaced into restrictive zones with minimal east-west access and explicit communication allowlists.
• Map device communications before enforcing policy Use passive monitoring to identify normal device-to-device traffic, then build network rules around actual communication patterns rather than assumptions about how the environment should behave.
• Tie device ownership to remediation accountability Assign each connected device to a responsible team and require support status, patch cadence, and retirement dates so no asset remains in an unmanaged state.

Key takeaways

• IoT risk is accelerating because device growth, attack volume, and unpatchable firmware are expanding faster than many governance models can absorb.
• Connected devices can function as persistent entry points when inventory, ownership, and support status are incomplete or stale.
• The most effective response is to tighten device visibility, isolate unsupported assets, and enforce segmentation around real communication patterns.

Key terms

• IoT Attack Surface: The total set of connected devices, interfaces, and pathways that can be reached or exploited in an environment. In practice, it includes managed and unmanaged endpoints, embedded systems, and shadow devices that extend trust boundaries beyond what teams can see.
• Unsupported Firmware: Device software that no longer receives security patches or vendor support. Once firmware reaches this state, known vulnerabilities often become permanent exposure, so the device must be isolated, replaced, or accepted as an enduring risk exception.
• Application Segmentation: Application Segmentation is the separation of application components and their communications into tightly controlled trust zones. It reduces lateral movement by allowing only the required service-to-service paths. Defenders define approved flows, enforce policy at network or host controls, and review exceptions so compromised services cannot spread to adjacent tiers or shared data stores.
• Connected App Inventory: Connected app inventory is the authoritative record of which external applications, automations, and services have been granted access to an environment. It is a control foundation for SaaS and NHI governance because untracked connections create blind spots in authorisation, monitoring, and revocation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity for practitioners who need to connect access control to the wider identity estate. It gives security and identity teams a shared vocabulary for governing devices, services, and ephemeral access paths across the programme.