Blog | CloudSilicon Cybersecurity Insights

Ask most IT managers how many endpoints they're responsible for, and they'll give you a number that covers laptops, servers, and phones. Ask how many devices are actually talking on the network, and the honest answer is usually "more than that, and we're not entirely sure how many more." The gap between those two numbers is shadow IoT, and it has quietly become one of the largest unmanaged attack surfaces in the average business network.

The scale problem is bigger than most inventories admit

Industry research on this has been remarkably consistent for years: roughly a third of organizations in the US, UK, and Germany report more than 1,000 shadow IoT devices connected to their network on a typical day, and more recent device-visibility research puts the average enterprise network at somewhere around 35,000 connected devices spanning roughly 80 distinct device types — badge readers, IP cameras, building management and HVAC controllers, smart TVs and conference room hardware, VoIP handsets, networked printers and scanners, warehouse and point-of-sale hardware, and increasingly, connected medical equipment in healthcare settings. Recent analyses of enterprise device fleets have also found that a large share of assets — over 40% in some studies — are effectively agentless, meaning there's no way to install traditional endpoint security software on them at all, and that networks commonly carry dozens of devices that would be classified as high-risk or outright banned under most security policies if anyone were actually looking.

None of this is a hypothetical category of risk. It's already deployed, already networked, and in most SMB and mid-market environments, already largely invisible to whoever owns the security budget.

Why IoT is structurally harder to secure than a laptop fleet

This isn't a training or discipline problem the way phishing susceptibility is — it's an architectural one, and it's worth being specific about why.

Constrained firmware, no agent support. Most IoT and OT devices run stripped-down embedded operating systems with no capacity to run an EDR agent, antivirus, or any conventional endpoint tool. Whatever visibility you have into a laptop's behavior, you typically don't have into a badge reader or an HVAC controller — security has to be applied at the network layer instead, which most flat SMB networks aren't built to do.

Default and hardcoded credentials. A large share of IoT devices ship with default administrative credentials that are never changed after installation, often because the installer was a vendor technician, not internal IT, and nobody followed up. This is not a theoretical weakness — it's the exact mechanism the Mirai botnet used to build a network of hundreds of thousands of compromised IoT devices in 2016, scanning the public IPv4 address space for devices still using factory-default Telnet credentials. The resulting botnet was large enough to launch a distributed denial-of-service attack against DNS provider Dyn that generated over 1 terabit per second of traffic and knocked major internet services offline. Nearly a decade later, default-credential exploitation of consumer and small-business networking gear is still an active technique in nation-state and criminal campaigns alike.

Firmware update cycles measured in years, not weeks. A laptop gets patched on a monthly cadence through the same management tooling as everything else. A building access control panel or an industrial sensor might get a firmware update once a year, if the vendor is still supporting that model at all — and physical/operational infrastructure devices routinely stay in service for a decade or more, well past the point most manufacturers keep shipping security patches for them.

No local administration, no logging visibility. Many IoT devices have minimal or no local logging, and what logging exists often isn't forwarded anywhere a SOC would see it. An attacker who gains a foothold on one of these devices can frequently operate for extended periods without generating the kind of signal that would trigger an alert on a managed endpoint.

How attackers actually use IoT footholds

The pattern is consistent across incident reports: IoT devices are rarely the final target. They're the entry point or the pivot.

Initial access via internet-exposed devices. Devices left reachable from the public internet with default or weak credentials get discovered by automated scanning within hours, not months — this is exactly the reconnaissance pattern Mirai and its many derivatives are built around, and it remains a standard technique for compromising small-office network gear as a stepping stone toward larger targets.

Lateral movement through flat networks. Once inside, an attacker who's compromised a low-value IoT device uses it as a pivot point to reach higher-value systems on the same network segment. This only works because so many business networks still put IoT, guest, and core corporate traffic on the same flat network with no segmentation between them — the printer and the finance server are one hop apart because nobody ever separated them.

Botnet recruitment for DDoS and further scanning. Compromised IoT devices are frequently recruited into botnets used for outbound attacks against other targets — meaning your compromised smart TV or IP camera can make your business complicit infrastructure in an attack on someone else, with the reputational and bandwidth consequences that involves, even if no data was ever taken from you directly.

Long-term persistence. Because these devices are rarely reimaged, rarely monitored, and rarely even rebooted, a foothold established on one can persist for a very long time compared to the same foothold on a managed workstation that gets patched, scanned, or replaced on a normal refresh cycle.

The segmentation gap is usually the real root cause

Most of the risk above collapses down to one architectural decision: whether IoT devices sit on the same broadcast domain as everything else that matters. In a properly segmented network, a compromised badge reader or thermostat can reach almost nothing of value — its blast radius is limited to other devices on its own VLAN, with tightly restricted egress rules controlling what it can talk to even within that segment. In a flat network, the same compromised device can potentially reach file servers, domain controllers, and endpoints directly.

Network Access Control (802.1X or equivalent) that authenticates devices before granting network access, dedicated VLANs for IoT and OT traffic separate from corporate IT, and default-deny egress rules for those segments (a smart thermostat has no legitimate reason to be able to initiate a connection to your accounting server, or in most cases, to the general internet at all) are the specific controls that turn "we have thousands of unmanaged devices" from a critical exposure into a contained one.

Building an actual IoT security program

Start with discovery, not policy. You cannot secure or segment what you don't know exists. Passive network discovery tools that fingerprint device types from traffic patterns are the practical starting point for most organizations, since manual asset inventories reliably undercount IoT by a wide margin.

Segment before you try to patch everything. Given how inconsistent vendor patch cycles are for embedded devices, network-layer containment is a faster and more reliable risk reduction than chasing firmware updates across dozens of device types and manufacturers.

Change default credentials as a deployment standard, not an afterthought. This should be a mandatory step in any IoT or OT device installation checklist, including devices installed by third-party vendors or contractors, not just ones IT racks itself.

Monitor at the network layer. Since most IoT devices can't run an agent, network traffic analysis and NDR (network detection and response) tooling that can flag anomalous behavior from a device that's never behaved that way before is often the only realistic detection mechanism available.

Extend vendor risk management to IoT and OT suppliers. The same due diligence applied to SaaS vendors — what data can this touch, what's their patch and disclosure history, what happens if it's compromised — should apply to the vendors supplying your cameras, building systems, and connected hardware.

Why this is turning into a compliance question too

Cyber insurers and auditors are increasingly asking about network segmentation and device inventory as part of underwriting and renewal, not just endpoint protection. For businesses handling health information or payment data through connected devices — networked medical equipment, POS terminals, connected diagnostic hardware — the exposure isn't just operational anymore; it intersects directly with sector-specific compliance obligations around safeguarding that data, since a compromised device is a viable path to the records those regulations are meant to protect.

The businesses that get caught out here are rarely the ones with no IoT footprint — that's essentially nobody at this point. It's the ones who never inventoried it, never segmented it, and found out how big the gap was during an incident instead of before one.