The Scan That Exposed Our Shadow IoT Fleet
We discovered 140 IoT devices on our corporate VLAN during a network discovery scan: HVAC sensors, security cameras, smart TVs, badge-adjacent controllers, and a few devices my team could not identify from the MAC vendor alone. None of them were inventoried. None of them were controlled. They were sitting beside engineering workstations, file shares, and production reporting systems like they belonged there.
My first assumption was wrong. I thought we had a rogue-switch problem or a contractor plugging unmanaged gear into spare drops. The mistake was simpler and more uncomfortable: our IT policy required all devices to be registered, but IoT devices were being connected by facilities teams who did not know about the IT policy.
That was the backdoor.
Our regular 802.1X model worked well for Windows 11 laptops, Ubuntu 22.04 engineering stations, and managed mobile devices, but it did not fit the IoT fleet. These devices could not run supplicants, could not store certificates safely, and could not handle the retry behavior we expected from normal endpoints. I have seen teams pretend this is a documentation issue. In my experience, it is an access-control issue first and an inventory issue second.
Use MAC Authentication Bypass Where 802.1X Stops
We moved the problem to MAC Authentication Bypass because it matched the actual capability of the devices. On our Cisco access switches, we used 802.1X as the preferred method and MAC authentication as the fallback path. The switch tried proper authentication first, then sent the endpoint MAC address to RADIUS when no supplicant answered.
We ran Cisco IOS XE 17.9.4 on the access layer, FortiOS 7.4.3 at the segmentation boundary, FreeRADIUS 3.2.3 on Ubuntu 22.04, and Python 3.11 for the fingerprinting job that enriched unknown MAC records. The exact versions mattered because small differences in RADIUS attributes, CoA behavior, and switch templates changed how cleanly the ports recovered after failed authentication.
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control
interface GigabitEthernet1/0/18
description IOT-CANDIDATE-ACCESS
switchport mode access
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
mab
dot1x pae authenticator
spanning-tree portfastMAB is not identity. I treated it as controlled admission with a weak identifier, and that distinction kept our design honest.
MAC addresses can be spoofed, so I would not call this strong authentication. I would call it a practical gate for devices that otherwise get no gate at all. In our environment, the gain came from combining MAB with dynamic VLAN assignment, DHCP observation, firewall policy, and behavior monitoring, not from trusting the MAC address like a certificate.
Assign VLANs Dynamically Instead of Hard-Coding Ports
At first, facilities asked my team to label ports as IoT ports. I pushed back because hard-coded access ports age badly in a manufacturing facility. A camera gets moved. A smart TV is replaced. A contractor uses the wrong wall jack. Static port configuration turns every small facilities change into either an outage or a policy exception.
We used RADIUS attributes to return the VLAN based on the device record. Known camera MACs went to the camera VLAN. HVAC sensors went to the building-management VLAN. Unknown IoT-like devices went to a quarantine IoT VLAN with DHCP, DNS, NTP, and a registration portal reachable, but nothing else. Corporate VLAN access was removed from the decision path.
- Known corporate endpoint with supplicant: normal 802.1X user or machine policy
- Known IoT MAC with approved fingerprint: assigned IoT production VLAN
- Known camera MAC: assigned video surveillance VLAN
- Unknown MAC with IoT fingerprint: assigned quarantine IoT VLAN
- Unknown MAC with workstation behavior: blocked pending investigation
Before the change, 0 of the 140 discovered IoT devices were under network admission control. After implementing MAC-based RADIUS authentication with automatic IoT VLAN assignment, 100% of connected IoT devices were isolated to the IoT segment within 2 weeks.
That metric changed the argument.
Once we had the VLAN decision in RADIUS, we stopped debating which switch ports were safe and started debating which devices deserved which network reachability. That was a healthier conversation. In my opinion, dynamic assignment is the only sane way to handle IoT at plant scale.
Fingerprint Devices Before Trusting the Label
Device names were unreliable. One camera registered as “admin,” several TVs used generic Linux hostnames, and one HVAC controller borrowed a vendor prefix that matched three unrelated product families. My team built a lightweight classification process around DHCP options, MAC OUI, HTTP banners where allowed, mDNS, LLDP, traffic destinations, and observed ports.
You may also find this useful: Check out our guide on Python Network Config Backup: Automating Multi-Vendor Device Snapshots for more practical tips.
What I did not expect was how many devices changed behavior after firmware updates. A camera that used to call only the local video recorder suddenly started reaching a vendor cloud endpoint after a maintenance window. Nothing in the purchase record told us that would happen. The network did.
Our Python 3.11 job pulled DHCP lease data, switch authentication sessions, and firewall logs, then scored each device against known profiles. We did not auto-promote unknown devices into trusted segments on a single clue. A matching OUI plus DHCP fingerprint plus expected destination pattern was enough for low-risk classification, but anything odd stayed in quarantine until my team reviewed it.
Trust had to be earned twice.
The best fingerprints were boring. Cameras talked to recorders and NTP. HVAC sensors talked to controllers and DNS. Smart TVs tried too hard to reach streaming and telemetry services, which made them easy to isolate aggressively. I prefer conservative classification because a false allow creates a path inward, while a false quarantine usually creates a helpdesk ticket.
Keep Watching After Segmentation
Segmentation did not end the work. It made the traffic readable. Once IoT devices were isolated behind FortiGate policies on FortiOS 7.4.3, we could see which devices tried to cross boundaries, which ones depended on unexpected DNS names, and which ones failed quietly because a vendor had never documented its cloud dependency.
We built alerts for IoT-to-corporate attempts, new outbound countries, new internal destination ports, repeated DNS failures, and devices that moved between switch ports too often. We also watched authentication failures because failed MAB attempts were often the first sign of a replaced camera, a cloned MAC, or a facilities install that skipped the request process.
The firewall rules were intentionally narrow: IoT to DNS, NTP, required controllers, required recorders, and specific vendor endpoints when approved. No broad access to internal file shares. No lateral access between device classes. No casual reachability to engineering subnets because someone wanted a dashboard to load faster.
Small rules age better.
My strongest opinion after this project is that unmanaged IoT should never land on the corporate VLAN, even temporarily. If a device cannot prove identity with 802.1X, we can still make it enter through a controlled path, assign it to the least-dangerous segment, and keep watching what it does after admission. That is not perfect security, but it is a real control, and real controls beat policy documents that facilities teams never saw.