IoT Device Security: Why the Forgotten Devices on Your Network Are the Biggest Risk

Printers, cameras, and other IoT devices are the most overlooked endpoints in the enterprise. Here is the seven-step program for IoT device security that actually works.

The Forgotten Endpoint Class

Most security programs are built for laptops, servers, and cloud workloads. The devices that get attacked first are usually none of those. They are the printers, IP cameras, badge readers, and sensors that 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 of The Security Podcast of Silicon Valley, he laid out the case in numbers. Around 20% of enterprise endpoints are printers. Roughly 99% of those sit at factory defaults. Becker's Healthcare reports cameras and printers as the top two IoT endpoints getting hacked across healthcare systems.

If you want a real IoT device security program rather than a slide on the strategy deck, the work starts with the devices you already own and forgot.

Why Forgotten IoT Devices Keep Getting Owned

IoT devices break the assumptions that traditional endpoint security is built on. They run proprietary operating systems. They are configured through vendor-specific web UIs and APIs. They cannot host an EDR agent. They are often deployed by facilities, biomed, or supply chain, not by IT.

The pattern that follows is consistent.

  • They land on the network with the published administrator password.

  • They expose web servers, FTP, Telnet, SNMP, and proprietary management ports.

  • They store credentials for adjacent systems, including email, file shares, and directories.

  • They keep working for ten years past the last firmware update.

  • 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 Endpoint Security

Most IoT failures are governance failures with technical symptoms. LaRoe describes the typical pattern: procurement buys the device, IT runs the network it sits on, information security owns the risk on paper, and nobody owns the hardening.

Here is the ownership matrix that usually sneaks into mature organizations.

Function

Who tends to own it

What goes wrong

Purchasing

Procurement, supply chain

Security requirements get redlined out of contracts to hit pricing targets.

Deployment

Facilities, biomed, ops

Devices land on the network with default credentials and no inventory entry.

Network connectivity

IT

Switches accept the device. No one validates outbound traffic or segmentation.

Hardening and patching

Often unassigned

Without explicit owner, the device runs as-deployed for its full lifetime.

Risk acceptance

CISO or IS team

They get the audit finding, but no budget code to remediate.

LaRoe gives a real example: a hospital system, a 15,000-printer fleet, a CISO who wanted Symphion's program in the contract, and a group purchasing organization that redlined the security scope on its way to a five-year managed print agreement. The CISO had no juice over a procurement category that the supply chain had owned for a decade.

The first move in any serious IoT device security program is naming the owner and giving that person the authority to enforce a policy. Without that, the rest of this article is theater.

What Basic Cyber Hygiene Looks Like for IoT

Most IoT compromise still comes from the basics. The devices are not falling to novel zero days. They are falling to choices the manufacturer and the customer both made years earlier. The good news is the controls are well understood.

The non-negotiables for any IoT device class:

  • Asset inventory. Make, model, firmware version, MAC, IP, location, and an explicit owner.

  • Credential hygiene. Replace the published default password, rotate, and store credentials in a vault rather than the device's own UI.

  • Port and protocol minimization. Disable FTP, Telnet, weak SNMP versions, and any service that is not in active use.

  • Firmware management. Track current vs supported firmware. Remove or segment unsupported devices.

  • Certificate management. Many devices ship with self-signed or expiring certificates; treat them like server certificates.

  • Configuration drift monitoring. Detect when a service technician resets a device to factory and re-harden it the same day.

  • Outbound traffic control. Decide whether the device gets to phone home to the manufacturer at all.

Treat these as a baseline that applies to every IoT class on the network, not as a printer-only checklist. The same controls cover IP cameras, badge readers, building management systems, and most production OT in the same way.

Standards That Apply: NIST and DISA STIG

There is more guidance available than most teams realize. NIST issued NISTIR 8023 in 2015 specifically for replication devices, including printers, scanners, and copiers. That guidance was later folded into broader NIST publications and now applies to most networked devices through the standard NIST IoT and cybersecurity controls.

For organizations that work with the federal government or want a hardening template anyway, the DISA Security Technical Implementation Guides ("STIGs") cover dozens of device classes with concrete configuration baselines. Symphion bakes both into its customer programs because the same controls that satisfy a federal STIG mostly satisfy commercial regulators too.

The practical pattern: pick one framework as your reference (NIST is the right default for most organizations), map your device classes to it, and use STIG content where the NIST controls need a concrete configuration target.

A Seven-Step Program for IoT Endpoint Hygiene

Translating standards into operations is where most programs stall. Here is the structure LaRoe runs at customer sites, generalized so it works for printers, cameras, and any other unmanaged device class.

  1. Discover. Use agentless network scanning to find every device on every subnet. Catch additions within an hour, not a quarter.

  2. Classify. Bucket each device by risk: data sensitivity, network reach, regulatory scope, and whether the manufacturer still supports it.

  3. Harden. Apply the baseline configuration: no default password, minimal services, encrypted storage where supported, walk-up access controls.

  4. Patch. Track firmware versions per device. Apply patches on a schedule. Replace unsupported devices.

  5. Monitor. Watch for configuration drift, new device arrivals, and unexpected outbound traffic. Tie alerts to a real owner.

  6. Remediate on a clock. When drift is detected, including the technician-resets-to-default pattern, re-harden the same day under standing change control.

  7. Report. Give leadership a board-ready risk view that they can act on. Plain English, scored, with trend lines.

The point of writing it down is not the artifact. The point is to make the program survive turnover. A program that depends on one engineer's memory falls apart the first time that engineer takes vacation.

Why IoT Device Security Is a Quick Win

Most security investments compete with each other for attention. IoT device security usually does not. The work is well scoped, the controls are well understood, and the budget is small relative to the volume of devices it covers. The hard part is naming an owner and getting procurement, IT, and IS to operate from the same playbook.

Two practical hooks that usually shift the conversation:

  • Cost framing. A three-year all-in program is materially cheaper than the regulatory exposure for any single PHI or PCI incident traced back to a printer or camera.

  • Quick-win framing. 20% of the endpoint estate, currently almost completely unprotected, with controls that already exist in standards. The same least-privilege discipline that gets applied to AI agents and human users belongs on devices that hold LDAP credentials too. The same missing authorization layer that makes other systems brittle shows up in IoT as nobody has explicit authority to enforce a policy.

You do not need to solve every IoT problem in the first quarter. You do need to put an owner on the program, agree on the framework, and start with the device class that is leaking the most credentials today.

Listen to the Episode

Jim LaRoe is the founder and CEO of Symphion, a Dallas-based cybersecurity firm that has been in business since 1999. Symphion runs print fleet cybersecurity programs for organizations with up to 30,000 printers and broader IoT deployments at over 150,000 endpoints. He sat down with Jon McLachlan (co-founder of YSecurity and Cyberbase.ai) on Episode 94 of The Security Podcast of Silicon Valley.

The full conversation walks through the company's path from a 1999 CMDB project for a Dallas-Fort Worth alpha customer through to its current cyber hygiene as a service offering, including the politics that come with selling security into a category historically owned by procurement.

Listen to the full episode for Jim's view on why the cameras and printers nobody talks about will keep being the easiest way into the network until someone makes them somebody's job.

What are IoT endpoints?

What is IoT device security?

What are the biggest IoT security risks?

How do you secure IoT devices at scale?

Meet the hosts

Jon McLachlan

Co-Founder, YSecurity & Cyberbase

Questions founders and engineers actually ask, with decisions not theater.

Questions founders and engineers actually ask, with decisions not theater.

Sasha Sinkevich

Co-Founder, YSecurity & Cyberbase

Pushes past surface answers into architecture, tradeoffs, and what scales.

Pushes past surface answers into architecture, tradeoffs, and what scales.

The Security Podcast of Silicon Valley

jon@thesecuritypodcastofsiliconvalley.com

The Security Podcast of Silicon Valley

jon@thesecuritypodcastofsiliconvalley.com