IoT Device Security: Why Forgotten Devices Are Your Biggest Risk
Printers, cameras, badge readers, sensors — the devices that get attacked first are the ones nobody put in the security org chart. Most IoT failures are governance failures with technical symptoms.
Most security programs are built for laptops, servers, and cloud workloads. The devices that get attacked first are usually none of those. They’re the printers, IP cameras, badge readers, and sensors nobody put in the security org chart.
Jim LaRoe, founder and CEO of Symphion, calls them “the top of Mount Everest of complexity” for IoT devices. On episode 94, he laid out the case in numbers: around 20% of enterprise endpoints are printers, roughly 99% sit at factory defaults, and Becker’s Healthcare reports cameras and printers as the top two IoT endpoints getting hacked across healthcare systems.
Why forgotten IoT devices keep getting owned
IoT devices break the assumptions traditional endpoint security is built on. They run proprietary operating systems, are configured through vendor-specific web UIs, can’t host an EDR agent, and are often deployed by facilities or supply chain rather than IT. The pattern that follows is consistent: they land on the network with the published admin password; they expose web servers, FTP, Telnet, and SNMP; they store credentials for adjacent systems; they keep working ten years past the last firmware update; and they reset to factory defaults the first time a technician services them.
Every one of those properties is well known to red teams. The same logic that breaks traditional perimeter assumptions shows up inside the trust boundary, where an unmanaged camera or printer becomes a pivot rather than a target.
Who actually owns IoT security
Most IoT failures are governance failures with technical symptoms. Procurement buys the device, IT runs the network it sits on, security owns the risk on paper — and nobody owns the hardening.
| Function | Who tends to own it | What goes wrong |
|---|---|---|
| Purchasing | Procurement | Security requirements get redlined out to hit pricing targets. |
| Deployment | Facilities, ops | Devices land with default credentials and no inventory entry. |
| Network | IT | Switches accept the device; no one validates outbound traffic. |
| Hardening | Often unassigned | Without an owner, the device runs as-deployed for its full life. |
| Risk acceptance | CISO | Gets the audit finding, but no budget code to remediate. |
LaRoe’s real example: a hospital system, a 15,000-printer fleet, a CISO who wanted the hardening program in the contract, and a group purchasing organization that redlined the security scope on its way to a five-year deal. The first move in any serious IoT program is naming the owner and giving that person authority to enforce a policy. Without that, the rest is theater.
Basic cyber hygiene for IoT
Most IoT compromise still comes from the basics — the devices aren’t falling to novel zero days. The non-negotiables for any device class: asset inventory (make, model, firmware, MAC, IP, location, owner); credential hygiene (replace the default, rotate, vault it); port and protocol minimization; firmware management; certificate management; configuration-drift monitoring to catch a technician’s factory reset; and outbound traffic control. Treat these as a baseline that covers IP cameras, badge readers, building management, and most OT the same way it covers printers.
Standards that apply
There’s more guidance than most teams realize. NIST issued NISTIR 8023 for replication devices, later folded into broader NIST IoT controls. For federal work — or just a hardening template — DISA STIGs cover dozens of device classes with concrete baselines. Pick one framework as your reference (NIST is the right default), map your device classes to it, and use STIG content where you need a concrete configuration target.
A seven-step program
- Discover — agentless scanning that catches additions within an hour, not a quarter.
- Classify — by data sensitivity, network reach, regulatory scope, and vendor support.
- Harden — no default password, minimal services, encrypted storage, walk-up controls.
- Patch — track firmware per device; replace unsupported models.
- Monitor — for drift, new arrivals, and unexpected outbound traffic, tied to a real owner.
- Remediate on a clock — re-harden the same day when drift is detected.
- Report — a board-ready, scored risk view with trend lines.
The point of writing it down is that the program survives turnover. One that depends on one engineer’s memory falls apart the first time they take vacation.
Why it’s a quick win
IoT security rarely competes for attention: the work is well scoped, the controls are understood, and the budget is small relative to the device count. Two hooks shift the conversation — a three-year program is far cheaper than the regulatory exposure of a single PHI or PCI incident traced to a camera; and it covers 20% of the endpoint estate that’s currently almost completely unprotected. The same least-privilege discipline we apply to product and infrastructure security belongs on a device that holds an LDAP password too. You don’t need to solve every IoT problem this quarter. You do need to put an owner on the program and start with the device class leaking the most credentials today.