On a Tuesday last spring, I got a text from a client that opened with the question you'd expect: "What is on my wifi?"
The office manager at a regional logistics company had just finished a Wi-Fi scan because one of the conference rooms kept dropping audio. The scan found two devices she couldn't place: a couple of contractor phones and something called Magic Max. The phones she had guessed were visitors. The Magic Max device she'd never heard of. "Is someone on our network?" she asked.
I'm the quality and brand compliance manager here. Before any network design, user guide, or marketing claim goes to a customer, I review it. Roughly 250 deliverables a year, and I reject about 12% of first drafts. The reasons vary: a cable label that doesn't match the switch port, a VPN setup doc that references the wrong subnet, a claim of "enterprise-grade" with no test report behind it. That background is why her question made me stop—not because I suspected an attacker, but because I knew how often the answer was "no, it's worse: it's a spec failure."
It wasn't a rogue device. It was a segmentation gap.
The client had switched to Extreme Networks primarily because they were tired of expensive Cisco licensing and wanted a predictable alternative. The network was built on a stack of ExtremeSwitching X440 access switches, with Extreme Networks Fabric Connect handling VLAN services. We had chosen that architecture for one main reason: Fabric Connect IoT segmentation. The client wanted their printers, badge readers, cameras, and building controller on isolated segments without the cost of a separate physical network.
On the whiteboard, the design was clean. The Fabric Connect service list showed an IoT VLAN, a guest VLAN, a voice VLAN, and corporate data VLANs. The X440s had the right software licenses. The access points were configured with separate SSIDs for staff, guests, and IoT devices. The diagram said "IoT segmented."
But the diagram was a lie. Not a malicious one—a lazy one.
What the X440 switch actually showed
When I pulled up the switch's MAC address table and compared it to our documentation, the first problem was clear: the Magic Max controller wasn't on the IoT VLAN. It was on VLAN 10, the corporate data VLAN, with access to the printer VLAN and the file server subnet. The device page described Magic Max as a smart building controller with firmware version 2.1.4 and an MQTT connection. It had no known critical CVEs, but it was exactly the kind of device you don't want sitting next to your payroll file server.
People think buying a switch with IoT segmentation features means your devices are automatically segmented. Actually, the causation runs the other way: the network only becomes segmented after you verify every port and SSID mapping, one by one. Segmentation is an action, not a feature. The Magic Max device was proof that the action hadn't been completed.
The phones were the second surprise. Two contractor devices had connected to the "Guest" SSID, but the Guest SSID was mapped to the corporate VLAN because an access point had been re-provisioned with the wrong template. From the contractor's perspective, they were on guest Wi-Fi. From the network's perspective, they were inside the fence. That's exactly the kind of thing that doesn't show up on a first glance at the dashboard.
And then there was the Fabric Connect part. The IoT segmentation service was bound to one X440 stack member, but not to the other. The switches shared the same config file, yet the service advertisement wasn't propagating the same way on every port. This is the sort of thing that looks fine in a CLI output and fails in practice.
Here's something vendors won't tell you: most network diagrams are drawn before the physical work is done. The plan says "IoT segmented," and the designer genuinely believes it will be that way. The network doesn't care what the plan says. The network cares what port is plugged into which switch, and which VLAN that switch port is willing to carry.
The turning point
What started as a "check the scan" visit turned into a full port-by-port audit.
I told the office manager that we couldn't just move the Magic Max device to another VLAN and call it fixed. We needed to verify the entire path: every wall jack, every patch panel connection, every access point SSID, and every Fabric Connect service binding. It took two days longer than we'd planned. The client wasn't happy about the delay, but I've learned that understanding the truth is more important than staying on schedule.
At one point, the office manager asked why the previous installers hadn't caught this. The answer: because nobody tested the boundary. The port was in the right VLAN in the switch config, but the cable went to the wrong wall plate. The AP showed the right SSID names, but the VLAN mapping was wrong. These mismatches only show up when you check the whole chain, end to end.
We rejected the network as delivered and drew up a remediation list: re-patch the Magic Max controller to an IoT port, reconfigure the access point templates, update the Fabric Connect service bindings on all X440 members, and then re-verify every segment with a real device. Not a simulation. A device on the IoT VLAN tries to reach the file server, and it fails.
What the fix looked like
The fix wasn't glamorous. We moved the Magic Max controller to a dedicated IoT VLAN with no route to the business network. We put the contractor phones on a real guest VLAN. We re-bound the Fabric Connect IoT service to all stack members and updated the AP templates so "Guest" actually meant guest. Then we ran the tests again.
The most satisfying part was watching the office manager connect her own laptop to the guest Wi-Fi and try to hit the printer IP. It failed. That was the moment she understood that segmentation isn't a checkbox on a datasheet—it's a behavior you can prove.
We also updated the network documentation, which nobody had touched since the original install. The drawings now show physical port numbers, wall plate labels, and VLAN IDs. If someone plugs an IoT device into the wrong port next month, the label should tell them why it's wrong.
The professional boundary
I could have ended the story there, but there's a reason the word "quality" is in my title. The visit taught me something about the limits of our role.
We're a networking team. We don't manage the Magic Max device itself. We don't write firmware for smart building controllers. We don't know what every IoT vendor means by "encrypted." What we do is provide a boundary that works even when those devices don't. The boundary is our product.
That's why I'm uncomfortable with the phrase "one-stop shop" in this industry. A vendor who says "we can secure everything" is overpromising. A vendor who says "we can't secure that controller for you, but we can make sure it can't reach your file server" is much more useful. That boundary is what we're good at.
And it's worth remembering that claims have to be provable. Per FTC guidelines (ftc.gov), advertising claims need substantiation. The same standard should apply to a network handoff. If a partner says your network has IoT segmentation, they should be able to show you the test result, not just the topology diagram.
What I'd tell someone asking "what is on my wifi?"
My experience here is based on a mid-sized logistics deployment with ExtremeSwitching X440 switches, Fabric Connect, and a small number of access points. If you're running a completely different environment, the exact commands and console screens won't match. The principle, though, is universal: you don't know what's on your wifi until you've verified it from the physical layer up.
So if you see a Magic Max device or a phone you don't recognize on your network, don't panic. Do the audit. Also be prepared to discover that the hardware isn't the problem. The problem is that someone labeled a wall port wrong, or bound a service to the wrong switch, or trusted a diagram instead of a test.
Eventually, the client thanked us for the delay. The Magic Max controller still exists, and it still does its thing, but now it lives on an IoT segment that can't reach the things that matter. The contractor phones are still allowed, but they're guests in every sense. And the next time someone asks "what is on my wifi?", the answer is: "I can show you, because we verified it."