Why IoT Devices Need Special Risk Reduction
Smart TVs, speakers, cameras, plugs, thermostats, robot vacuums, and “smart” appliances often behave differently from laptops and phones. Many are built to be inexpensive, run minimal operating systems, and prioritize convenience over long-term maintainability. As a result, they can be harder to monitor, harder to patch, and more likely to expose services you did not intend to run on your home network.
IoT risk reduction is the practice of limiting what these devices can do, limiting what they can reach, and limiting what can reach them. Network segmentation is one of the most effective tools for this: you place devices into separate network “zones” so that compromise of one zone does not automatically grant access to everything else.
Think in terms of “blast radius.” If a smart plug is compromised, the goal is that the attacker can at most control that plug and maybe reach the internet, but cannot scan your laptop, access your NAS, or talk to your security cameras.
Network Segmentation: Core Concepts
What segmentation is (and what it is not)
Segmentation means dividing your home network into multiple logical networks with controlled traffic between them. In practice, this is usually done with one or more of the following:
- VLANs (Virtual LANs): separate Layer 2 networks on the same physical hardware, typically requiring a router/firewall that supports VLAN interfaces and rules.
- Multiple SSIDs mapped to different networks: for example, an “IoT” Wi‑Fi name that places devices into an IoT VLAN/subnet.
- Separate physical routers: a second router behind the primary router, creating a “double NAT” segment for less-trusted devices.
Segmentation is not the same as “hiding” devices. If devices are on the same network, they can often discover each other via broadcast/multicast, and a compromised device can attempt connections to anything. Segmentation changes the default: cross-zone traffic is blocked unless you explicitly allow it.
Continue in our app.
You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.
Or continue reading below...
Download the app
Zones, subnets, and trust levels
A practical way to design segmentation is to assign each device category a trust level and a zone. Common zones include:
- Trusted / Main: laptops, phones, tablets, work devices.
- IoT: smart home devices that need internet access but should not reach your computers.
- Cameras / Security: cameras and NVRs, often needing local access to a recorder but not to your general devices.
- Servers / Storage: NAS, home server, backups, media server.
- Management: router, switches, access points, controller interfaces.
Each zone typically corresponds to a different IP subnet (for example, 192.168.10.0/24 for Trusted, 192.168.20.0/24 for IoT). The router/firewall sits between these subnets and enforces rules.
Default-deny between zones
The most important segmentation concept is: allow what you need, block everything else between zones. A simple baseline is:
- Trusted → Internet: allow
- IoT → Internet: allow (sometimes with restrictions)
- IoT → Trusted: block
- Trusted → IoT: allow only what is needed for control (often specific protocols)
- IoT → Servers/Storage: block (or allow only to a specific service like an NVR)
- IoT → Management: block
This baseline prevents common lateral movement patterns: scanning the network, attempting default credentials on other devices, or reaching file shares.
Common IoT Communication Patterns You Must Account For
Local control vs cloud control
Some ecosystems control devices locally (your phone talks directly to the device), while others rely on cloud relay (your phone talks to a vendor service, which talks to the device). This matters for segmentation:
- Cloud-controlled devices often work fine even when isolated, as long as they can reach the internet.
- Locally controlled devices may require your phone (Trusted zone) to reach the device (IoT zone) on specific ports.
Example: A smart bulb hub might expose a local HTTP API on TCP 80/443, or a proprietary port. If you block Trusted → IoT entirely, the app may not discover the hub or may fail to control it locally.
Discovery protocols (mDNS, SSDP/UPnP, broadcast)
Many smart home apps rely on discovery protocols to find devices automatically:
- mDNS (multicast DNS, UDP 5353) used by many Apple and smart home devices.
- SSDP (part of UPnP, UDP 1900) used for discovery by many consumer devices.
- Broadcast discovery (various UDP broadcasts) used by printers, TVs, and older IoT gear.
These protocols do not naturally cross subnets. If you segment IoT into a different subnet, auto-discovery may stop working unless you use a feature like an mDNS reflector/repeater or you configure devices by IP/hostname instead of discovery.
Security trade-off: reflecting discovery across segments increases convenience but also increases cross-zone visibility. Prefer targeted allowances (for example, allow only mDNS between Trusted and IoT) rather than broad “allow all.”
Device-to-device dependencies
Some devices must talk to each other locally:
- Camera → NVR (often RTSP, ONVIF, proprietary ports)
- Smart speaker → streaming device (casting protocols)
- Hub → sensors (often Zigbee/Z-Wave locally, but the hub still needs internet)
Segmentation design should group tightly-coupled devices together (for example, cameras and NVR in the same “Cameras” zone) and then restrict that zone from reaching everything else.
Practical Segmentation Designs for Home Networks
Design A: Router with VLAN support (recommended when available)
This design uses one router/firewall that supports VLANs and rules, plus access points (APs) that can map SSIDs to VLANs. You create separate VLANs/subnets for Trusted, IoT, and optionally Cameras/Servers/Management.
Advantages: clean separation, flexible rules, no double NAT, easier to scale. Disadvantages: requires compatible hardware and some configuration effort.
Design B: “Second router” IoT segment (works with basic equipment)
If your primary router cannot do VLANs, you can place a second router behind it and connect IoT devices to the second router’s Wi‑Fi. This creates a separate subnet behind NAT.
Advantages: inexpensive, simple conceptually. Disadvantages: double NAT can break some device discovery and inbound access; you may need port forwarding between routers for local control, which can reduce the isolation benefits if done broadly.
Design C: Separate AP/SSID with client isolation (partial segmentation)
Some routers/APs offer “AP isolation” or “client isolation” on a Wi‑Fi network. This prevents Wi‑Fi clients from talking to each other, but it does not necessarily prevent them from reaching wired devices or other subnets, depending on implementation.
Use this only as a partial measure when you cannot create separate subnets. It is better than nothing, but it is not equivalent to VLAN segmentation with firewall rules.
Step-by-Step: Build an IoT Segmentation Plan
Step 1: Inventory devices and classify by risk
Create a list of every connected device and assign it to a category. Include “invisible” devices like hubs and bridges. For each device, note:
- Does it need to be controlled locally from phones/PCs?
- Does it need to talk to another local device (e.g., camera to NVR)?
- Does it store sensitive data (e.g., camera footage, voice recordings)?
- Is it from a vendor with a strong update track record?
Practical classification example:
- High risk: cheap cameras, off-brand plugs, devices with unknown update support.
- Medium risk: mainstream smart speakers/TVs, streaming sticks.
- Lower risk: hubs that use non-IP radios for sensors (Zigbee/Z-Wave), because sensors are not directly IP-reachable, but the hub is still an IP device.
Step 2: Decide zones and what must communicate
Start with three zones if you want to keep it manageable:
- Trusted: computers/phones
- IoT: smart devices
- Servers/Storage (optional): NAS/home server
Write down required flows in plain language, for example:
- Phones in Trusted must control smart TV in IoT.
- IoT devices must reach the internet for updates and cloud control.
- IoT devices must not reach NAS.
This list becomes your firewall rule plan.
Step 3: Create subnets (or the equivalent) for each zone
If using VLANs, assign a VLAN ID and subnet per zone. Example:
- Trusted: VLAN 10, 192.168.10.0/24
- IoT: VLAN 20, 192.168.20.0/24
- Servers: VLAN 30, 192.168.30.0/24
If using a second router, the “IoT zone” is the second router’s LAN (for example, 192.168.50.0/24), while Trusted remains on the primary router’s LAN.
Step 4: Map Wi‑Fi SSIDs (and wired ports) to zones
For VLAN setups, create separate SSIDs:
- SSID “Home” → VLAN 10 (Trusted)
- SSID “Home-IoT” → VLAN 20 (IoT)
For wired devices (like an NVR or smart TV), either connect them to a switch port assigned to the correct VLAN, or place them behind the second router if using Design B.
Step 5: Apply baseline firewall rules (least privilege)
Implement rules in this order (order matters on many firewalls):
- Allow established/related traffic (so return traffic works).
- Block IoT → Trusted (entire subnet).
- Block IoT → Servers/Storage (entire subnet), unless you have a specific dependency.
- Allow IoT → Internet (outbound).
- Allow Trusted → IoT only as needed for control.
Practical example of “only as needed”: if your phone app controls a hub via HTTPS, you might allow Trusted → IoT on TCP 443 to the hub’s IP only, rather than allowing all ports to all IoT devices.
Step 6: Handle discovery carefully (mDNS/SSDP)
If device discovery breaks after segmentation, you have three common options:
- Manual configuration: add the device by IP address in the app, if supported.
- Selective reflection: enable an mDNS reflector between Trusted and IoT only, not between all zones.
- Temporary pairing window: temporarily allow broader access during setup, then revert to strict rules.
A practical workflow is to keep a “Setup” rule disabled by default (for example, allow Trusted → IoT any/any), enable it only while onboarding a new device, then disable it again.
Step 7: Verify segmentation with simple tests
After applying rules, verify from a device in each zone:
- From an IoT device (or a test device placed in IoT), confirm it can reach the internet.
- From IoT, confirm it cannot reach a Trusted device (try pinging a laptop IP, or attempting to open a shared folder).
- From Trusted, confirm you can still control IoT devices that require local access.
If you do not have tools on IoT devices, temporarily connect a spare phone or laptop to the IoT SSID and use it as a test client.
IoT Risk Reduction Beyond Segmentation
Minimize local services and lateral movement opportunities
Even within the IoT zone, reduce device-to-device exposure when possible:
- Prefer hubs that keep sensors off IP (Zigbee/Z-Wave) so sensors are not individually reachable.
- Disable features you do not use (for example, local media sharing, remote admin, or “developer” modes) in device settings.
- Avoid placing high-value devices (NAS, backups, workstations) in the same zone as entertainment devices.
Outbound control: restrict where IoT devices can connect
Segmentation controls lateral movement, but many IoT compromises involve outbound connections to command-and-control servers. If your router/firewall supports it, consider outbound restrictions for IoT:
- Block IoT from reaching local subnets (already covered by segmentation).
- Allow only necessary outbound ports (often TCP 443, sometimes TCP 80 for updates; be cautious because some devices use unusual ports).
- Block outbound SMTP (TCP 25/587) from IoT to reduce spam abuse if compromised.
Be prepared for trial-and-error: some devices fail silently when blocked. Start with logging enabled on deny rules so you can see what is being blocked and adjust deliberately.
Inbound control: avoid exposing IoT to the internet
A key risk reducer is ensuring IoT devices are not reachable from the public internet. In a segmented design, keep inbound rules tight:
- Do not create inbound port forwards to cameras, NVRs, or hubs unless you have a strong reason and understand the risk.
- If remote access is required, prefer a single hardened entry point (for example, a VPN endpoint on the router) rather than exposing multiple devices.
This approach reduces the number of internet-facing services and makes patching and monitoring more manageable.
Use a “management plane” for network equipment
Network segmentation is undermined if IoT devices can reach the admin interfaces of your router, switches, or access points. Create a simple management concept:
- Only Trusted devices (or a dedicated admin device) should be able to access management interfaces.
- Block IoT from reaching common management ports (HTTP/HTTPS admin pages, SSH) on network infrastructure IPs.
Even if you do not create a separate Management VLAN, you can still enforce “IoT cannot reach router admin IP” as a targeted rule.
Practical Examples of Segmentation Rules (Conceptual)
Example 1: Basic three-zone home
Goal: Keep IoT away from laptops and NAS, but allow phone control.
- Trusted (192.168.10.0/24) → IoT (192.168.20.0/24): allow TCP 443 to smart hub IP 192.168.20.10
- Trusted → IoT: allow UDP 5353 (mDNS) if needed for discovery
- IoT → Trusted: block all
- IoT → Servers (192.168.30.0/24): block all
- IoT → Internet: allow
Example 2: Cameras isolated with NVR access
Goal: Cameras can only talk to NVR and internet time services, not to anything else.
- Cameras zone → NVR IP: allow required camera-to-NVR ports (vendor-specific; often RTSP/ONVIF)
- Cameras zone → Internet: allow NTP (UDP 123) and HTTPS (TCP 443) if cameras need updates; otherwise block internet entirely
- Cameras zone → Trusted/Servers: block all
- Trusted → NVR: allow HTTPS to view footage
This design limits the impact of a compromised camera and reduces privacy risk by preventing cameras from making arbitrary outbound connections if you choose to block internet access.
Example 3: Streaming devices that need casting
Goal: Allow casting from phone/laptop to a streaming stick in IoT while keeping IoT isolated.
Casting often relies on discovery and local connections. A practical approach is:
- Enable mDNS reflection between Trusted and IoT (only those two zones).
- Allow Trusted → streaming device IP on required ports (often TCP 8008/8009, 8443, or vendor-specific).
- Keep IoT → Trusted blocked.
If you cannot determine ports easily, temporarily allow Trusted → IoT broadly, observe what connections occur (via firewall logs), then replace the broad rule with specific ones.
Operational Habits That Make Segmentation Work Long-Term
Use stable addressing for devices that need rules
Firewall rules are easier when key devices keep the same IP address. Use DHCP reservations for hubs, NVRs, and any IoT device that you will reference in rules. This prevents rules from breaking when a device gets a new IP.
Document your zones and exceptions
Maintain a simple table (even a note in your password manager) listing:
- Zone name and subnet
- Which SSID maps to which zone
- Any exceptions (for example, “Phone → Hub TCP 443 allowed”)
This prevents “mystery rules” that accumulate over time and weaken isolation.
Plan for new devices: a controlled onboarding pattern
When you add a new IoT device, you often need a short period of extra access for pairing and discovery. A safe pattern is:
- Place the device in the IoT zone from the start.
- Temporarily enable a broader Trusted → IoT rule for setup only.
- Once the device is working, disable the setup rule and add only the minimal permanent allowances.
This keeps convenience without permanently opening the network.
Watch for “shadow bridges” between zones
Some devices can unintentionally bridge segments:
- A smart TV connected by Ethernet to one zone and Wi‑Fi to another (dual-homed) can create unexpected paths.
- Mesh nodes or extenders configured incorrectly can leak VLANs or collapse separation.
- A computer with Internet Connection Sharing enabled can route between networks.
As a rule, avoid connecting a single device to multiple zones unless you explicitly understand and control the routing behavior.
When Segmentation Is Not Enough: Recognizing Residual Risk
Segmentation reduces lateral movement, but it does not automatically prevent:
- Data leaving the network if an IoT device is compromised and can still reach the internet.
- Attacks on the router/firewall itself if the device can reach management interfaces or exploit network services.
- Abuse of allowed paths (for example, if you allow Trusted → IoT broadly, a compromised Trusted device can attack IoT, and vice versa if you allow reverse paths).
That is why segmentation should be paired with strict rule design, minimal exceptions, and periodic review of what is allowed between zones.
