What Is IoT Security? Risks and Best Practices

In October 2016 a botnet built from cameras, DVRs, and home routers knocked Twitter, Reddit, Spotify, and Netflix offline for hours. The malware, Mirai, did not crack anything. It logged in. It scanned the internet for devices still using factory-default credentials like admin/admin and root/12345, tried a short list of them, and enrolled every device that answered into a network it pointed at the DNS provider Dyn. The devices were not exotic. They were the cheap connected hardware sitting in homes and offices, shipped with a password nobody changed and an update mechanism nobody used.

IoT security is the practice of protecting that hardware: the internet-connected devices that sense, store, and move data but were never built to defend themselves. There are far more of them than there are laptops. IoT Analytics counted 18.5 billion connected IoT devices at the end of 2024 and projects roughly 39 billion by 2030. Each one is a host on the network with an IP address, an attack surface, and, very often, no agent, no patch cycle, and a default password. This guide covers what IoT security is, why the devices are so hard to defend, the attacks that target them, and the practices that actually contain the risk. It is written for the people who have to find these devices on their network and account for them: SOC analysts, threat hunters, and the engineers who own the asset inventory.

What is IoT security?

IoT security is the set of controls and practices that protect internet-connected devices, the data they handle, and the networks they sit on, from compromise and misuse. The "things" are physical objects with a processor, network connectivity, and usually a sensor or actuator: IP cameras, smart thermostats, badge readers, medical infusion pumps, factory programmable logic controllers, smart TVs, building HVAC controllers, networked printers. Anything that has an IP address and is not a general-purpose computer is, for defensive purposes, an IoT device.

What makes these devices a distinct security problem is not what they do. It is what they lack. A laptop runs an operating system you can patch, an endpoint agent you can deploy, and a user who can be trained. A connected thermostat runs vendor firmware you cannot inspect, has no room for an agent, ships from the factory with a known password, and may never receive a patch because the vendor stopped supporting it the year after it sold. The device works fine for a decade. Its security stopped at the moment it left the warehouse.

The defensive consequence is that IoT security is mostly about the network and the inventory, not the device. You usually cannot harden the thing itself. You can find it, isolate it, watch what it talks to, and limit what it can reach. That shift, from securing the host to securing everything around the host, is what separates IoT security from ordinary endpoint defense.

Why IoT security gets overlooked

The count is the first reason. When connected devices outnumber managed endpoints several times over, and most of them were bought by facilities, clinical engineering, or a line-of-business team rather than IT, the security team often does not know they exist. You cannot defend an asset you have never inventoried, and the unmanaged camera in a conference room is invisible until it shows up in netflow talking to an address in another country.

The second reason is ownership. A laptop has an owner, a build standard, and a lifecycle. A smart building sensor belongs to facilities, the infusion pump belongs to biomedical, the badge reader belongs to physical security, and none of those teams reads the same patch advisories the SOC does. The device is on the corporate network but outside the corporate process.

The third reason is that the devices are designed for cost and convenience, not defense. A market that competes on price has no incentive to fund a security team, a patch pipeline, or a secure-by-default configuration. The result is predictable: hardcoded credentials, unencrypted communication, firmware that cannot be updated, and debug interfaces left open. The device does its job. Defending it was never part of the spec.

The IoT attack surface

Every connected device adds to the attack surface: the total set of points where an attacker could enter or extract data. IoT devices expand it in ways managed endpoints do not, because they fail on dimensions a laptop has covered.

Credentials. Many devices ship with default or hardcoded usernames and passwords, documented in the manual and indexed by search engines. A device that cannot have its password changed, or that nobody changes, is an open door with a published key. This is the single most exploited IoT weakness.

Firmware. The firmware is the device's operating system, and on cheap hardware it is built without the protections a modern OS has, with no signed-update mechanism and no way to patch a discovered flaw. A vulnerability in firmware is often permanent for the life of the device.

Communication. Many devices send data, including credentials and sensor readings, in cleartext. Anything on the path can read it or alter it, which makes an on-path (man-in-the-middle) attack trivial against an unencrypted IoT protocol.

Exposure. Devices get plugged in and forgotten, frequently on the flat corporate network with full reachability to servers and workstations, and sometimes exposed directly to the internet through a misconfigured router or a manufacturer's cloud service. A device meant to be reachable only from the local network ends up reachable from anywhere.

Lifecycle. The device outlives its support. When the vendor stops issuing firmware, every flaw found after that date stays open forever, and the device keeps running because it still does its job.

Common attacks on IoT devices

The weaknesses above turn into a small set of recurring attacks. None of them are sophisticated. They do not need to be.

Recruitment into a botnet. The Mirai pattern: scan for devices using default credentials, log in, install malware, and add the device to a botnet that the operator rents out or aims. IoT devices are ideal botnet nodes because they are numerous, always on, rarely monitored, and never patched. Mirai's source code was published in 2016 and its variants are still active, because the supply of default-credentialed devices never ran out.

Distributed denial-of-service. The most common use of an IoT botnet is a distributed denial-of-service (DDoS) attack: point hundreds of thousands of devices at one target and drown it in traffic. The 2016 Dyn attack, which took major sites offline across the US, was a Mirai DDoS sourced from compromised IoT hardware. The devices themselves were collateral; the target was someone else.

Firmware and vulnerability exploitation. When a device exposes a vulnerable service, an attacker can exploit the firmware directly to run code, often with no authentication at all. Because the firmware cannot be patched, the only fix is to remove or isolate the device.

On-path interception. When a device talks in cleartext, an attacker positioned on the network reads or modifies the traffic: stealing the credentials a camera sends to its cloud, or altering the readings a sensor reports. Encryption closes this; most cheap devices do not use it.

Pivot into the network. The device is rarely the real target. It is the entry point. An attacker who owns a networked printer or a conference-room display on a flat network uses it as a foothold to reach the systems that matter, because the device sits inside the perimeter and nobody is watching it.

IoT security best practices

You cannot patch your way out of the IoT problem, because the devices often cannot be patched. The practices that work treat the device as untrusted and build the controls around it. They fall into four jobs: know what you have, isolate it, lock down what you can, and watch it.

Inventory every connected device. You cannot protect what you have not found. Discover IoT devices the same way you find any host, through passive network monitoring and active scanning, and keep a living inventory that records what each device is, who owns it, what it should talk to, and whether the vendor still supports it. The inventory is the foundation; every other control depends on it.

Segment the network. Put IoT devices on their own VLANs or segments, separated from servers, workstations, and each other, with firewall rules that allow only the traffic each device actually needs. Network segmentation is the highest-leverage IoT control because it accepts that the device will be compromised and limits what that compromise reaches. A camera that can only talk to its recording server cannot pivot to a domain controller.

Change defaults and disable what you do not need. Where the device allows it, replace default credentials with strong unique ones, turn off unused services and open ports, disable universal plug and play and remote management you do not use, and apply firmware updates when the vendor issues them. This is basic hardening, and on IoT it is often the only host-level control available.

Encrypt the traffic. Where the device or its gateway supports encryption, use it, so that credentials and sensor data are not readable on the wire. Where the device cannot encrypt, segmentation and monitoring have to carry more of the load.

Monitor device behavior. An IoT device has a narrow, predictable traffic pattern: a thermostat talks to one cloud endpoint, a camera to one recording server. That predictability is a gift. Baseline the normal behavior and alert on deviation, a camera suddenly scanning the internal network, a sensor beaconing to an unfamiliar address, a printer generating outbound traffic at 3 a.m. Because you usually cannot run an agent on the device, this monitoring lives on the network. Network detection and response tooling is built for exactly this: watching traffic for the devices that cannot watch themselves.

Plan for end of life. Track which devices the vendor still supports, and treat an unsupported device as a known liability: replace it, or isolate it tightly enough that its permanent vulnerabilities cannot be reached. A device that no longer gets firmware updates does not stop being a risk; it stops being a manageable one.

The defender's view: IoT in an investigation

For a SOC, IoT changes what the evidence looks like. The device cannot tell you what happened, because it has no agent and often no usable logs. The record of its compromise lives entirely in the network: the netflow showing a camera scanning a subnet, the DNS query to a command-and-control domain, the spike of outbound UDP that signals a DDoS in progress. An IoT investigation is a network investigation by necessity.

That is also why the inventory matters so much at investigation time. When an alert fires on traffic from an IP, the first question is "what is that device, and who owns it?" An asset record that answers in seconds turns an investigation into a containment action. An unknown device on a flat network turns it into an archaeology project. The work you do before an incident, finding the devices and segmenting them, is the work that makes the incident survivable.

The honest summary is that IoT security is risk management, not prevention. You will not make a cheap connected device secure. You can make sure it is known, contained, watched, and unable to reach anything that matters when, not if, it is compromised.

Frequently Asked Questions

What is IoT security?

IoT security is the practice of protecting internet-connected devices, the data they handle, and the networks they sit on. It covers everything from IP cameras and smart thermostats to medical devices and industrial controllers. Because these devices usually cannot run a security agent or be patched reliably, IoT security focuses on finding the devices, isolating them on the network, and monitoring their behavior rather than hardening the device itself.

Why are IoT devices so hard to secure?

IoT devices are built for cost and convenience, not defense. They commonly ship with default or hardcoded passwords, run firmware that cannot be patched, communicate without encryption, and outlive vendor support. They also rarely have room for an endpoint agent, and they are often bought and managed by teams outside IT, so the security team may not even know they exist.

What was the Mirai botnet?

Mirai was malware that built a botnet from IoT devices like cameras and home routers by scanning the internet for devices using factory-default credentials and logging in. In October 2016 a Mirai botnet launched a massive distributed denial-of-service attack against the DNS provider Dyn, knocking major sites offline across the United States. Its source code was published, and variants remain active because default-credentialed devices are still common.

What is the best way to protect IoT devices?

Network segmentation is the highest-leverage control. Put IoT devices on isolated network segments with firewall rules that allow only the traffic each device needs, so a compromised device cannot reach servers or workstations. Pair that with a complete device inventory, changed default credentials, encryption where supported, and network-based monitoring of device behavior.

How do you find IoT devices on a network?

Discover them the same way you find any host: passive network monitoring to see what is talking, and active scanning to identify what responds. The goal is a living inventory that records what each device is, who owns it, what it should communicate with, and whether the vendor still supports it. You cannot protect or isolate a device you have not inventoried.

Why can't you just patch IoT devices?

Many IoT devices have no mechanism to update their firmware, ship with no security support, or are abandoned by the vendor while still in service. Even when patches exist, the device may have no owner tracking advisories. Because patching is unreliable, IoT defense leans on controls around the device, segmentation, monitoring, and least-reachability, rather than fixing the device.

What is IoT security monitoring?

IoT security monitoring watches a device's network behavior for deviation from its normal pattern, since most IoT devices cannot run a security agent. An IoT device usually has a narrow, predictable set of connections, so a baseline is easy to establish, and anything outside it, internal scanning, beaconing to unknown addresses, unexpected outbound traffic, is a strong signal. This monitoring typically runs on the network through tools like network detection and response.

The bottom line

IoT security protects the connected devices that now outnumber managed endpoints several times over and that were never built to defend themselves. The devices ship with default credentials, unpatchable firmware, cleartext communication, and a support window that ends long before they are unplugged. Those weaknesses turn into a predictable set of attacks: recruitment into botnets, DDoS, firmware exploitation, on-path interception, and pivoting deeper into the network.

You cannot fix the device, so you manage the risk around it. Inventory everything connected, segment it so a compromise cannot spread, change what defaults you can, encrypt where possible, and monitor behavior on the network because the device cannot monitor itself. For a defender the discipline is concrete: know what is on the network, contain it, and watch it, so that when a cheap connected device is compromised, it stops at the device instead of becoming the start of the incident.