How to secure IoT devices on your network
Put IoT devices on their own VLAN, change defaults, monitor traffic, and find a rogue smart device on your network with your router, nmap, and Home Assistant.
On this page
IoT devices are the weakest link in most home networks. A cheap smart plug or sensor with default credentials can become the entry point for an attacker. If you’re running Home Assistant or a local hub like the Hubitat Elevation C-8 (the plain C-8 was discontinued in March 2026, so the C-8 Pro is the only hub Hubitat sells now), you already have a security advantage - you’re not relying entirely on cloud services. But that only gets you so far. Here’s how to actually lock down your IoT stack.
Short version: VLAN segmentation is the highest-impact change you can make. Pair it with local-only devices where possible, changed defaults, and some monitoring, and you’ve closed off the attack paths that get used in practice. If an unknown device is already on the network, read your router’s connected-devices list, scan the subnet with nmap, and reconcile both against Home Assistant’s known devices and your Zigbee/Z-Wave node lists.
Isolate with network segmentation
The single most effective thing you can do is put IoT devices on a separate VLAN from your computers and phones. Most consumer routers don’t make this easy, but it’s worth the effort.
Create three networks at minimum:
- Trusted - your personal devices, NAS, Home Assistant host
- IoT - all smart home gadgets, smart TVs, voice assistants
- Guest - visitors, anything you don’t control
Traffic should flow from Trusted to IoT (so Home Assistant can reach your devices), but never the other way. If a compromised smart bulb tries to phone home to a command server, it gets blocked. Two exceptions are worth allowing on purpose: a device that pushes to your broker opens the connection itself from the IoT side, so MQTT needs an inbound rule; and mDNS discovery is link-local multicast that does not cross a VLAN boundary at all, so your router needs an mDNS repeater before Home Assistant can find those devices.
Segmentation is easier to describe than to wire. Per-port VLANs need a managed switch, and if the devices you are isolating are PoE cameras or access points, that switch has to power them too. In a UniFi setup the UniFi Switch Lite 8 PoE is the usual small answer: eight gigabit ports, four of them PoE+ on a 52W budget, fanless enough to live in a closet. For wireless, the UniFi U6 In-Wall puts a Wi-Fi 6 access point into a standard US gang box and adds wired ports behind it, which is a tidy way to give an IoT SSID its own hardware without another box on a shelf. Both show up in Home Assistant through the local UniFi Network integration, which is not monitoring-only: it exposes WLANs, port forwarding, traffic rules, zone-based firewall policies and individual switch and PoE ports as entities, so Home Assistant can change network policy rather than only watch it.
Many routers offer a separate IoT SSID for exactly this, and hardware built for segmentation makes it routine: the UniFi Dream Machine Pro runs the UniFi Network controller that manages your VLANs and shows every wired and Wi-Fi client, and the OpenWrt-based GL.iNet Flint 2 is a strong base for IoT VLAN isolation with no vendor cloud. Once IoT lives on its own segment, a stranger on your main network is immediately obvious.
If your router supports it, write the same rules for IPv6 as for IPv4. Firewall policy is per-address-family: a ruleset written only for IPv4 does not filter IPv6 at all, so a device that has IPv6 connectivity can still reach out through a policy you believe is closed.
For Home Assistant Green or Home Assistant Yellow users (the Yellow was discontinued in October 2025 and is fine to keep running, just not worth paying a premium for as old stock), ensure your instance is on the Trusted network and can still communicate with the IoT VLAN. You may need to configure static routes or allowlist specific ports.
Prefer local-only devices
Cloud-dependent devices are a liability. When the company shuts down their servers or gets breached, your device becomes a brick - or worse, an open door.
Choose devices that work locally without requiring cloud accounts:
- Aqara devices work over Zigbee to a local hub such as the Aqara Hub M3, so day-to-day control keeps working with the internet down, though the Aqara app and account are still needed for initial setup and firmware updates
- Shelly devices have built-in local HTTP APIs and MQTT support
- Philips Hue is controlled locally through the Hue Bridge’s on-LAN REST API, so lights keep responding without a cloud round-trip
Avoid devices that require constant cloud connectivity for basic functions. If a device won’t work with your internet down, that’s a security risk, not a feature. For more on cutting off unwanted outbound chatter, see how to stop your smart home from phoning home.
Zigbee and Z-Wave are separate radios, and each needs its own coordinator. For Zigbee, a dedicated USB stick such as the SONOFF Zigbee 3.0 USB Dongle Plus (E) or a ConBee III runs ZHA or Zigbee2MQTT on your own hardware. Neither one contains a Z-Wave radio, so Z-Wave devices need a separate Z-Wave stick running Z-Wave JS. Either way the network stays local, with no cloud account in the path.
Change defaults and update firmware
This should be obvious, but it bears repeating: change every default password. Most IoT devices ship with admin/admin or similar credentials that are publicly documented.
Beyond passwords:
- Disable UPnP on your router. UPnP lets devices open ports on your firewall automatically, which attackers actively scan for.
- Turn off cloud features you don’t use. Many devices ship with cloud connectivity enabled by default even if you configure them locally.
- Update firmware regularly. This is painful with many IoT devices that don’t have auto-updates, but it’s essential. Make a habit of checking every few months.
For devices that stop getting firmware updates, consider replacing them. An unpatched device on your network is a liability that grows over time.
Monitor what devices are doing
You can’t secure what you can’t see. Set up network monitoring to detect anomalous behavior:
- Pi-hole or similar DNS-level blocking can show you which devices are resolving domains you don’t expect
- Home Assistant’s built-in device tracker shows when devices come online, but it won’t catch traffic to unexpected IPs
- VLAN-level logging on your router captures all traffic flows - if your router supports it
Watch for devices making connections to IP ranges you don’t recognize, especially on ports other than standard ones (443, 80). A smart plug contacting port 22 or 3389 is a red flag. If you suspect an unknown device is already on your network, the next section walks through tracking it down.
If you run a UniFi gateway like the UniFi Dream Machine Pro, UniFi Network’s intrusion detection and prevention (IDS/IPS) can flag, and optionally block, suspicious device behavior across your VLANs.
Finding a rogue device on the network
An unrecognized device - a forgotten plug, an old camera, a guest’s gadget, or something you never installed - is worth tracking down. A note up front: Home Assistant does not ship a packet-capture or traffic-inspection panel, and the Apple Home app has no “device network” screen. The real tools are your router, standard network utilities, and a couple of Home Assistant integrations.
Start with your router
Your router has the authoritative list of everything on the LAN. Log into its admin page and look for a section usually called Connected Devices, DHCP Clients, or Device List. It shows each device’s IP address, MAC address, and often a hostname.
The MAC address is the most useful clue. The first half (the OUI) identifies the manufacturer - you can paste it into any public MAC/OUI lookup to see whether it’s an Espressif (ESP), Tuya, Amazon, or other known IoT vendor. A device whose hostname and manufacturer you don’t recognize is your candidate.
If your router supports it, you can reserve or block a MAC address from this same screen, which is the cleanest way to cut off a device you don’t want.
Scan the network yourself
To cross-check the router, scan the subnet directly with nmap:
nmap -sn 192.168.1.0/24This ping-scan lists live hosts with their IP and (where resolvable) MAC and hostname. Compare it against the devices you know about. For more detail on a single suspicious host, a port scan can hint at what it is:
nmap -sV 192.168.1.42An open RTSP port (554) suggests a camera; an open MQTT port or a tiny web server is typical of ESP-based gear. If you specifically suspect a hidden camera, see how to detect hidden cameras with an app and network scan.
Reconcile against Home Assistant
Home Assistant can help you map IPs to known devices. The Nmap Tracker integration scans your network on a schedule and creates device_tracker entities by MAC address, and the Ping (ICMP) integration tracks specific hosts by IP. Both are local-polling and add no cloud dependency.
To audit what Home Assistant itself manages, open Settings > Devices & Services. Anything on your network scan that doesn’t correspond to a device here - and isn’t a phone, computer, TV, or other expected client - deserves a closer look.
If you run a Zigbee or Z-Wave network, also check that coordinator’s device list (for Zigbee, ZHA or Zigbee2MQTT; for Z-Wave, Z-Wave JS). A radio device won’t appear in an IP scan at all, so an unexpected paired node is found here rather than via nmap.
For deeper traffic analysis when you really need it, capture packets with Wireshark or tcpdump on a mirrored switch port or on the router itself - not inside Home Assistant, which has no such feature. Once the stranger is dealt with, the durable fix is the VLAN from the first section, so the next one is contained and easy to spot rather than hunted one by one. From there, audit which smart devices still phone home to understand what the ones you keep are doing.