Open guest Wi-Fi was always a privacy problem wearing a hospitality badge
Every enterprise eventually invents the same guest pattern:
- Open SSID or a PSK printed at reception
- Captive portal for Acceptable Use
- VLAN isolation and maybe a web filter
- A story that “guest is segmented, so it’s fine”
Segmentation is necessary. It is not encryption. On a legacy open network, a passive adversary with a laptop in the lobby can observe traffic that isn’t protected higher up the stack. Users on HTTP sites, poorly configured apps, and discovery protocols still leak. Even with HTTPS everywhere, metadata and local-network behaviours remain interesting.
As an IT manager, I also hated PSK guest networks for a different reason: password distribution. Rotate it and you print new signs. Don’t rotate it and you’ve created a permanent shared key for every former vendor who ever sat in reception. Neither option is serious access control.
OWE / Enhanced Open is the standards answer to “no password, but not plaintext on the air.”
What OWE actually does
OWE (Opportunistic Wireless Encryption) lets a client and AP perform a Diffie-Hellman exchange during association and use the result to run the normal four-way handshake and encrypt traffic—without a shared password.
From the user perspective:
- See SSID
- Join
- No PSK prompt
- Portal can still appear if you use one
From the security perspective:
- Unicast traffic between client and AP is encrypted
- You reduce passive eavesdropping on the open SSID use case
- You still need VLAN isolation, egress controls, and abuse monitoring—OWE is not 802.1X
Meraki’s WPA3 Encryption and Configuration Guide describes OWE in exactly those operational terms: open-security convenience with encryption, including captive portal scenarios, via DH during association and PMK-driven handshake.
WWT’s WPA3 article lists Enhanced Open benefits the way executives hear them: familiar no-password join, encrypted guest traffic, captive portal compatibility.
The Wi-Fi Alliance’s security page brands this Wi-Fi Enhanced Open™—convenience of open networks with reduced risk versus unsecured open SSIDs.
Transition mode vs pure OWE (where Wi-Fi 6E/7 get strict)
Vendors often support OWE Transition Mode: an open BSS and an OWE BSS paired so legacy clients see a familiar open network while OWE-capable clients get encryption. Meraki documents the dual-beacon behaviour and the user-interface trick where capable clients hide the OWE BSSID and present the open SSID name.
That’s a migration tool for 2.4/5 GHz reality.
It is not the end state for 6 GHz and Wi-Fi 7:
- 6 GHz: Enhanced Open transition mode is not supported (Meraki cites WPA3 spec guidance). Use pure OWE for open-style access on 6 GHz.
- Wi-Fi 7: Legacy open is forbidden for full Wi-Fi 7 behaviour; OWE transition is also out; pure OWE with modern cipher expectations (including GCMP-256) is the path. Redway’s Wi-Fi 7 security post matches that: open and OWE transition fail the Wi-Fi 7 security bar; pure OWE is required to open Wi-Fi 7 for that SSID class.
So if your guest design is “open forever for compatibility,” you’ve also decided that guest won’t fully participate in the new band/feature set. Maybe that’s acceptable. Decide it on purpose.
What OWE does not solve (say this in the design review)
Not authentication of the user. Anyone in range can still join. OWE encrypts the link; it does not identify Alice vs Bob. For visitor accountability you still want a portal, SMS auth, sponsor workflow, or certificate-based guest onboarding on a different SSID.
Not protection against every active attack. Evil twins, malicious portals, and client mis-association remain in the threat model. OWE is opportunistic encryption with the AP you associated to—not a global guarantee the AP is trustworthy.
Not a substitute for segmentation. Guest VLAN, client isolation, no lateral path to corporate, strict egress. Same as before. Encrypted garbage laterally moving into finance is still a bad day.
Not automatic compliance magic. If a policy says “all wireless must use WPA3-Enterprise,” OWE won’t satisfy that wording. Update the policy to allow Enhanced Open for true guest use cases with compensating controls.
How I’d deploy this without creating a help desk fire
1. Separate the stories: corporate vs guest Corporate stays 802.1X / WPA3-Enterprise. Guest becomes OWE (plus portal if required). Stop trying to make one SSID do both “employees with certs” and “someone’s uncle at career day.”
2. Pilot pure OWE on a known client mix Test recent iOS, Android, Windows, and macOS. Note older IoT or specialty visitors that still need a legacy path on 2.4/5 only.
3. Keep portal flows honest OWE encrypts L2 unicast to the AP; the portal still runs at higher layers. Test HTTPS redirects, payment gateways if any, and session timeouts. Most portal bugs are portal bugs—don’t blame OWE first.
4. Use transition only as a bridge If you need OWE transition on 2.4/5 for a quarter, calendar the end date. Don’t extend it quietly for two years. And don’t expect that pattern on 6 GHz / Wi-Fi 7 guest.
5. Instrument abuse Open-style networks attract bandwidth hogs and the occasional hostile scanner. Rate limits, client isolation, DNS logging, and a clear block path matter more once joining is frictionless.
6. Align with the Wi-Fi 7 SSID group plan If your platform groups SSIDs for 11be/6 GHz advertising, a leftover pure-open guest SSID can poison a group’s capability. Meraki’s guide is worth reading before you “just leave Guest-Open in slot 1.”
War story texture (because coffee-chat content should sound lived-in)
I’ve done guest cutovers during live events where the “temporary” open SSID became the only network contractors would use—including contractors who then VPN’d into third-party systems from our address space. Encryption on the air wouldn’t have stopped the policy problem, but the open SSID made eavesdropping trivial for anyone who wanted a free look at unencrypted side channels and local discovery noise.
I’ve also supported PSK guest networks where Facilities laminated the password and facilities staff emailed the same PDF for years. SAE would have improved the crypto; it would not have fixed the PDF. OWE finally matches the requirement people actually state: no shared secret to mismanage.
And yes, during enterprise Wi-Fi migrations, guest is always the SSID someone wants to leave open “until after go-live.” After go-live never comes. If you’re lighting up 6 GHz, that delay also means guest never uses the new spectrum cleanly.
CISSP-aligned takeaways
- Confidentiality on open-style access: OWE addresses passive RF eavesdropping that portals never did
- Access control remains a separate control family: portals, NAC, segmentation
- Secure defaults / architecture: Enhanced Open is the modern default for visitor Wi-Fi; pure open is legacy
- Technology migration risk: transition modes and dual SSIDs need owners and expiry
- Asset and data flow thinking: guest traffic still traverses your edge; encrypt the first hop, control the rest
Practical checklist
- Replace pure open guest with OWE on AP platforms that support it
- Keep captive portal + isolation + egress policy
- Document that OWE ≠ user authentication
- For 6 GHz guest capacity, plan pure OWE, not transition
- For Wi-Fi 7 guest SSIDs, expect pure OWE + modern cipher (e.g. GCMP-256) requirements
- Retire wall-posted PSKs unless you have a device class that truly needs WPA3-Personal
Actionable takeaway
OWE / Enhanced Open is how you stop treating “easy guest Wi-Fi” as “unencrypted guest Wi-Fi.” Users still join without a shared password; the air link is no longer a free passive tap. Pair it with isolation and portal or sponsorship controls, use transition modes only briefly, and for 6 GHz / Wi-Fi 7 design pure OWE from the start. That’s guest networking that matches how people behave—and how modern Wi-Fi security is written.