Continue your mission
IoT devices introduce a category of security risk that traditional endpoint defenses cannot address. This article covers the core challenges of securing constrained hardware at scale, the Mirai botnet as the definitive case study, and the network-level defense strategies that actually work when agents cannot be installed.
# IoT Security Fundamentals
The Internet of Things (IoT) refers to the broad category of network-connected devices that are not general-purpose computers: IP cameras, industrial sensors, smart thermostats, building automation systems, medical monitors, consumer appliances, and embedded controllers of every description. IoT security is the discipline of protecting these devices, and the networks they touch, from unauthorized access, exploitation, and weaponization.
What makes IoT security a distinct field rather than a subset of standard endpoint security is a single structural reality: these devices typically cannot run traditional security agents. There is no endpoint detection and response (EDR) client you can deploy to a smart thermostat. There is no antivirus engine that fits in 64 KB of flash storage. The methods that protect laptops and servers are architecturally unavailable for most of the IoT device population. Security teams must therefore defend the environment around these devices rather than the devices themselves.
The scale of the problem is substantial. By 2025 there were more than 15 billion IoT devices connected to the internet globally, a number that continues to grow faster than any corresponding increase in security controls. Every one of those devices is a potential entry point, a potential botnet node, or a potential lateral movement vector into a broader network.
Understanding IoT security requires understanding why these devices are difficult to secure in the first place. The constraints are not oversights by lazy engineers; they are the direct result of design tradeoffs that made large-scale IoT deployment economically viable.
Hardware Constraints
Most IoT devices run on microcontrollers with severely limited CPU cycles and memory. A typical industrial sensor might have 256 KB of RAM and a processor running at 48 MHz. A low-cost IP camera might have 32 MB of RAM and a single-core processor designed for video encoding, not cryptographic operations. These constraints mean that computationally expensive security operations, including TLS handshakes with strong cipher suites, certificate validation, or on-device log analysis, can be impractical or impossible without dedicated security silicon.
Unencrypted Protocols
The protocols that IoT devices commonly use were often designed before network security became a priority. Telnet, used for remote management on early IP cameras and routers, sends credentials in plaintext. HTTP without TLS exposes configuration interfaces to anyone with network access. MQTT (Message Queuing Telemetry Transport), the publish-subscribe protocol widely used for IoT telemetry, supports transport security through TLS but defaults to port 1883 without encryption, and many deployments never configure the encrypted alternative on port 8883. Modbus, used in industrial control, has no authentication mechanism at all.
Default Credentials
Consumer and industrial IoT devices frequently ship with hardcoded or default credentials: admin/admin, admin/password, root/root. Manufacturers set these defaults for initial setup convenience and rely on end users to change them. In practice, a large fraction of deployed devices retain factory credentials throughout their entire operational life. This is the vulnerability class that enabled the Mirai botnet.
Patch Management Failures
Unlike enterprise software where patch deployment is an established operational discipline, IoT firmware updates face structural barriers. Many devices have no automatic update mechanism. Users receive no notification when a firmware vulnerability is disclosed. Applying an update often requires physical access or a configuration process that non-technical users cannot execute. Some vendors exit the business entirely, leaving their device populations permanently unpatched. The result is a global installed base of devices running firmware with known, published vulnerabilities, indefinitely.
Operational Lifecycles
Enterprise servers are replaced on three-to-five year cycles. IoT devices, particularly in industrial and infrastructure contexts, routinely remain in service for ten to twenty years. An IP camera purchased in 2012 may still be operational in 2032. A building automation controller installed in 2008 may not be replaced until the building is renovated. The security assumptions embedded in firmware from a decade ago bear no resemblance to the current threat environment.
The Mirai botnet, discovered in 2016, is the definitive case study in IoT security failure and remains instructive nearly a decade later.
Mirai's authors wrote a worm that systematically scanned the public internet for IoT devices with default Telnet credentials, using a hardcoded list of approximately 60 username/password combinations. Because so many devices shipped from the factory with credentials like admin/admin and never had them changed, Mirai successfully recruited over 600,000 devices into a botnet in a matter of weeks. The device population included IP cameras, DVRs, home routers, and various industrial sensors.
On September 20, 2016, this botnet launched a distributed denial-of-service (DDoS) attack against the security researcher Brian Krebs, generating traffic at 620 Gbps. On October 21, 2016, a Mirai variant launched an attack against Dyn, a major DNS infrastructure provider, generating peak traffic of approximately 1.2 Tbps. The Dyn attack disrupted DNS resolution for large portions of the internet, taking down Twitter, Netflix, Reddit, GitHub, Etsy, Spotify, and dozens of other major services for hours. These platforms were not themselves compromised; their DNS provider was overwhelmed, making them unreachable.
The aftermath made the situation worse. Mirai's source code was released publicly in late September 2016. This made IoT botnet capability a commodity; any attacker with modest technical skill could compile and deploy their own Mirai variant. Dozens of derivative botnets followed within months.
Mirai demonstrated that IoT security failures have consequences that extend far beyond the owner of the compromised device. A homeowner with a vulnerable IP camera is not just at personal risk; their device becomes a weapon used against unrelated third parties. The distributed nature of the harm creates a tragedy-of-the-commons dynamic: the individual cost of changing a default password feels low priority, while the collective cost of the industry's failure to require it is measured in internet-wide outages.
Network Segmentation
The most effective compensating control for IoT devices that cannot be patched or hardened is network segmentation. Placing IoT devices on a dedicated VLAN, isolated from corporate systems and the general enterprise network, limits the blast radius of a compromise. A vulnerable IP camera on an isolated IoT VLAN can be exploited without giving the attacker access to the file server or Active Directory domain on the corporate network.
Effective IoT VLAN design includes stateful firewall rules that permit specific required traffic flows (camera footage to the NVR, sensor data to the collection system) and deny all other lateral traffic. Default-deny egress policies prevent compromised devices from participating in outbound botnet activity or exfiltrating data. Access Control Lists (ACLs) should block IoT devices from initiating connections to other internal network segments.
Device Inventory and Profiling
You cannot protect devices you do not know exist. IoT environments frequently accumulate shadow devices: devices added to the network by facilities teams, vendors, or individual employees without IT or security involvement. Passive network discovery tools that identify devices by their MAC address OUI, protocol behavior, and traffic patterns can build an inventory without generating the active scan traffic that might disrupt sensitive equipment. Network Access Control (NAC) systems can enforce policies that prevent unregistered devices from reaching anything beyond a quarantine VLAN.
Firmware Update Processes
Where vendors provide firmware updates, organizations should establish a process to monitor for releases, test firmware in a staged environment, and deploy updates on a defined schedule. For devices where the vendor has exited the business or stopped issuing updates, organizations should document the unpatched state as an accepted risk with compensating controls, or plan accelerated device replacement.
Network-Level Monitoring
Because agent-based monitoring is unavailable on most IoT devices, detection must happen at the network level. Behavioral baselines for each device class establish what normal looks like: a temperature sensor should send small UDP packets to one collection endpoint at regular intervals. Deviation from this baseline, such as the sensor initiating outbound TCP connections to external IPs, or generating traffic volumes inconsistent with its function, is a detection signal. Security information and event management (SIEM) systems fed by network flow data (NetFlow, IPFIX) can apply these behavioral rules at scale.
NIST IR 8259
NIST Interagency Report 8259 establishes a baseline set of IoT device cybersecurity capabilities that manufacturers should build into devices and that organizations should require before procurement. The core capabilities include: device identification (unique identifiers for each device), device configuration (the ability to change credentials and disable unused network services), data protection (the ability to use cryptography for data at rest and in transit), logical access to interfaces (access controls for management interfaces), software and firmware updates (a mechanism for applying updates), and cybersecurity state awareness (the ability to report security-relevant events). NIST IR 8259A extends this with supporting non-technical activities including documentation and customer notification processes.
Zero Trust Architecture for IoT
Zero Trust Network Access (ZTNA) principles applied to IoT treat every device as untrusted regardless of network location. Each device is required to authenticate before accessing resources, and access is granted only to the specific resources the device legitimately needs, not to the broader network. For devices that cannot support certificate-based authentication, network-level controls (MAC address binding, 802.1X port authentication, or NAC policy enforcement) approximate the same outcome. The key principle is that network adjacency does not imply trust; IoT devices must earn access to each resource individually.
CDA's Vulnerability and Surface Defense (VSD) domain applies its Continuous Surface Reduction (CSR) methodology directly to IoT environments. CSR's core principle, "Every surface you expose is a surface we eliminate," maps cleanly onto IoT: every network service running on every device is attack surface. Default credentials running on Telnet are attack surface. An IP camera with an administrative HTTP interface exposed to the corporate LAN is attack surface. CSR-driven IoT work begins with a complete device inventory, classifies each device by risk tier, and systematically closes or controls every surface that is not operationally required.
The Security Posture and Hygiene (SPH) domain's Autonomous Posture Command (APC) methodology provides the ongoing monitoring function. Because IoT devices cannot self-report their security state, APC operates at the network level: continuous monitoring of traffic flows, automated alerting on behavioral anomalies, and regular posture assessments that verify segmentation controls remain intact. APC treats IoT network monitoring as a hygiene function, not a periodic audit: "Your posture adapts. Your hygiene never sleeps."
For organizations with large IoT deployments, CDA's approach combines CSR surface reduction through segmentation and inventory with APC-driven network monitoring to create a defense model that does not depend on agent deployment and does not require devices to be inherently secure.
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.