Passpoint and Hotspot 2.0 Security Guide

Passpoint lets devices join Wi-Fi automatically and securely, but that convenience moves trust into installed profiles, server certificate rules and a federation of operators the user never sees. Passpoint is the Wi-Fi Alliance certification for automatic network discovery, selection and authentication (the underlying specification is widely known as Hotspot 2.0), and it underpins roaming federations such as the Wireless Broadband Alliance's OpenRoaming. This guide explains how Passpoint and OpenRoaming are structured, what makes a profile trustworthy, which credentials and certificates are involved, and how to deploy, test and assess them. It is for network, mobility and identity teams running venue, campus, carrier or enterprise Wi-Fi, and goes deeper on roaming and profile trust than the general Wi-Fi Security Guide.

Key takeaways

The profile is the trust anchor. A Passpoint profile carries the home domain, realms, roaming consortium identifiers, credential and the CA used to validate the AAA server; a weak profile undoes the strong radio security.
Server validation must be pinned. Specify a trust root and the accepted AAA server names; Android otherwise falls back to public CAs, and on Apple devices trusted server names (or an anchored CA) suppress the user trust prompt.
OpenRoaming is a PKI federation. Access and identity providers exchange RADIUS over TLS (RadSec, RFC 6614) using certificates from a WBA private PKI, so those certificates are critical machine identities.
Online sign-up has gone. Android's documentation records that the Wi-Fi Alliance deprecated Online Sign-Up (OSU) as of 30 June 2023, so provisioning now relies on apps, MDM or downloaded profiles.
Privacy is designed in but must be configured. Anonymous outer identities and rotating Chargeable-User-Identity values prevent visited networks from tracking users across sessions.

What it is and who it applies to

Passpoint certifies Wi-Fi access points, controllers and devices for automatic discovery, seamless roaming between hotspots and, in the Wi-Fi Alliance's words, enhanced WPA3 security. Before associating, a device queries the access point (using the IEEE 802.11u interworking and ANQP query mechanism) for the realms, roaming consortium identifiers and operator names it serves, and joins only if one matches an installed profile. Authentication then uses enterprise EAP methods over 802.1X, never a shared passphrase or a captive portal login.

Android records three Passpoint releases relevant to deployment:

Release	Main additions	Android support (per AOSP documentation)
R1	Automatic discovery and EAP authentication; profiles provisioned by web download	Since Android 6.0
R2	Online Sign-Up (OSU) and subscription provisioning of EAP-TTLS profiles; OSU deprecated by the Wi-Fi Alliance as of 30 June 2023	Android 10
R3	Terms and conditions acceptance, venue information URLs, decorated identity prefixes, deauthentication-imminent handling	Android 12

Android 11 and later make Passpoint a requirement for devices with Wi-Fi, and Apple platforms have supported Passpoint configuration in managed Wi-Fi profiles since iOS 7 and macOS 10.9. The guide applies to:

Access network providers (ANPs): venues, campuses, retailers and municipalities that broadcast Passpoint and accept roaming users.
Identity providers (IDPs): mobile operators, cable providers, universities, enterprises and app owners who issue profiles and authenticate users.
Enterprises: organisations using Passpoint for staff roaming across their own sites or into partner and public networks.

Structure and key requirements

Passpoint profile elements

Element	Purpose	Security requirement
Home SP domain (FQDN) and friendly name	Identifies the provider; Apple key `DomainName`, `DisplayedOperatorName`	Must match the provider's own domain; do not reuse generic names users cannot verify
Roaming consortium OIs (RCOIs)	Federation memberships the profile can roam into; Apple key `RoamingConsortiumOIs`	Include only the federations you have agreements and policies for
NAI realms and MCC/MNC	Realms the provider authenticates; mobile network codes for SIM credentials	Publish the realm in ANQP; Android advises this for EAP-SIM/AKA auto-connect reliability
Credential	SIM (EAP-SIM, EAP-AKA, EAP-AKA'), certificate (EAP-TLS) or username and password (EAP-TTLS)	Prefer SIM or certificate; password credentials need strong server validation
Trust root CA	Validates the AAA server certificate; Apple `PayloadCertificateAnchorUUID`	Always set; Android checks public CAs if omitted
AAA server trusted names	Accepted server certificate names; Android 11 and later, Apple `TLSTrustedServerNames`	Always set, narrowly, so a valid certificate for another name is refused
Expiry and terms URLs	Profile validity; R3 terms and conditions	Android requires HTTPS for terms URLs and blocks the network otherwise

OpenRoaming federation structure

OpenRoaming is the WBA's roaming federation built on Passpoint and its WRIX standards. Its technical detail is documented in an Internet-Draft, draft-tomas-openroaming-08 (12 June 2026), an Independent Submission with Informational intent that the IETF has not endorsed; treat details as current WBA practice that may change. As described there:

Roles: ANPs configure OpenRoaming RCOIs on their Wi-Fi equipment and need not join the WBA; IDPs place RCOIs in their users' Passpoint profiles and authenticate them; brokers are WBA members that assign WBA identifiers (WBAIDs) and run issuing CAs or registration authorities.
Base RCOIs: five-octet values, with OpenRoaming-Settled (BA-A2-D0-xx-x, the ANP expects payment) and OpenRoaming-Settlement-Free (5A-03-BA-xx-x). Context bits encode policy: level of assurance (baseline ISO/IEC 29115 LoA 2 or enhanced LoA 3), quality of service tier, whether a persistent user identifier may be returned (only with user consent), identity type and long-lived or short-lived on-boarding.
Signalling: RADIUS over TLS (RadSec, RFC 6614, an Experimental RFC updated by RFC 8996 and RFC 9765) with mutual TLS and dynamic peer discovery per RFC 7585 using the aaa+auth NAPTR tag.
RADIUS profile: ANPs must support accounting for all sessions, include Chargeable-User-Identity (attribute 89) in Access-Requests and put their country code in Location-Data (attribute 128); IDPs must answer every Access-Request and Accounting-Request.

Identity and NHI requirements

Passpoint replaces human logins with device-held credentials and server-to-server trust, so most of its security is machine identity management.

RadSec entity certificates: each OpenRoaming participant's RADIUS server authenticates with a certificate from the WBA PKI, which has four levels (root, policy intermediate, issuing intermediate or registration authority run by brokers, and entity certificates). The WBAID sits in the certificate Subject UID. Inventory these certificates, monitor expiry, protect private keys in hardware where possible and rotate on staff or supplier change. See the Machine Identity, PKI and Certificate Lifecycle Guide.
AAA server certificates: the certificate presented inside EAP is what every device validates. Use a dedicated CA or a dedicated name, keep the trust root in the profile, and plan renewals so that the chain the profile pins does not change unexpectedly. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
Device credentials: client certificates for EAP-TLS are device identities. Android's R1 download format requires the PKCS #12 container to be unencrypted, so the delivery channel must be HTTPS and access-controlled; prefer MDM or app-based enrolment with keys generated on the device.
Password credentials: Android notes that passwords in downloaded profiles are base64-encoded, which is not encryption. Treat profile files as secrets and issue per-device credentials that can be revoked individually.
RADIUS shared secrets and hubs: any remaining static RADIUS links (for example to an internal proxy) use shared secrets that are long-lived NHI credentials. See the RADIUS Security Guide.
User privacy identifiers: use an anonymised outer identity where the EAP method allows it. The draft cites WRIX guidance to refresh CUI and Class correlation keys no more often than every 2 hours and at least every 48 hours, unless the user consented to a persistent identifier.

Implementation steps

Decide your role and federations. Are you an ANP, an IDP or both? Choose which RCOIs to advertise or include (your own, OpenRoaming settled or settlement-free) and record the policy each implies, especially level of assurance and identifier sharing.
Build the AAA and PKI layer first. Stand up RadSec-capable RADIUS servers, obtain entity certificates through a broker if joining OpenRoaming, configure DNS NAPTR records for dynamic discovery and, where DNSSEC is not used, put your realm in the server certificate's subject alternative name as the draft recommends.
Configure the radio side. Enable Passpoint on controllers or access points with WPA3-Enterprise where all target devices support it, advertise realms, RCOIs and operator names in ANQP, and keep Passpoint on a dedicated SSID separate from captive-portal guest networks. See the WPA3 Migration and Transition Mode Guide.
Write profiles conservatively. Include the trust root and trusted AAA server names, set an expiry, include only required RCOIs, and choose SIM or certificate credentials where possible.
Provision through a controlled channel. Use MDM (Apple managed Wi-Fi payload with IsHotspot enabled, Android enterprise management) or an authenticated app. For web download on Android, serve the application/x-wifi-config file over HTTPS after a user tap.
Pilot with a test realm. Test on representative Android and Apple versions: auto-join, roaming into partner networks, server name mismatch (must fail), expired profile (must not auto-join), and terms acceptance for R3.
Roll out by site and population. Start with managed staff devices, then customers. Keep the previous SSID available during transition as the rollback path, and remove it once connection success is stable.
Operate. Monitor RadSec connections with Status-Server (RFC 5997), alert on certificate expiry, and review federation membership and RCOIs at least annually.

Choosing a credential type

Credential	Best for	Strengths	Watch for
SIM (EAP-SIM, EAP-AKA, EAP-AKA')	Mobile operators and their subscribers	No user secret to steal; strong device binding	Prefer EAP-AKA' where supported; IMSI privacy depends on operator configuration
Certificate (EAP-TLS)	Enterprises, universities, app-based IDPs	Phishing-resistant, revocable per device	Certificate issuance, renewal and key protection on devices
Username and password (EAP-TTLS)	Legacy subscriber bases	Easy to issue	Credentials exposed if server validation is weak; base64 profile passwords

Small venues usually act only as ANPs through a managed Wi-Fi provider and should focus on correct RCOI advertisement and RadSec certificate custody. Large organisations acting as IDPs carry the heavier load: PKI, profile issuance and privacy commitments.

Evidence and assessment

Profile review: export sample profiles and confirm trust root, trusted server names, expiry and minimal RCOIs. A profile without trusted server names is a finding.
Negative testing: present a test AAA certificate from a public CA with a different name; devices must refuse. Record results per OS version.
PKI evidence: certificate inventory for RadSec and AAA servers with expiry dates, key storage and renewal owners.
Logging: RADIUS authentication and accounting logs with realm, CUI, Operator-Name and outcome, retained per policy. See the Public Wi-Fi Safety Guide for the user side.

Metrics:

Passpoint authentication success rate per realm and per OS version.
Share of profiles in circulation with pinned trust root and trusted server names (target: 100 per cent).
Days to expiry of the soonest RadSec and AAA certificates (alert under 30 days).
Authentication failures caused by server certificate rejection after changes (should be zero outside tests).
Share of roaming sessions using SIM or certificate credentials rather than passwords.

Mapping to other frameworks

Framework	Reference	Passpoint relevance
NIST SP 800-53 Rev. 5	AC-18 Wireless Access; AC-18(1) Authentication and Encryption	Enterprise EAP authentication and encryption for wireless
NIST SP 800-53 Rev. 5	IA-3 Device Identification and Authentication; IA-5(2) Public Key-based Authentication	Device credentials and certificate validation
NIST SP 800-53 Rev. 5	SC-17 Public Key Infrastructure Certificates; SC-8 Transmission Confidentiality and Integrity	RadSec PKI and protected RADIUS transport
NIST SP 800-53 Rev. 5	AU-2 Event Logging	RADIUS authentication and accounting records
NIST CSF 2.0	PR.AA-01; PR.AA-03; PR.IR-01; DE.CM-01	Credential management, authentication, network protection and monitoring
ISO/IEC 27001:2022 Annex A	A.8.5 Secure authentication; A.8.20 Networks security	Authentication design and network controls
MITRE ATT&CK	T1557 Adversary-in-the-Middle; T1040 Network Sniffing	Threats that server validation and encryption counter

Common pitfalls

Profiles without server name pinning: any certificate chaining to a public CA is then accepted, which enables rogue access points running their own RADIUS to harvest password credentials.
Over-broad RCOIs: including federation identifiers "just in case" sends users onto networks whose policies, logging and level of assurance you have not reviewed.
Insecure profile distribution: emailing or hosting profile files over plain HTTP exposes base64 passwords and unencrypted client keys.
Unowned RadSec certificates: a federation certificate issued once by a project team expires and roaming fails across every site at once.
Relying on OSU: designs that still expect online sign-up, deprecated in 2023, leave users without a working provisioning path.
Persistent identifiers without consent: returning a stable CUI or user identity to visited networks breaks the privacy model and may breach data protection commitments.

Practitioner checklist

Document your role (ANP, IDP or both) and every RCOI you advertise or include, with its policy.
Pin a trust root and narrow AAA server names in every profile; test that mismatches fail.
Set profile expiry and a renewal process.
Prefer SIM or certificate credentials; issue per-device credentials that can be revoked.
Distribute profiles only via MDM, authenticated apps or HTTPS download.
Inventory RadSec and AAA certificates with owners and expiry alerts.
Use anonymous outer identities and rotate CUI unless users consent otherwise.
Log RADIUS authentication and accounting with realm and outcome, and review failures.
Keep a rollback SSID during migration and retire it once success rates are stable.

Passpoint and Hotspot 2.0 Security: Profiles, Credentials and OpenRoaming Trust Explained