← All Posts

Segmenting IoT and OT Devices: An Addressing Plan for Cameras, Badge Readers, and Everything You Don't Trust

One of the most widely told stories in network security involves a casino, a lobby aquarium, and a smart thermometer. The thermometer kept the water comfortable and reported readings over the casino's Wi-Fi, and according to the security firm that investigated, attackers used it as their way in: they compromised the thermometer, moved from it to systems deeper inside, and left with a database of the casino's biggest-spending customers. To the staff, the thermometer was an appliance. To the network, it was a trusted computer, free to start a conversation with anything else in the building, because nobody had told the network otherwise.

That thermometer belongs to a category the technology industry calls IoT, the Internet of Things: everyday objects that carry a network connection, such as security cameras, smart TVs, thermostats, video doorbells, printers, and conference-room gadgets. Its industrial cousin is OT, or operational technology, the equipment that controls physical processes: badge readers and the door controllers behind them, HVAC (heating, ventilation, and air conditioning) systems, elevator controllers, and factory machinery. The two categories share an inconvenient set of habits. They ship with old software and rarely receive updates, they cannot run the security tools you would install on a laptop, many arrive with a factory password printed in the manual, and they stay in service for a decade or more. A laptop gets patched every month, while a badge reader installed in 2015 may still be running the software it shipped with, and the vendor that wrote that software may no longer exist.

The deeper problem lives in how networks treat these devices. Out of the box, most networks are flat, meaning every device joins one shared pool of addresses and can start a conversation with any other device in the pool. On a flat network, nothing stands between the aquarium thermometer and the payroll server, and nothing stops a compromised camera from knocking on every door in the building to see what answers. Security people call that follow-on knocking lateral movement: break into the weakest device, then travel sideways toward something valuable. The set of things one compromised device can reach is often called its blast radius, an idea our guide to right-sizing subnets explores from the design side, and on a flat network the blast radius is everything you own.

Segmentation shrinks the blast radius by drawing borders inside your own network. Instead of one big shared space, you run several smaller networks, sorted by how much you trust what lives in each, with a firewall checking any traffic that tries to cross between them. The standard tool for the job is the VLAN (virtual local area network), a feature built into ordinary business network switches that splits one physical network into several isolated ones without any new wiring. Devices on the same VLAN talk among themselves as usual, while traffic between VLANs has to pass through a router or firewall, which is exactly where you want it, because that is where rules can be enforced. Our guide to VLANs and VRFs covers the machinery in detail. The picture to keep in mind is an office building: a flat network is one enormous open-plan floor, and a segmented network is the same floor divided into rooms, where every doorway checks a badge.

The question that organizes the entire plan is simple to ask about any device: what does this thing actually need to talk to? A security camera needs to send video to the NVR (network video recorder), the machine that stores camera footage, and it needs nothing else. A badge reader needs to report swipes to the access-control server that decides who gets in. A smart TV needs the internet for streaming and firmware updates. The HVAC controller needs its vendor's cloud service. A visitor's phone needs the internet and absolutely nothing of yours. Read that list again and notice what is missing: almost nothing on it needs to reach anything else on it. Devices group naturally by need, and each group becomes a segment.

With the groups chosen, the addressing plan almost writes itself. Internal networks draw their IP (Internet Protocol) addresses, the numbers that identify each device, from the private ranges set aside for exactly this purpose, which our tour of the 10 reserved IP ranges covers. Here we will carve everything out of 10.60.0.0/16, one convenient block of that private space. The slash notation describes how big each network is, and a /24 holds 254 usable addresses; our visual guide to subnetting explains how to read it. The one deliberate flourish is that each segment's VLAN number reappears inside its addresses, a readability trick borrowed from our worked IP plan example, so anyone glancing at an address like 10.60.50.31 knows instantly that it belongs to a camera.

Segment VLAN Subnet What lives there
Staff2010.60.20.0/24Laptops, desktops, and phones of people you employ
Servers3010.60.30.0/24The NVR, the access-control server, file and print servers
Cameras5010.60.50.0/23Every security camera, and only cameras
Door hardware6010.60.60.0/24Badge readers, door controllers, intercoms
Building systems7010.60.70.0/24HVAC controllers, smart thermostats, energy meters
Gadgets8010.60.80.0/24Smart TVs, conference-room gear, sensors, the aquarium thermometer
Guest Wi-Fi9010.60.90.0/23Every visitor's phone and laptop

A few of the sizes deserve a word. Cameras get a /23, twice the usual space with 510 usable addresses, because camera counts only ever grow: every renovation and every incident review adds a few more, and renumbering a full segment later is miserable. Guest Wi-Fi gets the same generosity because phones outnumber people. Everything else fits comfortably in a /24 with room to spare, and if you want to sanity-check any of these ranges, our free subnet calculator will do the arithmetic for you. The pattern matters more than the particular numbers: pick a scheme where the address itself announces the trust level, and troubleshooting gets easier for the rest of the network's life.

Segments alone accomplish nothing until the firewall between them has opinions. The right starting opinion is deny everything, which sounds drastic and is actually the entire point: traffic between segments is forbidden unless a rule permits it, and the permitted list turns out to be remarkably short.

The entire between-segment rule set, in plain English

default: deny all traffic between segments, then allow:

cameras          → servers     video streams to the NVR, nothing else
door hardware    → servers     badge swipes to the access-control server
staff            → servers     everyday office traffic
staff            → cameras     viewing feeds, changing settings
building systems → internet    the HVAC vendor's cloud service
gadgets          → internet    streaming and firmware updates
guest            → internet    and nothing of yours at all

Each rule is a one-way door. Staff can open a connection to a camera to watch a feed, and the camera's replies flow back through the connection staff opened, but the camera can never open a fresh connection toward the staff segment on its own. That single property defuses the casino scenario: a compromised camera can still send video to the NVR, because the rules allow that, and every other knock it attempts dies at the firewall, which will happily log the attempt so you know something is wrong. Notice also what the rules leave out. The gadgets segment reaches the internet and nothing internal, so the thermometer that started this story could have been compromised all day long without ever finding a path to a database.

Firewall rules name addresses, so any device a rule mentions needs an address that never changes. Most devices receive their address automatically from DHCP (Dynamic Host Configuration Protocol), the service that hands out addresses as devices join, and for laptops and guest phones that churn is exactly right. For cameras, badge readers, and servers, use DHCP reservations, standing instructions that a particular device always receives the same address, so the rules built on those addresses stay true; our guide to DHCP, static, and reservations walks through which devices deserve which treatment. While you are deciding, point our free port scanner at one of your cameras. Seeing how many doors a security camera leaves open tends to convert people to segmentation faster than any article can.

All of this assumes you know what is on your network, and that assumption fails more often than anyone likes to admit. Before drawing borders, take an inventory: the DHCP lease list, the switch's table of connected devices, and a careful scan will surface every camera you forgot, the vending machine nobody realized was online, and the TV in the lobby that has been quietly reachable since the day it was mounted. If you have inherited a network with no documentation at all, our guide to building an IP inventory from scratch covers that dig in detail. Segmentation applied to a partial inventory leaves every forgotten device behind in the old flat network, still able to reach everything.

When migration day comes, move one category at a time rather than rebuilding the network in a weekend. Cameras make the best first move, because their needs are the clearest and a camera that goes quiet is annoying rather than dangerous. Gadgets and guest Wi-Fi come next, and each move will surface a device that misbehaves, like a conference-room display that turns out to need a connection to a scheduling server nobody documented; every one of those surprises becomes a rule you now know to write down. Save the door hardware for last, schedule it during business hours, and have the access-control vendor reachable, because a mistake in that segment locks actual doors on actual people.

A segmented network carries more moving parts than a flat one: seven subnets instead of one, a VLAN map, a page of reservations, and a rule set whose logic lives partly in the firewall and partly in someone's memory. Writing it all down is what lets the design survive staff turnover. This is the job IPCraft was built for: each segment becomes a subnet with a name and a description stating its trust level, every camera and badge reader becomes an address entry with custom fields for vendor, model, and firmware version, and utilization tracking, covered in our guide to subnet capacity planning, warns you when the camera segment starts running out of room. The payoff arrives with the next headline vulnerability: when researchers announce a flaw in a camera brand, the full list of your affected devices, with addresses and locations, is one search away instead of one week away.

The same design scales down to an apartment, where the untrusted population is smart plugs and a robot vacuum instead of badge readers, and our home lab addressing guide shows the small-scale version of these walls. At any scale, the goal is the same quiet outcome. The gadgets keep working, the guests keep browsing, the cameras keep recording, and the next compromised thermometer finds itself in a small room with the door locked, alone with the fish.