TL;DR: A captive portal in 2026 needs support for the IETF CAPPORT standards (RFC 8908 and RFC 8910), granular consent capture separated from network access, multiple authentication methods, broad hardware compatibility, an API for delivering visitor data to a CRM or CDP, and a documented data-ownership position. Splash-screen customization is the least important item on that list.
Most captive portal requirement documents are written backwards. They start with what the login page should look like and end, if they get there at all, with what happens to the data.
Reverse it. A captive portal is a data-capture and consent instrument that happens to have a login screen attached. Here is what it needs to do, in the order that matters.
1. Support the CAPPORT standards, not just DNS interception
This is the requirement almost no procurement document contains, and it is the one that will age the rest of the platform.
What to ask a vendor: does your portal advertise an RFC 8908 API endpoint, and can it be provisioned via RFC 8910 DHCP options? If the answer is a blank look, the platform is built on interception techniques that the IETF working group itself justified replacing on the grounds that “existing interception techniques will become less effective.”
2. Handle consent properly, and separately from access
This is where most portals create legal exposure without anyone noticing.
GDPR Article 4(11) defines consent as a “freely given, specific, informed and unambiguous indication of the data subject’s wishes.” The provision that bites captive portals is Article 7(4): when assessing whether consent is freely given, “utmost account shall be taken of whether… the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.”
In plain terms: a portal that says tick this marketing box or you don’t get WiFi is bundling consent with service delivery, and that is exactly the pattern Article 7(4) targets.
Separately, ePrivacy Directive 2002/58/EC Article 13(1) requires prior consent for direct marketing by electronic mail, with a narrow “soft opt-in” at Article 13(2) for an existing customer’s own similar products and that route still requires a free, easy objection mechanism at collection and in every message.
Portal requirements that follow:
- Network access and marketing consent must be separately actionable. Connecting without opting in has to be possible.
- Consent must be granular — email marketing, SMS marketing and analytics are different purposes.
- Every consent event needs a timestamped, exportable record: what was shown, what was ticked, when.
- Withdrawal must be as easy as granting.
- Data residency must be configurable if you operate across jurisdictions.
3. Offer more than one authentication method and know their limits
Different venues need different front doors. A hotel needs room-number validation; a shopping centre wants email capture; a corporate campus wants SSO.
| Method | Best for | Watch out for |
| Audience building | Disposable addresses; requires verification to be worth anything | |
| SMS / OTP | Verified identity, high-value venues | Per-message cost; see the NIST note below |
| Social login | Low-friction sign-up | Platform dependency and API deprecation risk |
| Voucher / access code | Hotels, paid WiFi, events | Distribution overhead |
| SSO / 802.1X | Corporate, campus, staff networks | IEEE 802.1X-2020 is the current standard; not a guest-friendly path |
| Passpoint / Hotspot 2.0 | Repeat visitors | Automatic connection means no portal — and no new consent |
Two caveats worth writing into a requirements document.
On SMS: NIST Special Publication 800-63B revision 4 treats the public telephone network as a constrained channel, restricting out-of-band verification over the PSTN and permitting SMS or voice OTP only subject to additional conditions. It also states plainly that email SHALL NOT be used for out-of-band authentication. This governs SMS as an authentication factor rather than as a guest-WiFi identity step, but it is a citable reason not to describe SMS-OTP as strong authentication in a security review.
On social login: build for its absence. Platform WiFi login products have been withdrawn before with limited notice, and a portal whose only identity path is a third-party API is a portal with a single point of failure outside your control.
Worth noting alongside this: Wi-Fi Enhanced Open, built on RFC 8110 Opportunistic Wireless Encryption, provides unauthenticated encryption on open networks. It improves guest security without touching the portal flow, and it is a reasonable thing to require of the underlying network.
4. Work with the hardware you already own
A portal that supports three access point vendors is a portal that constrains your estate.
The realistic compatibility list for a multi-site operator spans Cisco, Meraki, Aruba, Ruckus, UniFi, Fortinet, MikroTik, Extreme, Juniper Mist, Cambium and Alcatel-Lucent — because acquisitions, phased refreshes and regional deployments mean almost nobody runs one vendor everywhere. Aislelabs publishes a full hardware integration list for exactly this reason; ask any vendor for theirs in writing rather than accepting “we support all major vendors.”
Ask specifically about RADIUS behaviour, walled-garden configuration, and whether the portal requires a controller, a cloud tenant, or an on-premise appliance.
5. Get detection right across every operating system
A portal that does not reliably trigger is worse than no portal, because the visitor blames the venue’s WiFi.
Each OS uses its own probe to decide whether a network is captive:
- Apple documents captive.apple.com as its “internet connectivity validation for networks that use captive portals,” on TCP 80 and 443, across iOS, iPadOS, tvOS, macOS and visionOS.
- Google names connectivitycheck.gstatic.com as the ChromeOS default HTTP probe and https://www.google.com as the HTTPS probe, with connectivitycheck.android.com used for Android app connectivity checks.
- Microsoft runs the Network Connectivity Status Indicator across two domains: www.msftconnecttest.com for the HTTP probe and dns.msftncsi.com for the DNS probe. Microsoft’s documentation is explicit that portals must not allow access to www.msftncsi.com before authentication, and must redirect all requests consistently rather than redirecting some and silently dropping others.
Requirement: the vendor should be able to describe this behaviour without being prompted. Inconsistent redirect handling is the single most common cause of “the WiFi doesn’t work” complaints that are actually portal misconfiguration.
6. Let the data leave
A portal that collects visitor data into a dashboard you cannot export from is a liability dressed as an asset.
- API access for programmatic retrieval, not just CSV download.
- Native integrations to the systems the marketing team already uses — CRM, CDP, ESP, loyalty.
- Webhook or streaming delivery for near-real-time triggers.
- A documented ownership and deletion position: who owns the visitor records, what format they export in, and what happens at contract termination. Get this in the contract, not the sales deck.
7. Everything else
These matter, but less than the six above:
- Multi-tenancy and role-based access — essential for operators managing multiple properties or partners managing multiple clients.
- Branding and templates — per-site branding, multi-language support, and mobile-first rendering. Note this is a splash page concern, and splash page is not a synonym for captive portal: a splash page displays a message, a captive portal controls network access.
- Bandwidth and session controls — time limits, throttling, tiered access.
- Surveys and progressive profiling — capture more on the third visit than the first.
- Analytics — visit frequency, dwell, new versus returning. This is where the portal stops being a login screen and starts being an instrument.
- Certifications — ISO 27001 and equivalent attestations are procurement gates in enterprise and public-sector deals, not preferences.
The 12-question vendor checklist
- Do you advertise an RFC 8908 Captive Portal API endpoint?
- Can it be provisioned via RFC 8910 DHCP options 114 / 103 / RA type 37?
- Can a visitor connect without giving marketing consent?
- Is consent recorded with a timestamp and exportable?
- Is consent granular by channel and purpose?
- Which authentication methods are supported natively?
- What is the full hardware compatibility list?
- How does the portal behave against Apple, Google and Microsoft connectivity probes?
- Is there an API, and what is rate-limited?
- Who owns the visitor data, in what format does it export, and what happens at termination?
- Is the console multi-tenant with role-based access?
- What security certifications do you hold, and can you produce the current certificate?
A vendor who answers the first two without hesitation is building for where captive portals are going. A vendor who answers only questions 11 and 12 well is selling you a login page.
Frequently asked questions
The essential features are CAPPORT standards support (RFC 8908 and RFC 8910), consent capture that is separate from network access and recorded with timestamps, multiple authentication methods, broad access point compatibility, reliable captive-network detection across iOS, Android and Windows, and API-based data export to a CRM or CDP.
A captive portal is a web page that intercepts a device’s network access until the user completes an action — accepting terms, logging in, or providing an identifier. It controls access at the network level, which distinguishes it from a splash page, which only displays content after connection is granted.
No. A captive portal controls network access — the device cannot reach the internet until the portal flow completes. A splash page is a page displayed to the user, typically after access is granted. The terms are often used interchangeably in marketing material, but the technical distinction affects what the platform can enforce.
It is legally fragile in the EU and UK. GDPR Article 7(4) requires that when assessing whether consent is freely given, regulators take utmost account of whether service provision is conditional on consent that is not necessary for that service. Best practice is to let visitors connect without opting in, and to record consent separately and granularly.
It depends on the venue. Email suits audience building, SMS suits verified identity in high-value venues, vouchers suit hotels and paid access, and Passpoint suits repeat visitors. Most multi-site operators need more than one, and should avoid depending solely on a third-party social login API.
Related reading
- how to set up a guest WiFi portal — the implementation sequence once you have chosen a platform
- OpenRoaming, Passpoint and Hotspot 2.0 — the standards behind automatic reconnection
- how WiFi marketing platforms differ — the vendor categories this checklist applies to
- de-anonymization and consent — the privacy architecture behind requirement 2
- monetizing the guest network — what the portal can earn once the audience exists
Aislelabs Connect is a captive portal and guest WiFi platform supporting traditional portals and Hotspot 2.0 / Passpoint across a published list of access point vendors, with granular consent capture and API delivery into CRM and CDP systems. See the platform or request a demo.
