Wireless networks are the part of the stack everyone stops thinking about once the signal bars show up. That is exactly why they're the part of the stack attackers think about the most. When we walk into an environment for a security assessment, the wireless posture is almost always worse than the customer thinks it is — and the failures are remarkably consistent. Four issues account for the majority of what we find. None of them are exotic. All of them are fixable.

1. A single flat SSID for everything

The most common mistake: one corporate wireless network, one PSK or one 802.1X identity, and every device — laptops, phones, printers, conference room TVs, that one old Windows 7 industrial PC nobody wants to replace — joining the same subnet. Once a device is on that network, it can see every other device. Once an attacker has any foothold on any device, the whole thing is lateral movement.

The fix is not glamorous, but it works: segment by trust level, not by department. Corporate managed endpoints on one SSID tied to certificate-based authentication. BYOD on a separate SSID with isolation between clients and no east-west access to the corporate subnet. IoT, OT, and "devices I don't control" on their own VLAN with egress rules that let them phone home to their vendor cloud and nothing else. Guest on its own internet-only VLAN. Four SSIDs. Four different trust assumptions. Printers don't need to talk to laptops. Conference room TVs don't need to see the finance file share. Enforce that at the network layer and you've eliminated the single largest wireless attack surface for free.

2. WPA2-PSK with a password that leaks the day an employee leaves

Shared-key wireless made sense in 2008. It does not make sense now. Every time somebody prints a sticker labeled "Guest Wi-Fi Password: SpringBreak2019," you are one phone-left-at-a-coffee-shop away from an outsider having permanent credentials to your network. Rotate it quarterly, sure — and watch the help desk tickets multiply while devices get hard-coded with the old password by people who didn't get the memo.

The right answer for managed corporate devices is WPA2 or WPA3 Enterprise with EAP-TLS and certificate-based authentication through your RADIUS server. The certificate is tied to the device or the user, it can be revoked instantly when somebody leaves, and there is no password for anybody to write down. Yes, it's more work to stand up. Yes, you need a proper PKI or a RADIUS-as-a-service provider. No, there is no good excuse to still be running WPA2-PSK on a corporate SSID in 2025. For guest traffic a captive portal with a daily-rotating password is fine. For anything that touches your internal data, enterprise auth is table stakes.

3. Rogue APs and evil twins that nobody is watching for

An attacker does not need to break into your building to break into your network. They need to stand close enough to it with a Raspberry Pi, a battery pack, and a USB wireless adapter. A deauth attack kicks clients off your legitimate AP, a spoofed SSID with the same name captures the reconnection, and suddenly the attacker is sitting in the middle of your users' traffic. Employees who bring in their own "just a little travel router, no big deal" to extend wireless to their corner of the building are another version of the same problem — an untrusted AP on your corporate LAN, sometimes plugged directly into an Ethernet port they found under a desk.

The fix is wireless intrusion detection. Most enterprise AP platforms — Cisco, Aruba, Ubiquiti UniFi, Extreme — have some version of rogue AP detection built in. Turn it on. Actually look at the reports. When an unknown SSID broadcasting your corporate name shows up, you want to know within minutes, not on an auditor's findings report six months later. Complement that with port security on your wired switches so somebody can't just plug an unauthorized device into a wall jack and get a DHCP lease. And walk your building occasionally with a tool like Kismet. It is startling what you find.

4. Guest networks that aren't actually guest networks

The fourth failure is the one that fools even careful admins. Somebody set up a "guest" SSID years ago, and at the time it was isolated properly. Since then, a VLAN got reconfigured, a firewall rule got loosened to "just let the conference room apps work," a junior admin added a route "temporarily," and now the guest network has visibility to a handful of internal resources nobody remembers exposing. The guest SSID itself is fine. The guest VLAN's path through the rest of the network is not.

Test this the way an attacker would. Join the guest network with a fresh laptop, run a basic scan — nmap, a port scanner, whatever you like — and see what responds. You should see your internet gateway and nothing else. If you can resolve internal DNS names, if you can ping the file server, if you can reach the printer VLAN, your guest network is not isolated. Fix it at the firewall level with explicit deny rules, not implicit trust. And audit it quarterly, because configuration drift on segmentation rules is one of the most common ways good networks slowly rot into bad ones.

What actually matters

None of these fixes are expensive, and none of them require ripping your wireless infrastructure out and starting over. They require taking wireless seriously as an attack surface, not as a convenience feature. The attackers already treat it that way. The question is whether your defense does too.

If you want to know where your wireless network actually stands, the cheapest useful test is the one we run at the start of every engagement: a week of passive monitoring with a tool like Wireshark or the built-in logs on your AP controller, and an honest conversation about what you find. You do not need a red team. You need a quiet hour and the willingness to look at what's already in front of you.