IoT Security: Risks, Controls and What Actually Works

Quick Summary

• Most organizations cannot list their connected devices, and you cannot secure an inventory you do not have. 

• IoT devices commonly ship with default credentials, no patch path, and no ability to run security software. 

• The realistic control is isolation, not hardening, because the device usually cannot be hardened. 

• The risk is rarely the device itself. It is the route the device provides to everything else.

Why Is IoT So Hard to Secure? 

Conventional IT security assumes a device you can manage: install an agent, apply a patch, enforce a policy. Most connected devices fail all three assumptions. 

• No agent capability, so endpoint tooling cannot see them 

• Default credentials that are often documented publicly and rarely changed 

• Firmware that is updated infrequently, or never, or only by physical access 

• A vendor who may have discontinued support or gone out of business 

• Purchased by facilities or operations rather than IT, so nobody told IT they exist 

That last point is the one that causes most damage. A camera system bought by facilities and installed by an integrator is on the network, and IT often finds out during an incident. 

The device you cannot patch is bad. The device you did not know about is worse. 

This isn’t a hypothetical failure mode. It’s the exact mechanism behind the largest DDoS attack ever recorded: Cloudflare’s Q3 2025 DDoS Threat Report traced a record 29.7 Tbps attack to the Aisuru botnet, an estimated 1 to 4 million compromised routers, IP cameras, and DVRs, recruited almost entirely through default credentials and unpatched firmware. 

CISA’s guidance for small and medium businesses treats knowing what’s connected as a precondition for everything else, and its Cyber Essentials baseline starts from the same place. 

What Are the Actual IoT Security Risks? 

The risk is rarely the device itself. Nobody wants your thermostat. They want what your thermostat can reach. 

1. A device with default credentials is compromised, often by automated scanning rather than a targeted attack. 
2. The attacker now has a foothold inside the network perimeter. 
3. From there they scan for anything reachable, which on a flat network is everything. 
4. They move toward systems that hold data or can be encrypted for ransom. 
5. The originating device is never the target and is frequently never examined afterward. 

The scale of that last pattern is worth sitting with: Microsoft’s Digital Defense Report has found, consistently across multiple years, that more than 90% of ransomware attacks reaching the encryption stage used an unmanaged device as their initial access point or for the encryption itself. The device isn’t incidental to the attack, it’s usually the whole reason it worked. 

A secondary risk is availability. Building controls, access systems, and clinical devices are operational, so a failure is not an inconvenience, it is a stoppage. 

Pivot: using a compromised low-value device as a launch point to reach higher-value systems. It is the reason a camera on the same network as a file server is a business risk rather than a facilities one. 

Which Controls Actually Work for Securing IoT Devices? 

Since you usually cannot fix the device, the controls act on the network around it. That’s a different mindset from conventional endpoint security, and it’s the correct one here. 

Segmentation does the heaviest lifting. A camera network that cannot route to the finance server turns a compromise into a contained nuisance. 

Outbound filtering is the most commonly skipped. A sensor that only needs to reach one vendor endpoint does not need general internet access, and restricting it removes the command-and-control path, the same path Aisuru-class botnets depend on entirely. 

How Do You Build the Inventory in the First Place? 

This is where most programs stall, because the honest answer is that asking departments what they have connected does not produce a complete list. 

• Network discovery to find what is actually communicating, rather than what people remember buying 

• Reconcile against purchasing records for anything facilities or operations procured 

• Check for devices that only appear intermittently, such as contractor equipment 

• Record whether each device can be patched, and by whom 

• Record who owns it, because unowned devices never get remediated 

The output is not a list of devices. It is a list of devices with an owner and a patchability status, which is what makes the next decision possible. 

An estate inventory is the same artifact our free IT assessment produces for the wider environment, flagging end-of-life systems and unsupported versions alongside the connected devices most inventories miss. 

Where Does a Managed Provider Help? 

The work here is continuous rather than a project. Devices arrive, firmware changes, contractors connect equipment, and an inventory taken once is wrong within months. 

• Discovery running continuously rather than annually 

• Monitoring across the IoT segment, since endpoint tooling cannot cover it 

• Segmentation maintained as the estate changes 

• Documented evidence of compensating controls for anything unpatchable 

Detection matters disproportionately here because prevention is largely unavailable. Our Security as a Service covers that layer, and Managed IT 360 covers the estate these devices sit alongside. 

For an independent external view, eligible organizations can use CISA’s no-cost vulnerability scanning, which will surface exposed devices you didn’t know were reachable. 

Case Study: Asset Discovery at Global Scale 

Client environment: a global energy group, 10,000 employees across 36 countries. 

Problem: inconsistent asset visibility across a highly distributed estate. 

Solution: asset discovery and patch management deployed consistently. 

Result: cycle-time reduction on downtime events and consistency across all 36 countries. 

This evidences asset discovery capability at scale. It does not evidence an IoT-specific security engagement, and none is claimed. No sector-matched case study currently exists for this topic, and as with the hydraulics manufacturer example used elsewhere in this series, I wasn’t able to verify this figure against currently published content on the live site. 

FAQs

1 What counts as an IoT device on a business network? 

Anything connected that is not a conventional computer or server: cameras, printers and multifunction devices, building and HVAC controls, access control systems, smart displays, sensors, and medical or industrial equipment. If it has an IP address and cannot run your endpoint agent, treat it as IoT for planning purposes. 

2 Can we just put IoT devices on the guest network? 

It’s better than a flat network, and it’s not the same as segmentation. Guest networks are usually designed for internet access rather than for controlling east-west traffic, and many IoT devices need to reach internal systems to function. A dedicated segment with explicit rules is the more defensible answer. 

3 What if the manufacturer never releases firmware updates? 

Then hardening is off the table, and the answer is compensating controls: isolate it, restrict outbound access, monitor it more closely than anything else, and document the decision with a review date. That is a defensible position; an undocumented one is not. 

4 Who should own IoT device management, IT or facilities? 

One named owner, and in practice it works best with IT owning the network controls and facilities owning the devices, with a written agreement on procurement. The failure mode is both assuming the other has it.