Passpoint and guest marketing: keeping first-party data when guests auto-connect

Venues keep first-party data under Passpoint by moving consent from the splash page to enrolment. A guest opts in once, on a captive portal, web page or app, then receives a Passpoint credential tied to that profile. Every later auto-connect authenticates the credential through RADIUS, so each visit updates the consented profile without another login screen.

What is Passpoint guest marketing?

Passpoint is the certification programme for Hotspot 2.0, a set of capabilities built on the IEEE 802.11u amendment. It lets a phone or laptop find and join a network automatically, using a credential installed in advance. The guest never sees a login screen.

Three standards do the work:

• ANQP (Access Network Query Protocol) lets the device ask an access point which identity providers the network accepts. This happens before the device associates.
• IEEE 802.1X, the port-based access control standard, authenticates the device. It uses an EAP (Extensible Authentication Protocol) method such as EAP-TLS or EAP-TTLS.
• RADIUS is the protocol access points use to ask a server whether a credential is valid. The RADIUS server accepts or rejects the connection, and traffic is then encrypted with WPA2-Enterprise or WPA3-Enterprise.

OpenRoaming is a federation run by the Wireless Broadband Alliance and built on Passpoint. Identity providers issue the credentials. These include device makers, mobile operators and app publishers. Venues act as access network providers that accept those credentials. Venue and identity provider exchange authentication over RadSec, which carries RADIUS inside TLS (RFC 6614).

Passpoint guest marketing means running a consented marketing and analytics programme on visitors who join this way. The alternative route is a captive portal: the splash page that intercepts a visitor's first web request and asks them to log in. For most venues, the captive portal is still where consent, identity and first-party data come from.

Why does auto-connect put your first-party data at risk?

On a Guest WiFi network, the splash page does three jobs at once. It identifies the visitor, records their marketing choices and logs the visit. Purple processed 440 million logins in 2024 across 80,000+ live venues (Purple data). Each login was a moment where all three jobs happened together.

Passpoint removes that moment. The device authenticates in the background, so there is no page on which to ask a question. Three consequences follow.

A connection is not consent

GDPR Article 4(11) defines consent as a freely given, specific, informed and unambiguous indication of wishes. Recital 32 adds that silence, pre-ticked boxes or inactivity do not count as consent. A device joining automatically is inactivity in legal terms. You cannot infer marketing consent from a Passpoint connection.

You may not see who connected

EAP methods such as EAP-TTLS send an outer identity that can be anonymous, for example "anonymous@realm". The real identity travels inside an encrypted tunnel to the home RADIUS server. In OpenRoaming, that server belongs to the identity provider, not to you. You receive only what the identity provider chooses to release.

MAC addresses no longer identify devices

Current iOS and Android releases use a private, randomised MAC address per network by default. Any analytics that joined visits by MAC address will undercount returning visitors. A Passpoint credential is a more reliable anchor, provided you issue it or can see it.

The gains are real. Passpoint encrypts every session with WPA2- or WPA3-Enterprise and replaces open SSIDs with 802.1X. It also removes splash-page friction for returning guests. Your task is to keep the consent and the data while you take those gains.

How does consent travel with a Passpoint credential?

The principle is to move the consent moment to enrolment, then let the credential carry it. Five design choices make that work.

Capture consent once, at enrolment

The first visit still needs a moment of choice. That moment can be a captive portal, a web page linked from a booking confirmation, or a step inside a venue app. At that point you collect conscious-choice opt-ins: separate, unticked choices for email, SMS and personalised offers.

GDPR Article 7(1) requires you to demonstrate that consent was given. Store the wording shown, the timestamp and each choice against the profile. Tell the guest plainly that later automatic connections will be recorded as visits. Article 13 requires that information at the point of collection.

Purple's captive portal already captures this consent record and integrates with CRM and marketing platforms. When you issue a Passpoint profile at the end of that flow, the same record covers every future visit.

Bind each credential to one profile

Issue every visitor a unique credential, never a shared one. A username and password for EAP-TTLS works, and so does a certificate for EAP-TLS. The RADIUS server maps each credential back to its consented profile. Every later authentication becomes a visit event against a known record, with no splash page involved.

Unique credentials also give you control over the lifecycle. You can expire a credential at check-out. You can revoke it when a device is lost or when a guest leaves the programme. A shared credential removes all of that and breaks attribution entirely.

Recognise returning visitors without their real identity

Where you do not hold the identity, you can still count visits. RFC 4372 defines the Chargeable-User-Identity attribute, a stable, opaque identifier a home server can return for each visitor. It lets your WiFi Analytics count return visits and dwell time without a name or email address.

Treat that identifier as personal data. GDPR Recital 26 confirms that pseudonymised data stays personal data where extra information could attribute it to a person. Use it for aggregate reporting under a documented lawful basis. Keep it out of marketing sends.

Use Passpoint Release 3 for terms and a venue URL

Passpoint Release 3 adds two features that matter for marketing. A network can require the guest to accept terms and conditions. It can also send a venue URL that the device displays after connecting. Android documents support for both features.

The venue URL is useful for anonymous visitors. It gives you a route to invite them to opt in, without blocking their connection.

Check what each OpenRoaming identity provider releases

OpenRoaming identity providers signal their policy through Roaming Consortium Organisation Identifiers (RCOIs) advertised by the network. That policy includes the type of identity on offer: some providers release an anonymous identity, others a verified one. Check what the providers you accept will release before you plan any campaign. In most deployments, federated visitors arrive anonymous and stay anonymous until they opt in on your terms.

Where does Passpoint sit alongside your captive portal?

Passpoint does not replace your captive portal. It sits beside it. Most venues run a captive-portal SSID for first-time visitors and a Passpoint network for enrolled guests.

Purple is hardware-agnostic and works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Both networks can therefore run on the access points you already own. Hotspot 2.0 support depends on access point model and firmware, so confirm it with your vendor first. Why your next WiFi upgrade doesn't need new hardware explains the cloud overlay approach.

WPA3 makes Protected Management Frames mandatory. Check how your estate handles them before you enable WPA3-Enterprise on the Passpoint SSID. Protected Management Frames: A Practical Guide for 2026 covers the compatibility checks.

How the three join methods compare

	Captive portal	Venue-issued Passpoint	OpenRoaming (federated)
How the visitor joins	Selects the SSID and completes a splash page	Installs a profile once, then auto-connects	Auto-connects with a credential from a third-party identity provider
Where consent is captured	On the splash page, for each new device	At enrolment, before the profile is issued	Not captured by the venue; opt-in invited separately
What the venue receives per visit	Data the visitor enters on the page	A credential mapped to the consented profile	Whatever the identity provider releases, often anonymous
Encryption	Open, or OWE (Opportunistic Wireless Encryption) where supported	WPA2- or WPA3-Enterprise	WPA2- or WPA3-Enterprise
Repeat-visit experience	Splash page again, or a remembered device	No login screen	No login screen
Standards	HTTP redirect; RFC 8908 and RFC 8910 for portal discovery	IEEE 802.11u, IEEE 802.1X, EAP	IEEE 802.11u, IEEE 802.1X, RadSec (RFC 6614)
Best fit	First-time visitors and first-party data capture	Returning guests, loyalty members and coworking members	Visitors you have never met before

Which approach suits your venue

Your situation	Recommended approach
Mostly first-time visitors, such as a tourist attraction	Captive portal with conscious-choice opt-ins
High return rate, such as hotel loyalty members or coworking members	Captive portal for enrolment, then venue-issued Passpoint
High volume of anonymous passers-through, such as a shopping centre, station or train	Captive portal plus OpenRoaming, with aggregate analytics for anonymous visits
Multi-day events with registered attendees	Passpoint profile issued at registration, expiring when the event closes
Patient and visitor networks in healthcare	Captive portal with minimal data capture; Passpoint only for long-stay visitors

Worked scenarios from hotels, retail and events

A 200-room hotel turns loyalty members into auto-connecting guests

Situation. Returning guests at a 200-room hotel met the splash page at every stay. Each new phone or laptop created a separate record. Stay history and consent were scattered across several partial profiles.

What was done. The hotel kept its captive portal for the first stay. It added an "add this network to your device" step at the end of the opt-in flow and in the pre-arrival email. Each guest received a unique EAP-TTLS credential bound to their consented profile. Credentials expired 12 months after the guest's last stay. Visit events synced to the hotel's CRM.

Measurable outcome. The hotel now reports three numbers each month:

• Credential holders as a share of connected guests.
• Stays logged per consented profile.
• Consent records retrievable on request, as Article 7(1) requires.

For credential holders, splash-page logins on return stays fall to zero, because the page never appears. See how this fits a wider Hotels deployment, and use the Hotel WiFi RFP checklist: authentication, content filtering and guest marketing to write it into a tender.

A shopping centre adds OpenRoaming without diluting its opt-in list

Situation. A shopping centre wanted shoppers to connect without friction. Its marketing team worried the opt-in list would shrink as shoppers moved to auto-connect. Most shoppers' phones already carried an OpenRoaming credential from a device or app identity provider.

What was done. The centre ran an OpenRoaming SSID alongside its existing captive portal. Anonymous OpenRoaming visits went into aggregate reporting only, counted by the Chargeable-User-Identity attribute where providers released it. The Passpoint Release 3 venue URL pointed shoppers to an opt-in page for the centre's newsletter. No marketing went to anonymous shoppers.

Measurable outcome. The centre now reports two separate audiences:

• Consented shoppers, who can receive marketing.
• Anonymous returning devices, reported in aggregate only.

The opt-in list grows only through conscious choice. The data protection officer can see that split in every report. The same pattern applies across multi-site Retail estates.

A conference centre issues credentials at registration

Situation. A conference centre hosting three-day events saw queues at the splash page every morning. The queues were worst in the first session of each day. Organisers also wanted attendance data by hall.

What was done. The event registration page carried the opt-in choices and issued a Passpoint profile with each ticket. Each credential expired automatically when the event closed. Attendees connected in every hall without a login step.

Measurable outcome. Registered attendees saw zero splash pages on site. Every credential was revoked automatically at close, with no manual clean-up. Organisers received per-hall session counts in aggregate. Marketing went only to attendees who had opted in at registration.

What are the limits you should know about?

Enrolment adds a step

On Apple devices, the guest installs a configuration profile and approves it in Settings. Android flows vary by manufacturer and OS version. Fewer guests will enrol than complete a splash page. Offer enrolment after you have delivered value, for example at the end of a first stay or in a booking confirmation.

Device support is not universal

Older devices and some laptops lack Passpoint support. Keep the captive portal SSID live so no visitor is locked out. Test enrolment on the devices your guests actually carry.

Federated visitors are not marketable by default

An OpenRoaming credential carries no marketing consent for your venue. In the UK, regulation 22 of the Privacy and Electronic Communications Regulations (PECR) requires consent, or a soft opt-in, before you send marketing email or SMS to individuals. A WiFi connection meets neither test.

Withdrawal must be as easy as consent

GDPR Article 7(3) requires that withdrawing consent is as easy as giving it. Keep marketing consent and network access as separate controls. A guest who unsubscribes from email may still want automatic WiFi.

Some sectors need lighter data capture

Location data on a hospital network can reveal health information. That brings GDPR Article 9 special category rules into play. Keep capture minimal on patient and visitor networks, and never infer health status from visits.

Your RADIUS service carries the load

Every Passpoint connection depends on 802.1X and a reachable RADIUS server holding a valid server certificate. Cloud RADIUS removes on-premises servers from the design. Plan certificate renewal before launch. Network Best Practices for Venues and Enterprises in 2026 covers the surrounding design choices.

What should you do next?

1. Audit your access points. Confirm Hotspot 2.0 and Passpoint support by model and firmware with your vendor.
2. Review your consent wording. Make sure it tells guests that automatic connections will be recorded as visits.
3. Choose your model. Use the decision table above to pick venue-issued Passpoint, OpenRoaming, or both.
4. Design enrolment. Place it at the end of your captive portal flow and in pre-arrival or registration emails.
5. Set credential rules. Use unique credentials, define an expiry and agree who can revoke them.
6. Split your reporting. Keep consented audiences and anonymous aggregate visits in separate reports.
7. Write it into procurement. Specify Passpoint, OpenRoaming and the consent record as tender requirements.

Frequently asked questions

Do I need new access points to run Passpoint?

Usually not. Hotspot 2.0 and Passpoint are features of access point firmware, and Cisco Meraki, HPE Aruba, Ruckus and Juniper Mist all document configuration for them. Support depends on model and firmware version, so check with your vendor first. Purple is hardware-agnostic and runs as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Enrolment and RADIUS need no rip and replace.

Is consent captured at Passpoint enrolment valid under GDPR?

Yes, provided the enrolment step meets the GDPR standard for consent. Article 4(11) requires consent to be freely given, specific, informed and unambiguous, and Article 7(1) requires you to prove it. Use separate, unticked choices for each purpose and store the wording and timestamp. Tell the guest that later connections will be recorded as visits. The credential carries that consent; the connection itself never creates it.

Can I market to visitors who connect through OpenRoaming?

Not on the strength of the connection alone. An OpenRoaming credential comes from a third-party identity provider and carries no marketing consent for your venue. Often you receive only an anonymous identity. You can report anonymous visits in aggregate under a documented lawful basis. Use the Passpoint Release 3 venue URL or your captive portal to invite the visitor to opt in on your terms.

Can Passpoint run alongside my existing captive portal?

Yes, and most venues should run both. Keep the captive portal for first-time visitors, where you capture identity and conscious-choice opt-ins. Advertise a Passpoint network alongside it for enrolled guests, as a separate SSID on the same access points. The captive portal becomes your enrolment route and Passpoint your return route. Your consented database keeps growing while returning guests skip the login screen.

Does Passpoint work on iPhone and Android devices?

Yes, both platforms support Passpoint, with different enrolment flows. Apple devices install Passpoint through a configuration profile that the guest approves in Settings. Android supports Passpoint configuration natively and documents support for Release 3 features, including terms acceptance and venue URLs. Flows vary by manufacturer and OS version. Test enrolment on the devices your guests carry before you launch.

What happens to the data when a guest withdraws consent?

You stop marketing at once and decide separately whether to keep the credential. GDPR Article 7(3) makes withdrawing consent as easy as giving it. A guest who unsubscribes from email may still want automatic WiFi, so keep marketing consent and network access as separate controls. If they ask to leave entirely, revoke the credential in RADIUS. Then delete or anonymise the profile under your retention policy.

How does Passpoint affect my WiFi analytics?

It makes return-visit counts more accurate. Randomised MAC addresses on current iOS and Android devices make device-based counting unreliable, while a Passpoint credential stays stable across visits. With venue-issued credentials, each authentication becomes a visit on a consented profile. For federated visitors, the Chargeable-User-Identity attribute defined in RFC 4372 can supply a stable pseudonym. Keep those pseudonymous visits in aggregate reports, separate from your marketable audience.