How to Segment IoT Devices on a Business Network

Table of Contents

• Why IoT Devices Belong on Their Own Network Segment
• Inventory and Classify Every Connected Device
  • Discovery: find devices you did not know were there
  • Classification: group by function, risk, and owner
  • The three questions that set the rules
• Configuring IoT VLAN Configuration on Switches and Access Points
  • Handling Devices That Cannot Support VLAN Tagging
• Writing IoT Firewall Rules That Enforce Least Privilege
  • Start with default-deny between zones
  • Sample allowlist for a camera VLAN
  • Shared service allowlists
  • Logging and review
• Building an IoT Network Security Policy You Can Maintain
• Scaling IoT Segmentation Across Multiple Locations
• Testing and Rolling Back Your IoT Segmentation Before You Go Live
• Frequently Asked Questions

Why IoT Devices Belong on Their Own Network Segment

Most business networks were built for laptops, phones, and servers. Cameras, sensors, badge readers, and smart printers were added later, often by different vendors without much planning.

Network segmentation means dividing your network into separate zones and controlling which zones can talk to each other. Applying these strict boundaries across diverse environments highlights the fundamental importance of network segmentation, especially when managing the complex connectivity requirements found in hospitality settings.

Many IoT devices ship with default passwords, rarely get firmware updates, and cannot run security software, making them easy targets.

Segmentation gives you three practical benefits:

• Containment: A compromised device cannot reach trusted systems.
• Visibility: Traffic from IoT devices is easier to monitor because it has its own path. To see how camera traffic affects the network, read how security cameras impact network performance.
• Control: You can set firewall rules that allow only the connections each device actually needs.

Watch out: a device that is “isolated” but still allowed to reach the whole internal network gives you little protection.

Inventory and Classify Every Connected Device

You cannot protect devices you do not know about. Start with a complete inventory before changing any network settings, not just a list, but a risk-ranked list with an owner for every entry.

Discovery: find devices you did not know were there

Use at least two independent sources, because each one misses different devices:

• DHCP lease tables on your router or DHCP server show every device that received an address. Export and sort by MAC vendor (the OUI) to spot device types.
• Switch MAC address tables show what is physically plugged into each port, even with static IPs. Walk the table port by port against floor plans.
• Wireless controller client lists show Wi-Fi devices, their SSIDs, and signal strength. Flag devices on the corporate SSID that should not be there.

It is common to find 10-20% more devices than the IT team expected. Treat every unknown device as suspect until someone can explain what it is, who owns it, and why it is connected.

Classification: group by function, risk, and owner

Group devices by what they do and what happens if they are compromised, not by brand. A practical classification uses three inputs:

1. Function: surveillance, access control, environmental control, building automation, office peripherals, medical or lab equipment, guest/unknown.
2. Risk score: rate each device on (a) internet exposure, (b) sensitive data, (c) firmware updatability, and (d) control of physical access or safety systems. A 1-3 scale per factor sorts devices into high, medium, and low risk.
3. Owner: a named person or role (facilities, security, IT, department head) who approves network access and owns the device lifecycle.

Device Group	Examples	Typical Risk	Suggested Zone
Video surveillance	IP cameras, NVRs	High (internet-facing, large data flows)	Camera VLAN
Access control	Badge readers, door controllers	High (controls physical entry)	Access VLAN
Environmental	Thermostats, sensors	Medium	Building VLAN
Office peripherals	Printers, smart displays	Medium	Office IoT VLAN
Guest or unknown	Anything unverified	High until verified	Quarantine VLAN

The three questions that set the rules

For each device, answer:

• What does it need to talk to? (recorder, controller, cloud endpoint, time server)
• Who needs to reach it? (administrators, vendor support, nobody)
• Can it receive updates? (if not, strictest rules and a replacement date)

Record the answers in a spreadsheet or IPAM tool alongside make, model, IP, MAC, firmware version, location, and owner. Devices that cannot be updated or explained get the strictest rules and a replacement plan.

Configuring IoT VLAN Configuration on Switches and Access Points

VLANs (virtual local area networks) let one physical switch carry several logical networks.

A typical small business uses four to six VLANs: corporate, servers, guest Wi-Fi, cameras, access control, and general IoT. The count depends on your device groups.

On a managed switch, the basic steps are:

1. Create the VLANs. Assign each a clear name and ID, such as VLAN 30 for cameras.
2. Set access ports. Ports connecting single devices should be untagged members of one VLAN only.
3. Set trunk ports. Ports connecting switches or access points carry the needed VLANs as tagged traffic.
4. Assign native VLANs carefully. Avoid using a trusted VLAN as the native VLAN on any trunk.
5. Disable unused ports. Put them in a quarantine VLAN or shut them down.

On wireless access points, create a separate SSID for IoT devices and map it to the IoT VLAN.

Check the work with a test device on each VLAN. Confirm it gets an address in the correct subnet and cannot reach the others.

Handling Devices That Cannot Support VLAN Tagging

Some older or low-cost devices cannot handle VLAN tags. They expect untagged traffic on a single network.

Dedicate a physical switch port to a single VLAN and set it as an untagged access port.

Where a device cannot be segmented at all, put it behind a firewall or dedicated switch with strict rules, and plan to replace it, an unisolatable device is a standing risk.

Writing IoT Firewall Rules That Enforce Least Privilege

Segmentation only works when firewall rules control what crosses between zones. The guiding principle is least privilege: allow only the connections each device needs, and deny everything else. The practical challenge is that “everything else” is a long list, so you need a repeatable template.

Start with default-deny between zones

Begin with a default-deny policy between every IoT VLAN and every trusted network (corporate, servers, management). Then add narrow allow rules. On most business firewalls, the rule order is:

1. Specific allow rules (most specific first).
2. Broader allow rules for shared services (DNS, DHCP, NTP).
3. Default deny between zones.
4. Default deny from IoT zones to the internet, except explicitly allowed destinations.
5. A final deny-all rule at the bottom.

Order matters. Put specific allows above broad denies, and keep a final deny-all rule at the bottom so nothing falls through.

Contact Us For Free Estimate →

Sample allowlist for a camera VLAN

A camera VLAN typically needs only a handful of connections:

• Allow camera traffic to the NVR on a specific IP and port (for example, TCP 554 for RTSP).
• Allow the camera to reach the NTP server (UDP 123).
• Allow the NVR to reach the vendor’s update server over HTTPS (TCP 443) if cloud updates are required.

A sample rule set, written in plain terms:

1. Permit: Camera VLAN to NVR at 10.30.5.10, TCP 554 (RTSP).
2. Permit: Camera VLAN to NTP server at 10.10.1.5, UDP 123.
3. Permit: Camera VLAN to DNS resolver at 10.10.1.10, UDP/TCP 53.
4. Permit: NVR to vendor update endpoint (specific FQDN or IP range), TCP 443.
5. Deny: Camera VLAN to Corporate VLAN, any port.
6. Deny: Camera VLAN to Servers VLAN, any port.
7. Deny: Any VLAN to Camera VLAN, any port, except the NVR above.
8. Deny: Camera VLAN to internet, any port, except rule 4.

Shared service allowlists

Every IoT zone needs a small set of shared services. Build these once and reuse them:

• DNS: allow IoT zones to your internal resolver only, not public DNS. This keeps queries visible and blocks DNS tunneling.
• DHCP: allow IoT zones to your DHCP server or relay. Skip if devices use static IPs.
• NTP: allow IoT zones to your internal time server. Accurate time is required for certificate validation and log correlation.

Logging and review

Enable logging on deny rules between IoT zones and trusted networks. Review denied traffic weekly for the first month after go-live, then monthly. A spike in denied traffic from an IoT zone can indicate a misconfigured device or an active compromise.

Review rules quarterly. Remove rules for devices that no longer exist, and tighten any rule allowing more than one port or destination. Keep a change log with dates and names.

Building an IoT Network Security Policy You Can Maintain

Technical controls fail without a written policy that someone owns. Your IoT network security policy should be short enough to read and specific enough to act on.

Cover five areas:

• Onboarding: Every new device is inventoried, assigned a zone, and approved before it connects.
• Credentials: Default passwords are changed before deployment. No shared accounts.
• Updates: Devices that support firmware updates are updated on a set schedule; devices that cannot be updated are flagged for replacement.

Assign one person as the owner. In a small business, this is often the IT lead or an outside integrator.

A common mistake is writing a policy once and never revisiting it. Schedule a review at least twice a year.

Scaling IoT Segmentation Across Multiple Locations

Multiple sites add complexity. Each location may have different equipment, and staff may not be able to visit every site often.

Use the same VLAN numbering, naming, and subnet plan at every location. For a full guide, see scaling security systems for multiple locations.

Manage firewall policy centrally where your equipment allows it.

Plan site-to-site traffic carefully. To see how integrated security is handled at critical infrastructure locations, see integrated security for critical infrastructure sites.

For multi-site deployments, a phased rollout works better than a single cutover. Pilot one site, fix what breaks, then repeat the process.

Testing and Rolling Back Your IoT Segmentation Before You Go Live

Test every change before you apply it to production.

Build a simple test plan:

1. Confirm addressing. Each test device gets an IP in the correct subnet.
2. Confirm required traffic. Cameras reach the recorder, readers reach the controller, sensors report to their hub.
3. Confirm blocked traffic. Test devices cannot reach corporate or server networks.
4. Confirm internet behavior. Devices reach only the update and time servers they need.
5. Confirm monitoring. Denied traffic appears in logs.

Make a rollback plan before you start. Save current switch and firewall configurations and note how to restore them.

Watch out: a rule that blocks the wrong traffic can stop an access control system and lock people out.

After go-live, watch logs for the first week. Look for denied traffic that suggests a missed rule, and adjust carefully.

Frequently Asked Questions

Why should businesses segment IoT devices from the rest of the network?

IoT devices such as cameras, badge readers, thermostats and printers often ship with default passwords and receive firmware updates irregularly, which makes them easy entry points. If a compromised device shares a flat network with workstations and file servers, an attacker can move laterally to sensitive systems. Segmentation limits that movement by placing devices in their own network domain, where firewall rules allow only the connections they actually need. It also makes monitoring simpler, because unusual traffic from a segment stands out against its known baseline.

How can you test whether IoT network segmentation is working?

Test from the device’s segment and confirm it can reach only the destinations your policy permits, such as the cloud service or the controller it reports to. Then attempt connections from the device segment to workstations and servers on the corporate network, which should fail. Repeat the same checks from a corporate workstation against IoT devices to confirm inbound access is blocked where intended. Keep a short test script and record the results so you can repeat the checks after firmware updates or firewall changes.

What should businesses do if an IoT device cannot support VLAN tagging?

Some older or low-cost devices cannot tag traffic with a VLAN ID. In that case, connect the device to a dedicated switch port or a separate wireless SSID that is mapped to the IoT VLAN on the access point, so the port itself defines the segment. Confirm the port is set as an untagged member of the correct VLAN, and apply the same firewall rules you use for tagged devices. Where neither option is possible, isolate the device behind its own firewall interface and document the exception for future review.

---

DefCon Security Technologies designs and integrates IP-based alarm, video, and access control systems, and we work with your IT team to keep these segments secure and reliable. Contact us for a free estimate and a segmentation review of your current network.