A camera running three-year-old firmware sits on the same switch as the finance server. A cheap smart plug shares a subnet with a production line controller. Neither device was built with security in mind, and right now each one is a doorway into everything else on that network.

Segmentation is the least expensive risk reduction available to anyone running IoT gear. You don't need a second firewall cluster or a consultant on retainer to start. You need a device list, a maintenance window, and the discipline to write down what is actually allowed to talk to what.

Why a Flat Network Fails IoT Devices

Most IoT hardware is built to a price. It ships with default credentials, receives firmware updates for a year or two at best, and logs almost nothing useful. You cannot patch what the vendor abandoned, and you cannot monitor a device that reports nothing. What you can do is limit the blast radius when one of them turns hostile.

There are three practical problems with putting everything on one subnet:

  • Lateral movement. Once an attacker has a foothold on a camera, an ARP-level scan of the same broadcast domain hands them every other device for free.
  • Noise. Thirty cameras plus twenty smart devices generate constant discovery and multicast chatter that buries real alerts.
  • No policy surface. With one subnet, "what is this device allowed to reach" has exactly one answer: everything.

A VLAN separates the traffic. A firewall decides what crosses between them. You need both, and the firewall rules are where most projects quietly fail.

Inventory First, VLANs Second

Before touching a switch, walk the building. For every connected device, record its MAC address, which switch port or access point it uses, what it does, and who owns it. Cameras on the roof, a hub in the reception area, a PLC behind the panel — location matters because it affects cabling and wireless options later.

Then group devices by trust and function, not by convenience. A useful first pass:

  • Cameras and recorders
  • Consumer smart devices and hubs
  • Industrial or building controls (PLCs, HMIs, HVAC controllers)
  • Staff workstations and phones
  • Management interfaces for switches, access points, and the firewall itself
  • Guest and personal devices

Note which devices must communicate — camera to recorder, workstation to printer, HMI to PLC. That list becomes your allow rules. Skip this step and you will spend the migration guessing.

Designing VLANs for Cameras, Hubs, and Industrial Gear

Cameras and recorders

Give cameras their own VLAN with no route to the internet. Cameras need to accept connections from the recorder and from your management station, and they need outbound access to a time source. That is roughly the whole policy. If remote viewing is a requirement, prefer the recorder to broker it rather than opening each camera to the WAN.

Consumer hubs and smart devices

Group smart speakers, plugs, bulbs, and their hubs together. Expect trouble with discovery protocols: many of these devices advertise and find each other over multicast, which does not cross a VLAN boundary by default. The usual fix is to keep devices that must discover each other in the same VLAN, and rely on a multicast reflector only where you truly need it.

Industrial and building systems

Operational technology deserves its own segment, separate from cameras and offices. Keep safety-critical control traffic isolated, allow only the specific protocols and ports the equipment requires, and route vendor remote support through a jump host with multi-factor authentication rather than exposing a controller's web interface. If your OT network touches regulated or life-safety systems, bring in someone who does that work professionally before you change anything.

Writing Firewall Rules That Hold Up

Design the rule set around roles, not addresses. A camera subnet reaching a recorder subnet on the ports the vendor documents is a rule you can still read in two years. A list of forty individual IP pairs is not.

Start from default deny between all VLANs, then add only what the inventory says is needed. Practical habits that keep rule sets honest:

  • Write rules in both directions explicitly. An allowed return path is not the same as an open one.
  • Control egress, not just ingress. Many IoT compromises announce themselves as a device quietly reaching an unfamiliar external host.
  • Permit management traffic from one admin VLAN only, and never from the IoT segments.
  • Log denied traffic and review it weekly for the first month. It will show you what you forgot.
  • Where your switch supports ACLs, add a second layer so inter-VLAN traffic never reaches the firewall unless you intend it to.

A Migration You Can Run in an Afternoon

  1. Create the VLANs and assign subnets: management, cameras, smart devices, OT, staff, guest.
  2. Move ports to access mode one rack at a time, disable unused ports, and enable DHCP snooping and BPDU guard.
  3. Set up DHCP scopes, then give cameras and controllers static addresses or reservations so rules never break.
  4. Apply inter-VLAN default deny on the firewall before you plug anything into the new subnets.
  5. Add the allow rules from your inventory: recorder to cameras, HMI to PLC, admin VLAN to management interfaces.
  6. Map each wireless SSID to a single VLAN. Do not put IoT devices on the guest network unless they genuinely need nothing local.
  7. Test from a laptop on each VLAN. A scan from the smart device network should return nothing but its own subnet.
  8. Document the diagram, the subnet table, and every rule with a one-line reason.

The awkward parts

Printers, casting, and some hub-based devices depend on discovery that segmentation breaks. Decide early whether a feature is worth a firewall exception. Remote access belongs on a VPN into the management VLAN, not on a forwarded port. And resist over-segmenting: eight VLANs you can explain beat thirty nobody can troubleshoot at 2 a.m.

Keeping It Working

Segmentation is not a project you finish; it is a habit you maintain. Every time a device joins the network, someone should add it to a segment and decide what it may reach. Change default passwords, keep firmware current where the vendor still supports it, and review your deny logs after any incident or unexplained slowdown.

Start smaller than you think you need to. Move the cameras first, because the win is fast and visible, then the smart devices, then anything industrial with a professional's help. Even two VLANs and a default-deny rule between them put you ahead of most networks where a smart bulb can still see the payroll server.