Three Ways Guest Wi-Fi Gets It Wrong

1. Captive Portals: The Default, and the First Thing to Break

A captive portal intercepts a device before it reaches the internet, shows it a web page, and only releases it onto the network once that page is dealt with. In practice, it fails in several specific, well-documented ways:

• •It depends on an embedded browser rendering correctly, and that embedded browser is a known weak point — the Electronic Frontier Foundation has written specifically about how captive portals interfere with wireless security and privacy, precisely because of how they intercept and mediate a device's early connection. EFF, “How Captive Portals Interfere With Wireless Security and Privacy”
• •The network segment is very often unencrypted at the radio layer. Academic research on public Wi-Fi captive portals found that on open networks, traffic is not encrypted at the link layer and can be captured in clear text by anyone else on the same network — a captive portal login page alone does not fix this. arXiv, “On Privacy Risks of Public WiFi Captive Portals”
• •It is an ideal phishing setup.Because users are trained to expect a login page on a new network, a spoofed “evil twin” access point running a look-alike captive portal is one of the more effective, well-documented credential-harvesting techniques in use — including real, prosecuted cases of rogue access points set up specifically to harvest credentials through fake captive portals. Bitdefender, “What are Evil Twin Attacks” | InfiShark, “Credential Harvesting via Captive Portals”

None of this is a failure of any one vendor's implementation — it is what happens whenever a web-based authentication layer is bolted onto a network protocol that was never designed to carry it. It is also not education-specific: Wi-Fi is consistently rated one of the top factors in hotel guest satisfaction, and industry guidance points to slow portal redirects and failed authentication as a leading driver of connectivity complaints — the same embedded-browser and session problems, a different building. Purple.ai, “Hotel WiFi: The Complete Guide for Hoteliers”

2. Google Sign-In on Meraki: The “Obvious” Fix That Breaks the Same Week

The embedded browser error that greets users attempting Google sign-in on guest Wi-Fi

For organisations already running on Google Workspace — schools are the most visible example, but plenty of hotel groups, agencies, and offices run the identical stack — the next instinct is to authenticate Wi-Fi through the identity system everyone already uses. Meraki supports this two different ways — worth naming both, because admins often reach for one without realising the other exists:

• →Google Sign-In on the captive portal splash page — guests authenticate with a Google account instead of a code. Cisco Meraki Documentation, “Google Sign-In”
• →WPA2-Enterprise / 802.1X authenticated directly against Google Workspace — a deeper integration, tying network-layer authentication to the Google directory. Cisco Meraki Documentation, “WPA2-Enterprise with Google Auth” | “External Identity Sources”

Both run into the same wall, and it is not a Meraki bug — it is a Google policy decision. As of September 30, 2021, Google blocked OAuth 2.0 sign-in requests made from embedded browsers (Android WebView, iOS/macOS WKWebView) on security grounds. Google Developers Blog, “Security changes to Google's OAuth 2.0 authorization endpoint in embedded webviews” | Auth0, “Google Blocks OAuth Requests From Embedded Browsers”

Meraki's own response confirms this is not a minor edge case: they shipped a pre-splash info page specifically to warn users to open a full browser manually before attempting Google sign-in — a workaround layered on top of the feature, not a fix to it. To be direct about what that means: we have never met an admin who is genuinely happy running Google-backed Wi-Fi auth. It gets tolerated, not endorsed, and it gets adopted because the fallback in front of them — usually a single password shared across the whole device fleet — feels worse. Ask any Meraki admin running this setup off the record and you will get a shrug, not a recommendation.

3. Certificates: Correct for Staff, Not an Option for Guests

Once portals and Google auth both disappoint, the security-minded next step is EAP-TLS — certificate-based WPA2/WPA3-Enterprise, the gold-standard answer network vendors themselves recommend. It is genuinely a strong mechanism. It also has a documented, specific limitation: it depends on the device being enrolled somewhere first, because that is the only reliable channel to get a certificate onto it.

Industry guidance on this point is blunt — one enterprise Wi-Fi vendor's own technical guide states plainly that “for unmanaged devices, EAP-TLS can be cumbersome,” specifically calling out hotels and retail alongside other guest-heavy settings, and recommends routing guests around 802.1X entirely with a separate captive portal — which returns you to problem #1. Purple.ai, “BYOD WiFi Onboarding: Managing Unmanaged Devices”

Apple's own deployment documentation confirms the certificate payload is designed to be delivered through a device management enrollment flow — precisely the step no visitor's personal device has been through, whether that is a parent at a school gate, a guest at a hotel check-in desk, or a contractor at office reception. Apple Support, “Certificates device management payload settings”

So the honest technical picture is: certificates are the right tool for a population you have an enrollment relationship with — staff, company-owned devices. Guests, by definition, do not have that relationship, so pushing EAP-TLS onto them just relocates the friction from “sign in with Google” to “install this certificate” or “here is yet another portal after all” — worse for the visitor, and now there is certificate authority infrastructure to run as well.

4. What Modernised Guest Access Actually Looks Like

Line up the three approaches and the shared root cause is visible: a captive portal borrows a web session to answer a network question. Google-backed auth borrows an identity system to answer a network question. Certificates answer the question correctly, but only for a population you already manage. None of them were built as theguest Wi-Fi answer — they are what is available when the tools at hand do not have a real one.

The alternative is to stop asking “who is this person” and ask the actual question instead: should this device be allowed on the network, right now, for a bounded window. That is a credential problem, not an identity problem — something issued once, scoped to a device, valid for however long makes sense, revocable on its own without touching anyone else's access, with no browser session, no Google dependency, and no certificate chain in the way.

The better model

A unique, time-limited credential delivered by QR code. No login page, no OAuth policy, no certificate to install.

Scan, connect, done — guest Wi-Fi as it should be

5. It Does Not Stop at Guests

The same underlying problem — no clean way to issue and revoke Wi-Fi access per device, at scale, without a shared secret or an identity-system workaround — exists everywhere on a property, not just at the guest SSID. Staff personal devices, seasonal contractors, a fleet of company-owned laptops that should not all share one password pushed through an MDM profile because there was never a better option: it is the same question, asked at a different scale.

QuuPass treats Wi-Fi credentials as infrastructure, not a one-off guest feature — issuance, expiry, and revocation as a service, for every population on the network, not just the ones at the front gate.

Work with us on your network: [email protected] · airstars.asia · quupass.cloud