Passpoint profiles are getting simpler: what the WBA's new framework means for venues

Anyone who has deployed Passpoint at scale knows the pattern. The network side works. The authentication works. Then a support ticket comes in: one user's phone connects fine, another's won't, and nobody can tell which profile is installed on which device, who installed it, or whether it's expired.

The Wireless Broadband Alliance (WBA) has been working on exactly this problem. Its Passpoint Profile Standardization Framework — developed with participation from Apple, Google, AT&T, Boingo, Charter, Cisco, Comcast, HPE, RUCKUS and many others — lays out how Passpoint profiles should be structured, provisioned, and shown to users. Here's what's in it, and why it matters if you run Wi-Fi in a venue or enterprise.

First, the vocabulary problem

“Profile,” “file,” and “subscription” get used interchangeably, which causes real confusion. The framework draws clear lines:

• Passpoint Profile — the container file (often XML, or a carrier bundle) downloaded and installed on a device. One profile can hold one or more subscriptions.
• Subscription (PPS MO) — the Per-Provider Subscription Management Object inside it, holding the credentials, policies, and configuration needed for network access.
• Network Name vs. Operator Friendly Name vs. SSID — the network's identity advertised over ANQP, the human-readable provider name from the subscription, and the broadcast SSID, respectively. In a Passpoint world, the Friendly Name is usually what users should see, not the SSID.
• User-provisioned vs. carrier/enterprise bundles — profiles a user installs themselves (and can remove), versus centrally managed profiles from a carrier or MDM that users can disable but not delete.

A leaner subscription object

The PPS MO was designed to standardize provisioning across devices, but adoption has been uneven and real deployments have shown that some fields are never used while others are missing. The WBA group reviewed every node and submitted recommendations to the Wi-Fi Alliance:

• Deprecate what nobody uses. Examples include credential-sharing flags, soft-token app references, credential priority (profiles should contain one credential), SSID- and HESSID-based home network matching (domain-based matching is preferred), and usage limits like data caps and time limits that are rarely enforced.
• Keep what's essential. Home service provider FQDN and friendly name, roaming consortium OIs, realm, EAP method details, SIM IMSI and EAP type, certificate fingerprints, preferred roaming partners, and an update identifier to track changes.
• Add what's missing. New optional nodes include an explicit EAP identity for AAA routing, an emergency profile flag (a dormant profile activated by an emergency call or app), and a SubscriptionDetail structure that lets identity providers signal whether home or roaming usage is charged to the user and whether the device should conserve data.

Flattening the format

Today, operating system vendors interpret the profile format differently — some follow the spec closely, others use modified or proprietary formats. For an operator provisioning across iOS, Android, Windows, and macOS, that means building and testing multiple variants of the same profile.

The framework proposes a flat, schema-based encoding in place of deeply nested XML management-object trees: each parameter expressed once, at a single level, as typed key-value pairs in a modern format such as JSON or YAML. Devices take responsibility for converting that unified profile into their native configuration. Fewer layers means less parsing logic, fewer edge cases, and far more consistent cross-platform behavior.

Giving users visibility and control

Passpoint's strength — it's automatic — is also why it can be hard to troubleshoot. The framework recommends that devices let users:

• Enable or disable individual installed profiles.
• Delete profiles, including ones installed by an app, without uninstalling the app (carrier defaults may be excluded).
• Prioritize profiles when more than one could match a network.

It also proposes a “Configured Networks” view in Wi-Fi settings showing who installed each profile (website, app, or carrier), installation and expiry dates, the authentication method, the domain and realm, and which realm or roaming consortium was matched on the current network — but never the credential itself.

What venues and operators should do now

1. Standardize on domain-based matching (FQDN, realm, roaming consortium OIs) rather than SSIDs in new profiles.
2. Keep one credential per profile and track profile versions with the update identifier.
3. Set and document expiry dates, and plan for remediation when profiles lapse.
4. Prefer carrier SIM and federation credentials where possible, which avoid the user-installed profile problem entirely.
5. Monitor authentication outcomes centrally so you can see failure patterns by device type, OS version, and identity provider before users report them.

The bottom line

Passpoint is mature technology with a provisioning problem. The WBA framework is a credible, industry-backed path to simpler profiles, more consistent device behavior, and far easier troubleshooting. Changes will land in operating systems over time — but operators who design to these principles now will have less to unwind later.

Source material: Wireless Broadband Alliance, Passpoint Profile Standardization Framework, v1.0.0. Passpoint® is a registered trademark of Wi-Fi Alliance.