IoT Networking: Connecting Devices Without Opening Holes

The device that never gets patched is already on your network

A modern enterprise runs on things that were never designed to be secure. Badge readers, HVAC controllers, IP cameras, conference-room displays, medical infusion pumps, warehouse scanners, building-management gateways, and shop-floor PLCs all speak IP now, and most of them ship with weak defaults, embedded credentials, and firmware that stops receiving updates years before the hardware is retired. A door controller installed in 2019 may still be running its factory image in 2029. That mismatch — a long physical life against a short security life — is the core reason IoT and OT devices are a liability, and it is why "just put them on the network" is the wrong instinct.

The right instinct is to assume every one of these devices will eventually be compromised, and to design the network so that when it is, the blast radius is a single zone rather than the whole business. This post walks through how we do that for clients: segmenting devices, controlling who and what can talk to them, watching their behavior, and choosing the right connectivity for each class of device.

Why IoT and OT devices are different

Traditional endpoint security assumes you can install an agent, push patches, and enforce policy from the operating system. None of that holds for most connected devices.

• Weak or hardcoded defaults. Shared admin passwords, Telnet left open, unsigned firmware, and management interfaces reachable from any host on the LAN.
• No patching path. Many vendors never ship updates, and the ones that do often require a maintenance window, a physical touch, or a support contract that lapsed. Vulnerabilities that would be closed in days on a server can stay open for the life of the device.
• Long, opaque lifecycles. OT gear is bought to run for a decade or more, often under warranties that void if you modify the software. You cannot treat a CT scanner or a building controller like a laptop.
• No agent, limited logging. You usually cannot install anything on the device, so visibility has to come from the network, not the host.
• Fragile protocols. Industrial protocols like Modbus and BACnet were built for trusted, isolated networks and have little or no authentication. An aggressive vulnerability scan can knock some of these devices offline.

Because you cannot fix the device, you have to fix its surroundings. That means the network does the work the endpoint cannot. If you want a broader view of how this fits with the rest of your defenses, our network security practice treats device isolation as a first-class design goal, not an afterthought.

Segment first: put devices in zones, not on the flat LAN

Segmentation is the single highest-leverage control for IoT and OT. The goal is to group devices by function and trust level, place each group on its own VLAN or network, and force all traffic between zones through a firewall that inspects and logs it. A compromised camera should be able to reach exactly the recording server it needs — and nothing else.

Figure: zoning by function and trust turns one compromised device into a contained incident instead of a foothold on the flat network.

A workable zoning model for most organizations looks like this:

1. Corporate zone — managed laptops and servers with full endpoint controls.
2. IoT zone — cameras, displays, sensors, and building systems, with no path to corporate hosts and tightly limited outbound access.
3. OT/industrial zone — PLCs, SCADA, and controllers, ideally following a Purdue-style model with a demilitarized layer between IT and the plant floor.
4. Guest/untrusted zone — anything you do not manage, fully isolated from the rest.

The Purdue reference model matters in OT because it defines clear levels between the enterprise and the process, so data moves up through controlled brokers rather than letting a corporate host talk straight to a controller. Even in a pure IT environment, the same principle — enforce a boundary between what you trust and what you cannot patch — is what keeps a printer or a camera from becoming a pivot point. Done well, this is a practical step toward zero trust: no device is trusted by virtue of its network location.

Know what is on the network: NAC and profiling

You cannot segment what you cannot see, and in most environments nobody has a reliable inventory of connected devices. Network Access Control (NAC) with device profiling solves both problems at once.

• Profiling and fingerprinting. NAC platforms identify devices by MAC OUI, DHCP fingerprint, traffic patterns, and active probes, then classify them — "Axis IP camera," "Siemens PLC," "Windows workstation." This becomes your live inventory and feeds attack surface management, which keeps that picture current as devices come and go.
• Dynamic assignment. When a device connects, NAC drops it onto the correct VLAN automatically based on its identity, so a camera plugged into any switch port lands in the IoT zone whether or not someone remembered to configure that port.
• Posture and authentication. Where devices support it, use 802.1X with certificates. Where they do not — which is common for IoT — fall back to MAC Authentication Bypass with tight profiling so an attacker cannot simply spoof a MAC and inherit a trusted device's access.

The practical payoff is that onboarding a new device becomes a policy decision, not a manual switch-port change, and a rogue or unrecognized device is quarantined by default instead of getting a free ride on the LAN.

Restrict the traffic: east-west and outbound

Segmentation defines the zones; traffic policy defines what is actually allowed across and out of them. Two directions deserve equal attention.

East-west (device to device). Most IoT and OT devices have no legitimate reason to talk to each other. A camera does not need to reach another camera; a thermostat does not need to reach a badge reader. Default-deny between devices and permit only the specific flows a device needs — a camera to its NVR on one port, a controller to its historian. This is where a lot of ransomware and worm activity dies, because lateral movement is exactly what tight east-west policy prevents.

Outbound (device to internet). This is the control people forget. A compromised device needs to reach a command-and-control server to become useful to an attacker, and it may try to exfiltrate data or join a botnet. Most IoT devices need very little outbound — perhaps NTP, a vendor update endpoint, and a cloud service on a known domain.

• Default-deny outbound and allow-list only required destinations and ports.
• Force DNS through a filtered resolver so you can block and log lookups to unknown or malicious domains.
• Treat any device beaconing to an unexpected host as an incident, not noise.

Watch behavior: monitoring the devices you cannot patch

Because you cannot put an agent on these devices, the network is your sensor. IoT and OT traffic is unusually predictable — a sensor reports on a fixed interval, a controller talks to the same two hosts — which makes anomalies stand out. Feed the telemetry from your segmentation boundaries and NAC into a SIEM and pair it with analysts who know what normal looks like.

• Baseline normal. Establish each device's typical peers, ports, protocols, and data volumes, then alert on deviation — new destinations, off-hours activity, or a spike in outbound bytes.
• Passive discovery. Use passive monitoring rather than active scans in OT, since probing fragile devices can disrupt them. Span/tap the traffic and analyze it out of band.
• Route to response. Detection only helps if someone acts. Wiring these alerts into managed detection and response means a beaconing camera at 2 a.m. gets isolated and investigated instead of sitting in a queue.

Connectivity options: match the link to the device

How devices connect shapes both the risk and the design. The right choice depends on power, range, bandwidth, and mobility.

• Wired Ethernet. Still the most secure and reliable option for fixed devices. Prefer it for cameras, controllers, and anything critical, and pair it with 802.1X where supported.
• WiFi. Convenient and high-bandwidth, but give IoT its own SSID mapped to the IoT VLAN — never the corporate or guest network. Use WPA2/WPA3-Enterprise where the device supports it, and enable client isolation so devices on the same SSID cannot see each other.
• Cellular (4G/5G). Ideal for remote or mobile devices and for keeping a fleet off your corporate network entirely. Use private APNs so devices land in a controlled segment rather than the open internet.
• LPWAN (LoRaWAN, NB-IoT, LTE-M). Low-power, long-range, low-bandwidth links for sensors and meters that send small payloads and run for years on a battery. Keep the gateway and its backhaul inside your segmentation model, and rely on the protocol's own encryption for the device link.

For distributed sites and mixed connectivity, an SD-WAN or global network fabric lets you carry each device class in its own segment across locations and enforce consistent policy no matter how the device physically connects.

Bringing it together

Securing IoT and OT is not about hardening devices you cannot change — it is about building a network that assumes they will fail and contains the damage when they do. Inventory and profile everything with NAC, segment by function and trust, default-deny east-west and outbound traffic, monitor behavior continuously, and pick connectivity that keeps each device class in its own lane. None of these steps is exotic, but they have to work together, and they have to be maintained as the device population changes.

If your connected devices are sitting on the same network as your servers and laptops, that is the first thing worth fixing. Contact our team and we will map your device landscape, design the zones, and stand up the monitoring so a compromised sensor stays a contained event instead of a way in.