The Evening I Decided Enough Was Enough
It was a cold January night. The whole family was in the living room. Emily was on the couch with her laptop grading papers. Ella was on her iPad. Owen was watching something on the living room TV. Miles was—predictably—lying in the middle of the floor where someone was guaranteed to trip over him.
Everything was working. And that was the problem.
I had just read another story about a smart home device being used as an entry point for a network attack. Another piece about a compromised camera being recruited into a botnet. Another firmware vulnerability that was discovered months ago and never patched.
I had a smart TV, a video doorbell, three smart plugs, a smart speaker, a robot vacuum, and several smart bulbs. Every single one of them was on the same Wi-Fi network as our laptops, our phones, and our family photos.
If any one of them got compromised, it had a clear path to everything else.
That night, I decided to do something about it.
The Risk I Was Ignoring
Let me be direct about the problem.
Most consumer IoT devices are not built with security as a priority. Many run on cheap hardware, receive firmware updates for less than a year, and are abandoned by manufacturers shortly after release. The reality is that smart bulbs, plugs, and cameras often run stripped-down operating systems that haven't seen a security patch since they left the factory.
The risk in a flat network (everything on one network):
Any device can, in theory, see and talk to every other device on the network. That's how file sharing, printing, and casting work. It also means that a single compromised gadget becomes a staging point to attack everything else. Threat actors frequently target IoT devices to create botnets, conduct surveillance, or pivot to more valuable devices on the same network.
I'm not saying every smart device is compromised. But I am saying that the risk is real enough that the FBI explicitly recommends separating devices onto different networks. A compromised camera should not have access to my laptop, my NAS, or my family's photos. On an unsegmented network, it often does.
The Two Ways to Do This
There are two main approaches to isolating smart-home devices, and I considered both.
Option 1: The Guest Network
The simplest option. Most consumer routers have a built-in guest network feature. It's often a single checkbox or toggle in the router settings.
How it works:
The guest network operates on its own SSID. Devices on it can reach the internet but are isolated from the primary network. If a device is compromised, an attacker is confined to the guest network and can't reach more valuable devices on the main network.
What I liked:
Easy to set up—most routers have this feature already
No additional hardware required
Client isolation prevents devices from talking to each other on the same network
Many routers let you cap bandwidth on the guest SSID
The tradeoffs:
Not true network segmentation—no granular control over what talks to what
mDNS doesn't cross the isolation boundary by default (more on this later)
Guest network is often treated as "low priority" with fewer features
Some routers don't let you choose which devices go on which network—it's all or nothing
What I learned from others' experience: A friend of mine moved all their IoT gear to the guest network and AirPlay stopped working on their smart TV. The TV and the phone on the main network couldn't discover each other. The isolation worked—but it also broke something they actually used.
Option 2: VLANs (Virtual Local Area Networks)
More advanced. A VLAN is a logical way to split a physical network into multiple isolated instances. Each VLAN operates as its own separate network, with its own IP range and firewall rules.
How it works:
A VLAN allows you to separate devices even when they share the same physical hardware. You can create a trusted VLAN for your computers and phones, an IoT VLAN for smart devices, and a guest VLAN for visitors. Each VLAN can have its own set of firewall rules controlling what traffic is allowed.
What I liked:
Granular control over which devices can talk to each other
Truly separate subnets—not just a simplified isolation layer
Can create specific rules for specific devices or use cases
Much more secure than guest network isolation
The tradeoffs:
More complex to set up—typically requires a router that supports VLANs
Can break device discovery (mDNS, Bonjour, SSDP) across VLANs unless you configure multi-cast forwarding
Home Assistant users need to plan firewall rules ahead of time
If you don't document your rules, you'll have a mess when something breaks
The complexity myth: Modern routers from Ubiquiti's UniFi, TP-Link Omada, and even some advanced Netgear and Asus routers have made VLAN setup visual and accessible. It's often in plain language without mentioning the word "VLAN" at all. You name the network, assign a subnet, and set a rule for whether traffic can cross.
What I Actually Did
I chose VLANs. I wanted the granular control and the security of a truly separated network. I also wanted to avoid the limitations of guest network isolation—the mDNS breakage, the lack of visibility, the constraints.
My setup:
I created three VLANs:
Trusted VLAN (main network) — laptops, phones, tablets, NAS, desktop computers
IoT VLAN — smart plugs, smart bulbs, cameras, thermostat, robot vacuum
Guest VLAN — visitors' devices
The firewall rules I set:
Allow IoT devices to reach the internet (for firmware updates and cloud services)
Block IoT devices from initiating connections to the Trusted VLAN
Allow the Trusted VLAN to initiate connections to the IoT VLAN for control purposes
Allow specific exceptions only when required (e.g., Home Assistant on Trusted VLAN talking to devices on IoT VLAN)
Enable DHCP and DNS across VLANs
The mDNS fix:
mDNS (multicast DNS) doesn't cross VLANs by default. This broke casting, AirPlay, and device discovery. I enabled an mDNS reflector on my router. That allowed discovery traffic between the Trusted and IoT VLANs without opening unrestricted access.
What Broke and How I Fixed It
The moment I moved everything to the VLAN, things started acting strange.
Broken #1: Casting stopped working
Chromecast and AirPlay rely on mDNS discovery. When the TV moved to the IoT VLAN, devices on the Trusted VLAN couldn't see it. The fix: enable mDNS forwarding across VLANs.
Broken #2: Home Assistant lost integration
Home Assistant runs on a device on my Trusted VLAN. It needs to communicate with devices on the IoT VLAN. The fix: firewall rules allowing Home Assistant's IP to initiate connections to the IoT VLAN, while blocking IoT devices from initiating connections back.
Broken #3: Smart plugs stopped responding
Some vendor apps rely on local discovery (SSDP, UPnP) that doesn't cross VLANs. The fix: for provisioning, I temporarily connected my phone to the IoT VLAN, set up the device, then switched back. After that, the devices worked under the VLAN rules I set.
Broken #4: Camera feeds were unreachable from the main network
Cameras on the IoT VLAN couldn't be reached by the NVR on the Trusted VLAN. The fix: a specific firewall rule allowing the NVR's IP to reach the camera IPs on the IoT VLAN, with a strict allow-only rule for that specific traffic.
What I Learned
VLANs are worth the effort—but you need to plan.
The first week was frustrating. I kept finding things that broke because I didn't anticipate how devices actually communicate. But I also learned exactly what my devices were doing on the network—and that alone was valuable.
Key takeaways:
Most smart devices rely on mDNS for discovery, and mDNS doesn't cross VLANs without help
You need to allow only the traffic that's necessary—not everything
Testing each device individually after moving it prevents a cascade of failures
Documenting your rules is important—six months later, you'll forget why you added a specific exception
Not all routers support VLANs; if yours doesn't, guest network isolation is better than nothing
If your router doesn't support VLANs:
Many routers don't support VLANs, even some from the last few years. If that's the case, the guest network approach is still a significant security improvement over a flat network. The security benefit of isolation outweighs the limitations. Use the guest network with client isolation enabled.
If your router does support VLANs:
Setup may take a few hours upfront, especially the first time. But once it's working, the maintenance is minimal. Every new device I add goes straight onto the IoT VLAN, and I verify discovery works before relying on the device.
What if you just want the security benefit but don't want the complexity?
Use the guest network approach. It's less granular, but it still creates a wall between IoT devices and your sensitive data. That wall is what matters.
The Bottom Line
Putting smart devices on a separate network is one of the most practical security steps you can take.
The devices that are the least trustworthy—smart bulbs, plugs, cameras, sensors—don't need access to your laptops or your personal files. They just need the internet. By moving them to their own network, you ensure that a single compromised device can't be used to compromise your entire household.
Protect the front door before you build a taller fence.
The front door in this case is a wall between IoT devices and the rest of your network. The fence is everything else. Start with the wall.
What I'd recommend:
If your router supports VLANs, use them. If it doesn't, use the guest network with client isolation enabled. Either approach is better than running everything on one flat network.
Next Week: The five-minute version of a safe app cleanup—reviewing old accounts, access permissions, and device connections.
Dave C. — Five minutes now beats five hours later.
No notes on this sheet yet.