Captive Portal

How a captive portal works

The mechanism is conceptually simple but operationally finicky:

1. User connects to the network (open SSID or shared PSK).
2. The gateway issues an IP via DHCP but blocks all internet access for this client.
3. User opens a browser; first HTTP request is intercepted by the gateway.
4. Gateway returns an HTTP redirect to the portal page.
5. User completes the portal (accepts terms, enters email, enters access code, etc.).
6. Portal calls the gateway's API to whitelist the client's MAC address.
7. Gateway removes the block. User can now browse normally.

The client's MAC is the persistent identifier — until it expires from the gateway's whitelist (typically 4-24 hours), subsequent reconnections to the same network skip the portal.

Captive portal detection by the OS

Historically, users had to manually open a browser and try to load any HTTP site to trigger the portal. Modern operating systems detect captive portals automatically by probing known URLs:

When the response doesn't match what's expected — because the gateway redirected to a portal — the OS shows a notification ("Sign in to network") and offers to open the portal. This is what makes captive portals usable in 2026; without OS-level detection, users would have to manually trigger the redirect.

The HTTPS problem

Modern browsers default to HTTPS for almost everything. Captive portals cannot intercept HTTPS — the TLS layer prevents MITM. Three implications:

• Devices that only request HTTPS get stuck. The portal can't redirect them; they just see "site can't be reached" errors. The OS captive portal detection (which deliberately uses HTTP) saves users from this in most cases.
• Portal designers must keep the portal itself on HTTP (or at least an HTTP entry point) so the redirect works. Once redirected to HTTPS, the portal can use HTTPS for the actual form.
• HTTP Strict Transport Security (HSTS) on the target site means even the initial probe goes over HTTPS and fails to redirect.

Most modern captive portals work via the OS detection mechanism, which sidesteps the HTTPS problem. Pure manual access (user opens browser, types URL) is increasingly broken because users usually type HTTPS URLs or use HTTPS bookmarks.

Common captive portal patterns

Terms-only (click-through)

User sees acceptable-use policy, clicks "I Agree." Most common pattern. Shifts legal liability to the user; minimal friction.

Email collection

User enters email address (sometimes name) before being granted access. Used for marketing list building. Required disclosure under various privacy laws.

Time-limited free

"Free WiFi for 30 minutes" — user gets limited-time access, must reauthenticate to continue. Encourages turnover in cafes and airports.

Voucher / code

Hotel gives a printed code at check-in; user enters it. Conference attendees receive codes via email. Provides per-user/per-room tracking.

Paid access

User pays via credit card or in-app purchase for time blocks. Common at airports, on planes, and at some hotels.

Social login

"Sign in with Google/Facebook" — fetches profile data and grants access. Used by some venues for richer customer data.

Captive portal infrastructure for SMBs

Most cloud-managed WiFi platforms provide captive portal as a standard feature:

• Cisco Meraki — built-in click-through and login portals.
• Ubiquiti UniFi — Hotspot Manager with vouchers, payments, social login.
• Aruba Instant On — guest network with captive portal options.
• OPNsense / pfSense — captive portal modules for self-hosted gateways.

Dedicated SaaS providers for guest WiFi (Beambox, Purple, MyWifi) add marketing features on top: SMS verification, customer segmentation, email campaigns triggered by visits, customer dwell-time analytics. Useful for retail; overkill for typical SMBs.

Common operational issues

• HTTPS-only devices get stuck. If a device only accesses HTTPS resources and doesn't trigger OS captive portal detection (rare in 2026 but happens), it shows "no internet" without an option to authenticate. Workaround: open a known-HTTP site like neverssl.com.
• Apps that don't handle redirects. Native apps and IoT devices that don't follow HTTP redirects can't authenticate through a portal — they just fail. Some venues exempt specific device types (game consoles, streaming sticks) by manufacturer OUI or MAC range.
• DNS-based blocking confuses devices. Some captive portals block DNS until authentication; modern OS expect DNS to work for portal detection. Block at HTTP layer, not DNS.
• WPA3 OWE complications. Opportunistic Wireless Encryption (open networks with encryption) is incompatible with classic captive portal flows because OWE devices may not show the "Sign in" prompt the same way.
• EAP-based captive portals don't really exist. Captive portals are an open-network concept; networks using 802.1X with RADIUS authenticate at connection time, no portal.

Privacy and legal considerations

• Acceptable use policy at minimum — what users may and may not do on the network. Provides legal cover if users do something illegal.
• Logging. Many jurisdictions require ISPs (and sometimes commercial WiFi operators) to retain connection logs. Captive portal data (email, MAC, timestamp) often serves this purpose.
• Data collection. If you collect email addresses, GDPR (EU), CCPA (California), and similar regulations apply. Get proper consent; offer unsubscribe.
• Content liability. Operators of public WiFi networks have liability protections in most jurisdictions but only with appropriate AUP and reasonable controls.

Frequently Asked Questions

How does a captive portal actually work?

The network's gateway intercepts the client's first HTTP request and redirects it to the portal URL. The gateway maintains an allow-list of clients (by MAC address) that have completed the portal; new clients are redirected, completed clients pass through. Modern operating systems detect captive portals by sending probe requests to known URLs (e.g., http://captive.apple.com) and showing a special UI when the response doesn't match the expected reply.

Why does my phone show "Sign in to network" when I connect to hotel WiFi?

Your phone detected a captive portal. iOS and Android both periodically probe known URLs to check internet connectivity; when the probe gets redirected to a portal page instead of the expected response, the OS shows a notification and offers to open the portal. This is how phones make captive portals usable — historically you had to manually open a browser and try to load any HTTP site to trigger the redirect.

Why can captive portals not redirect HTTPS?

HTTPS uses TLS, which prevents intermediate parties from intercepting and modifying traffic — the entire point of HTTPS. A captive portal trying to redirect an HTTPS connection would have to perform a TLS MITM, which fails because the portal doesn't have the target site's certificate. Browsers show a certificate error. This is why captive portal detection on modern devices uses HTTP (not HTTPS) probe URLs specifically, and why portals struggle when users only browse HTTPS sites.

Are captive portals secure?

Limited security. A captive portal proves the user clicked through and accepted terms, but it doesn't actually encrypt their traffic or strongly authenticate them — the network is typically open WiFi or shared PSK. Use a VPN if you need privacy on public WiFi. From the operator's perspective, captive portals provide acceptable-use policy enforcement, optional email collection for marketing, and time-limited access controls; they are operationally useful but not a strong security mechanism.