IoT Network Security: How to Protect Connected Devices on Your Network

Most IoT devices cannot run a traditional endpoint security agent due to resource constraints, making the device population largely unmanaged and agentless from the network’s perspective. NAC’s posture-checking model and automated vulnerability scanning both assume a device can actively report compliance, a structural mismatch rather than a simple coverage gap.

If your vulnerability scanner and NAC system never seem to actually see some of your IoT devices, this explains exactly why, and what to do about it.

Why Are IoT Devices Genuinely Different from a Laptop or Server on Your Network?

Here’s the organizing insight most competitor content skips entirely, treating IoT devices as simply “more endpoints to secure the same way.” Most IoT devices are resource-constrained by design. They physically cannot run a traditional endpoint security agent the way a managed laptop or server can, making the device population largely unmanaged and agentless from the network’s own perspective.

Here’s why this genuinely breaks assumed tooling coverage. Automated vulnerability assessments, standard IT audit processes, and NAC’s own posture-checking model each assume a device can meaningfully report or be actively scanned for its own compliance status. A device that cannot run an agent and was never designed for that kind of introspection sits genuinely outside what those tools were built to cover, not because someone configured something wrong, but because the assumption baked into the tool never applied to this device category in the first place.

The patching reality deserves direct naming too. The overwhelming majority of deployed IoT devices have no automatic update mechanism at all, requiring a manual process, locating a firmware file, logging into a device’s own web interface, uploading it, that realistically never happens for consumer devices and rarely happens for commercial installations. A vulnerability the manufacturer patched months ago can remain exploitable on the installed base for years, simply because nobody performed the manual steps required to apply it.

Why IoT Devices Break Traditional Security Tooling Assumptions

Assumption	True for Managed Devices	True for Most IoT Devices
Can run an endpoint agent	Yes	No, resource-constrained
Can self-report compliance to NAC	Yes	No, lacks reporting capability
Receives automatic patches	Usually	Rarely, requires manual firmware upload
Appears in standard vulnerability scans	Yes	Often missed or unrecognized

Mirai and Its Descendants — a Case Study That Is Still Active in 2026

Mirai, discovered in August 2016, with its source code publicly released that September, exploited a list of default and hardcoded credentials via Telnet and SSH to compromise IoT devices at internet scale. It assembled them into a botnet used for some of the largest DDoS attacks recorded at the time.

Here’s why this remains genuinely current rather than purely historical. Mirai’s own source code has spawned numerous active successor families still operating in 2026, including variants that have achieved dramatically greater scale than the original. The Aisuru family, built on the Mirai framework but substantially evolved, reached a record 29.7 Tbps of DDoS capacity in the third quarter of 2025, drawing on somewhere between one and four million infected devices, mostly routers, DVRs, and IP cameras. An even larger 31.4 Tbps burst followed that November. Attack volumes this large simply didn’t exist when Mirai first emerged.

This connects directly to the DDoS defense discussion elsewhere. IoT botnets built from exactly this pattern remain one of the primary real-world sources of the volumetric traffic that traffic-scrubbing and anycast-absorption defenses specifically exist to handle. Every one of those record-breaking attacks started with the exact same weakness: a device somewhere, running a default credential nobody ever changed.

Default Credentials — the #1 Ranked Risk, and Why Traditional Tools Structurally Miss It

The OWASP IoT Top 10 explicitly ranks weak, guessable, or hardcoded passwords as the single most critical IoT vulnerability category, sitting above every other listed risk.

Why does this remain unresolved nearly a decade after Mirai first exposed it at scale? Setting a genuinely unique credential per device requires either a per-device provisioning step during manufacturing or a forced-change mechanism in firmware, both adding cost manufacturers competing on razor-thin margins routinely resist. This problem compounds with every already-deployed legacy device sitting in the field, since regulation cannot retroactively fix hardware that’s already shipped and installed.

Here’s the genuinely precise, honest technical gap worth naming directly. Default credential exposure is often not caught by automated vulnerability assessment, standard IT audit, or compliance scanning specifically because most affected devices are unmanaged and run without any agent at all. This is a structural blind spot, not a tooling failure someone forgot to configure correctly.

The Shadow IoT Problem — Inventory and Discovery

Organizations routinely have far more IoT devices connected to their network than they’re formally aware of, a genuine, direct parallel to the shadow IT problem already familiar elsewhere in this discussion, except applied to physical, connected hardware rather than unsanctioned software.

Network-based discovery is the practical response worth stating directly. Since many IoT devices cannot be relied upon to self-report the way a managed endpoint can, passive, network-based device fingerprinting and discovery becomes the practical, necessary starting point for building a genuinely accurate inventory, rather than assuming existing documentation is complete. A smart thermostat someone installed two years ago and forgot about, a camera a facilities team added without telling IT, a printer with WiFi capability nobody realized was network-connected at all, none of these show up in a spreadsheet nobody’s updated. They show up when you actually look at what’s talking on your network.

IoT-Specific Segmentation — the Direct Payoff of Post 5’s Own Deferral

A dedicated IoT segment, technically isolated using the same VLAN mechanisms already familiar from general segmentation practice, is the foundational step. But isolation from the general business network alone is not sufficient.

Here’s the genuinely important extension worth developing. IoT devices should, where feasible, also be isolated from each other using the same client isolation principle already introduced for wireless guest networks. A compromised device should not be freely able to reach and compromise its neighbors on the same IoT segment either.

Why does this matter with particular force given the Mirai pattern already covered? Segmentation is precisely what limits a single compromised device’s ability to scan for and recruit other vulnerable devices on the same network, directly closing the specific lateral-scanning behavior that made Mirai’s own spread so effective in the first place. Mirai didn’t just compromise one device and stop; it used that foothold to scan for and recruit its neighbors. A network where compromised devices can’t see or reach their neighbors turns that same self-propagating pattern into a dead end instead of an infection chain.

MUD — Letting the Network Enforce What the Manufacturer Says a Device Should Do

Here’s genuinely new, differentiated technical content most competitor IoT security articles never mention at all. Manufacturer Usage Description, defined in IETF RFC 8520, allows a device manufacturer to publish a file describing that specific device’s own intended, legitimate network communication pattern, which hosts and ports it should ever genuinely need to reach. A MUD-capable network controller can then use that file to automatically construct and enforce a tight, device-specific access list.

Here’s why this is genuinely valuable, worth understanding properly rather than skimming past. Rather than requiring a network administrator to manually define access policy for every single device type individually, guesswork most IT teams don’t have time for, MUD shifts that specific, technical knowledge to the party best positioned to provide it accurately: the manufacturer itself. A smart camera’s manufacturer knows exactly which cloud endpoints that camera legitimately needs to reach for firmware updates and video streaming. That’s information no network administrator could reasonably reconstruct on their own for every device they’ve ever deployed.

The honest, direct limitation worth naming rather than overselling: MUD’s own real-world adoption across the IoT manufacturing industry remains genuinely uneven, and academic research has identified specific gaps in how thoroughly MUD’s own protections are enforced in practice. It should be treated as one valuable, complementary layer within a broader segmentation and inventory discipline, not a complete, standalone solution capable of solving IoT security on its own. Cyber Security Solutions Ltd evaluates MUD-capable infrastructure selectively, specifically for device categories where manufacturer support is genuinely mature, rather than treating it as a blanket answer across an entire device fleet.

The Regulatory Landscape — What’s Changed Recently

The UK’s Product Security and Telecommunications Infrastructure Act, enforced from April 29, 2024, bans universal default passwords on consumer IoT devices sold in the UK and requires manufacturers to provide a public point of contact for vulnerability reporting.

California’s SB-327, an earlier US precedent worth naming briefly, took effect in January 2020 as the first US state law requiring IoT devices to ship with unique passwords or force a password change on first use.

The EU Cyber Resilience Act is worth naming as current and directly relevant given its imminent timeline. Adopted in 2024, its reporting obligations for actively exploited vulnerabilities begin September 11, 2026, requiring manufacturers to provide security updates for a defined support period.

IoT Regulatory Landscape

Regulation	Jurisdiction	What It Requires	Status
UK PSTI Act	United Kingdom	Bans universal default passwords, requires vulnerability reporting contact	Enforced since April 29, 2024
California SB-327	California, US	Requires unique passwords or forced password change on first use	Effective since January 2020
EU Cyber Resilience Act	European Union	Reporting for actively exploited vulnerabilities, defined support periods	Reporting obligations begin September 11, 2026

Here’s the honest, practical caveat worth closing on. These regulations apply to newly manufactured devices going forward, not the billions of already-deployed legacy devices that will remain in service, and often vulnerable, for years or decades regardless of what new law now applies to devices shipping today.

Where IoT Meets OT — a Brief, Honest Boundary

Operational Technology and Industrial Control Systems, PLCs, SCADA, manufacturing equipment, are a related but genuinely distinct category from the IoT devices covered throughout this guide, with their own full, dedicated treatment elsewhere.

Recent industry research has documented a significant rise in ransomware activity specifically targeting OT systems, with lateral movement from compromised IoT devices into adjacent OT environments increasingly named as a genuine, growing risk at exactly this boundary. Worth understanding the distinction exists, without treating IoT guidance as a substitute for the specific discipline OT and ICS environments genuinely require.

How Do You Secure IoT Devices on Your Network Step by Step?

1. Build a genuine, network-based device inventory rather than relying on existing documentation, given how commonly shadow IoT devices go unrecorded.
2. Change every default credential on every discovered device immediately, treating this as the single highest-priority action given its ranking as the #1 OWASP IoT risk.
3. Segment IoT devices onto their own dedicated network zone, isolated from the general business network.
4. Apply client isolation within that IoT segment specifically, preventing device-to-device lateral scanning of the kind Mirai itself relied on.
5. Evaluate MUD-capable network infrastructure specifically for device types where manufacturer-published usage descriptions are genuinely available.
6. Confirm any newly procured devices meet current regulatory baseline requirements, UK PSTI Act compliance or equivalent, as a genuine, non-negotiable procurement criterion going forward.
7. Monitor IoT segment traffic specifically for the scanning and unusual outbound volume patterns already established as botnet indicators.

Conclusion

IoT security isn’t a matter of applying the same playbook to more devices; it genuinely requires accounting for a device population that can’t report on itself, patch itself, or defend itself the way a managed laptop can. Inventory what’s actually connected, kill every default credential, and segment aggressively. If you want help finding out exactly what’s quietly sitting on your network right now, Cyber Security Solutions Ltd can walk through it with you.