Enterprise wireless security: WPA3, 802.1X and the certificate problem
Wireless security has a gap between what is configured and what is actually protecting anything. This page is about closing it.
What WPA3 fixes
SAE (Simultaneous Authentication of Equals) replaces the WPA2 personal four-way handshake. The important consequence: an attacker who captures the handshake cannot take it away and brute-force it offline. Under WPA2-Personal they can, and with a weak passphrase they will succeed. SAE also provides forward secrecy — a compromised passphrase does not decrypt previously captured traffic.
Protected Management Frames (PMF) are mandatory under WPA3. This kills the classic deauthentication attack, which is how most "Wi-Fi hacking" demonstrations begin.
WPA3-Enterprise 192-bit mode exists for environments with a compliance requirement for it. It is not needed by most organisations, and it restricts your client compatibility considerably.
Transition mode lets WPA2 and WPA3 clients share an SSID. It is a migration tool, and it means an attacker can force a WPA2 downgrade. Run it while you must, with a documented end date.
802.1X, and the mistake nearly everyone makes
802.1X with EAP-TLS is the strongest practical enterprise option: mutual certificate authentication, no passwords to phish, per-device revocation.
The common failure is on the client side. If the client is not configured to validate the RADIUS server's certificate — to check the certificate chain and the server name — then an attacker can stand up an evil-twin SSID, present any certificate, and harvest credentials. With PEAP-MSCHAPv2 that yields directly crackable password hashes.
Do this:
- Push the wireless profile by MDM or Group Policy. Never let users configure enterprise Wi-Fi by hand — the "trust this certificate?" prompt will be accepted every time.
- Explicitly configure the trusted root CA and the expected RADIUS server name in the profile.
- Disable the option that allows users to accept new servers or trust new CAs.
- Prefer EAP-TLS over PEAP-MSCHAPv2. If you must use PEAP during migration, treat it as a temporary state and enforce certificate validation rigorously.
- Monitor RADIUS logs for authentication attempts from unexpected NAS addresses.
IoT that cannot do 802.1X
This is most of it. A printer, a badge reader, a thermostat, a clinical pump, a barcode scanner from 2014 — none of them will do EAP-TLS.
Options, best first:
- Per-device PSK (PPSK / iPSK / DPSK depending on vendor). Each device gets a unique passphrase mapped to a VLAN and policy. One compromised device does not compromise the SSID. This is the right answer for most IoT estates.
- MAC authentication bypass with strong segmentation. MAC addresses are trivially spoofed, so this is not authentication — it is inventory. Only acceptable behind aggressive segmentation and monitoring.
- A separate SSID with a shared PSK, heavily segmented. Acceptable only when the VLAN is genuinely isolated and egress-filtered, and the key is rotated on a schedule.
Whatever you choose: put IoT on its own VLAN, deny it lateral movement, deny it internet egress except to the specific destinations it needs, and assume it will be compromised eventually. Design for containment rather than prevention.
Guest networks
- Use OWE (Enhanced Open) rather than a genuinely open BSS. It gives unauthenticated encryption, which stops passive sniffing of guest traffic — a meaningful improvement over open Wi-Fi for zero user friction.
- Isolate clients from one another at layer 2.
- Do not put a guest network on the same VLAN as anything else. Ever.
- Rate-limit per client, and be aware that captive portals interact badly with 6 GHz-capable clients and with MAC randomisation.
MAC randomisation
Modern iOS, Android and Windows randomise MAC addresses per SSID by default. Any control that depends on a stable MAC address — MAB, MAC allow-lists, per-device bandwidth policy, device tracking in analytics — is degraded or broken. Plan for identity based on certificates or per-device PSK instead.
The unglamorous list
- Rotate the WPA2 pre-shared keys you still have, and record where they are used.
- Disable WPS everywhere. It is still enabled by default on more equipment than you would expect.
- Change default admin credentials on every AP, switch and controller, and check that AP console access is disabled or password-protected.
- Enable rogue AP detection and containment, and check the alerts weekly rather than discovering an eighteen-month-old rogue during an audit.
- Physically secure APs in public areas. An AP in a reachable location is a console port and a network drop.
Signal, not noise.
One email a fortnight: new case studies, spectrum-policy changes, and the gear worth your budget.