IoT Security in the Enterprise: Managing the Attack Surface You Can't See
Every enterprise network today extends far beyond laptops and servers. Smart cameras, badge readers, HVAC controllers, printers, industrial sensors, medical devices, and a growing list of "smart" infrastructure now sit on the same networks as critical business systems. Most of them were never designed with enterprise security in mind — and most security teams don't have a complete inventory of what's actually connected.
This is the IoT security problem in one sentence: the fastest-growing part of the attack surface is also the least visible.
1. Why IoT Is a Different Kind of Risk
Traditional endpoint security assumes a few things: the device runs a known OS, can host an agent, receives regular patches, and has an owner who's accountable for it. IoT devices routinely break every one of those assumptions.
- No agent support — Most IoT firmware can't run EDR, antivirus, or monitoring agents.
- Infrequent or absent patching — Vendors often stop supporting firmware within a few years, if updates were ever pushed at all.
- Default credentials — A significant share of deployed devices still run factory-default or hardcoded credentials.
- Unclear ownership — A smart thermostat or badge reader is frequently deployed by facilities or operations teams, not IT — meaning security never gets visibility in the first place.
- Long device lifecycles — Industrial and building-management devices can stay in service for a decade or more, far outliving their security support window.
The result: a class of devices that is simultaneously hard to patch, hard to monitor, and hard to even find.
2. The Real-World Attack Path
IoT compromises rarely make headlines because a camera got hacked — they make headlines because the camera was the entry point into everything else. A typical attack chain looks like this:
- Discovery — Attacker scans for internet-facing IoT devices (via services like Shodan) or gains initial network access through phishing.
- Initial compromise — Default credentials, an unpatched CVE, or an exposed management interface gives access to a single low-value device.
- Lateral movement — Because IoT devices are frequently placed on flat networks alongside critical systems, the attacker pivots from the compromised device toward servers, databases, or OT (operational technology) systems.
- Persistence and impact — Ransomware deployment, data exfiltration, or — in industrial environments — physical process disruption.
The device itself is rarely the target. It's the weakest link used to reach something more valuable.
3. Common Vulnerability Classes in IoT Deployments
When assessing IoT environments, the same categories of weakness surface again and again:
Weak or hardcoded authentication — Default admin passwords, or credentials embedded directly in firmware that can't be changed.
Insecure firmware update mechanisms — Updates delivered over unencrypted channels, or without signature verification, allowing malicious firmware to be pushed.
Exposed management interfaces — Web UIs, Telnet, or SSH left accessible from the internet or from untrusted network segments.
Insecure communication protocols — Devices sending data in plaintext (MQTT, HTTP, proprietary protocols) rather than encrypted channels.
Lack of network segmentation — IoT and OT devices sharing VLANs with corporate IT infrastructure, removing any containment if a device is compromised.
Inadequate logging — Devices that don't generate audit logs, making post-incident investigation and even real-time detection nearly impossible.
4. Building an IoT Security Program
A mature approach doesn't try to bolt traditional endpoint security onto devices that can't support it. Instead, it treats IoT as its own risk category with dedicated controls.
Asset Visibility First You cannot secure what you don't know exists. Passive network discovery and traffic fingerprinting (rather than active scanning, which can crash fragile devices) should establish a full inventory: device type, firmware version, manufacturer, and network location.
Network Segmentation IoT and OT devices belong on isolated VLANs with tightly controlled, explicitly defined communication paths to the rest of the network — not implicit trust because they're "internal." A compromised camera should never be able to reach a domain controller.
Credential and Access Hardening Default credentials should be treated as a critical finding, not a minor one. Where devices support it, enforce unique credentials per deployment and disable unused management interfaces (Telnet, UPnP, unused web ports).
Firmware and Patch Governance Maintain a firmware inventory mapped to known CVEs, and establish a formal process for vendor patch tracking — because unlike servers, these updates are rarely automatic.
Continuous Monitoring, Not Point-in-Time Scans Behavioral monitoring — watching for anomalous outbound connections, unexpected protocol usage, or traffic to known malicious infrastructure — is often the only realistic detection method for devices that can't host security agents.
Vendor and Procurement Security Requirements Security requirements should be part of procurement decisions, not an afterthought after deployment: minimum patch support windows, ability to change default credentials, and documented secure update mechanisms.
5. Where Penetration Testing Fits
IoT-focused penetration testing differs meaningfully from standard web or network VAPT. It typically involves:
- Firmware extraction and static analysis for hardcoded secrets or backdoors
- Hardware-level interface testing (UART, JTAG) where physical access is in scope
- Radio and wireless protocol assessment (Bluetooth, Zigbee, proprietary RF)
- Network-level testing of how the device communicates and segments from the rest of the environment
The goal isn't just "can this device be exploited" — it's "if this device is exploited, what does that expose across the wider network."
6. Compliance and Regulatory Context
IoT security is increasingly a compliance requirement, not just a best practice. Frameworks and regulations such as the IoT Cybersecurity Improvement Act, ETSI EN 303 645, and sector-specific standards in healthcare and industrial environments are pushing organizations toward documented device inventories, patch management processes, and default-credential elimination — all of which also strengthen SOC 2 and ISO 27001 postures around asset management and third-party risk.
Closing Thoughts
IoT devices aren't going away — if anything, they're multiplying faster than most organizations can track them. The enterprises that manage this risk well aren't the ones trying to force traditional endpoint tools onto incompatible hardware. They're the ones that built visibility, segmentation, and monitoring around the reality of what these devices are: numerous, long-lived, and largely invisible to conventional security tooling — until something goes wrong.
Knowing what's connected to your network is the first step. Assuming you already know is usually where the risk begins.