Wi‑Fi That Feels Like Cellular vs Wi‑Fi That Feels Like Home: OpenRoaming and MDUs

OpenRoaming is, in my opinion, one of the best things to happen to public and carrier Wi‑Fi in the last decade, but in MDUs it often solves the wrong problem with the right technology. This is a story about incentives, operational reality, device experience, and where "Wi‑Fi that feels like cellular" aligns or does not, with how people actually live on a network.

This is an opinionated view from someone who designs MDU and residential managed Wi‑Fi today and has spent years in LPV networks where carrier offload gets heavily monetized.

OpenRoaming: Wi‑Fi that feels like cellular

OpenRoaming rides on top of Passpoint (Hotspot 2.0) and classic 802.1X, using the same EAP‑SIM/AKA and EAP‑TLS machinery operators already trust for secure access. Passpoint gives standardized network discovery and secure EAP‑based onboarding, while OpenRoaming adds the PKI and federation fabric that lets identity providers and access providers trust each other in large federation schemes. The result matches what cellular has trained everyone to expect: the device attaches to a trusted network when it sees one, with no captive portal and minimal user friction.

That model is extremely compelling if you own a stadium, an airport, a campus, or a nationwide footprint. Seamless roaming takes pain out of onboarding, supports offload from cellular, and underpins analytics and commercial partnerships where "identity everywhere" has real monetary value. In those worlds, Wi‑Fi is "a big IP pipe plus an identity anchor," not where the messy local services live.

The hidden machinery: PKI, federation, and "who pays"

Under the hood, OpenRoaming is not a clever RADIUS trick; it is a full federation with CAs, policies, and roaming contracts attached. Someone has to:

Operate root and intermediate CAs for the federation PKI.
Define and enforce policy frameworks and onboarding requirements.
Run and secure the roaming fabric (RadSec, WRIX, settlement versus settlement‑free tiers).
Manage contracts, compliance, and data‑sharing rules for all participants.

In a large public venue or telco context, the bill for that machinery has a clear place to land. The operator can justify it with offloading mobile traffic to Wi‑Fi, first‑party analytics on huge device flows, and commercial agreements with partners who care deeply about roaming and identity, with a direct line from "more seamless roaming" to "better KPIs".

Now put that next to a 300‑unit MDU or a small regional operator. Tenants are not asking for their apartment complex SSID to roam to the coffee shop across town, landlords do not want to underwrite a global roaming identity fabric, and the ISP may already be stretching just to deliver basic managed Wi‑Fi; adding global PKI and federation is not a free lunch. That mismatch in incentives is the first big crack between OpenRoaming's sweet spot and the residential world.

Who profits from being your IdP?

OpenRoaming is not a peer‑to‑peer trust mesh; it is a federation with a relatively short list of major identity providers and federation operators in the middle. If you decide to use a commercial provider as your OpenRoaming IdP, that provider is now in the path for every authentication your users perform on participating networks and can see identity and location metadata as part of that process.

The WBA privacy framework does set baseline rules: IdPs and access providers agree on how PII (MAC addresses, IPs, EAP identities, and additional identifiers) may be collected and used, and it requires explicit additional consent if an IdP wants to process that data beyond the baseline OpenRoaming purposes. All of that data is still stored and controlled by the individual OpenRoaming participants, but the commercial incentive to use it for analytics, personalization, and monetization is very real. WBA and its partners openly market Passpoint and OpenRoaming as ways to boost monetization and targeted promotions in verticals like hospitality and retail.

If you choose Cisco, Cloud4Wi, or any other commercial platform as your IdP, you are explicitly trusting that entity's privacy policy and business model, not just the WBA baseline. Technically and contractually, that IdP does not "own" your users, but it does gain a privileged view of who your users are, where they connect, and how often, and nothing in the technology prevents that data from being monetized as long as it stays inside those policies and consents.

From a residential‑privacy standpoint, that feels like the wrong trade for MDUs. Tenants sign leases, not federation contracts, yet their Wi‑Fi footprint can end up feeding a data model optimized for global roaming and marketing rather than "my stuff works in 301."

Privacy: local PSKs versus global IdPs

In a DPSK/PPSK world, your "identity" is a pre‑shared key (or a small bundle of them) anchored to a unit, tenant, or device. That key, and any metadata about which MAC addresses or VLANs it maps to, lives with the operator or MSP and is governed by the same contracts, RFPs, and SLAs that already define what the property owner expects for privacy and data use. Those documents typically spell out what data can be collected about tenants and guests, how long it is retained, and whether any analytics or marketing use is permitted.

When you plug into an OpenRoaming IdP, you are now dealing with a different regulatory and commercial surface. The IdP is typically a third‑party service provider whose business model explicitly includes analytics and "digital engagement" across many venues, not just your property. WBA's own material talks about Passpoint and OpenRoaming as ways to boost monetization and targeted engagement, and its privacy framework is built around letting each IdP and access provider manage user data under its own policy and consents, not under your MDU contract.

With multi‑PSK, the operator already in your contracts handles tenant Wi‑Fi data. With OpenRoaming, a remote IdP you do not control gets a privileged view of identities and connection events across a global federation, and tenants never explicitly negotiated that shift.

MDU reality: local services, local trust

Walk any MDU and the recurring themes from tenants and property managers are almost boringly consistent. Tenants want their TVs and speakers to see each other, their devices not to see the neighbor's, and the network to feel like "my own home Wi‑Fi, not a hotel". Underneath that are concrete technical requirements:

Per‑tenant or per‑unit segmentation (VLANs and subnets) aligned to leases and units.
mDNS and SSDP scoping so Chromecast, Apple TV, and Sonos work within the tenant’s own identity on a property‑wide SSID, not across the entire site.
Simple identity: "this is my Wi‑Fi password" or "this is my unit's credentials," not "this is a roaming identity tied to a federation."

Property and support teams also need designs that are easy to reason about. When unit 304 calls, they want to see "304" reflected in keys, VLANs, and policy, not reverse‑engineer a federated identity transaction across a RadSec fabric.

The device reality: who actually speaks Passpoint?

On paper, Passpoint and OpenRoaming can onboard any device that supports the right EAP methods and can accept a profile. In practice, the ecosystem skews heavily toward phones, tablets, and laptops, where operating systems like Android, iOS, Windows, and macOS have built‑in Passpoint support and reasonable UX for profile and certificate installation. That is perfect for public Wi‑Fi and carrier offload, where those are the majority of devices.

In MDUs, the devices tenants care about most are often the ones that do not speak Passpoint at all or have no usable UX for installing 802.1X or certificate profiles: TVs, game consoles, light bulbs, cameras, smart speakers, water sensors, and other assorted IoT gear. For those endpoints, the model is still "select SSID, type PSK, go," and forcing them through a Passpoint‑style flow either is not possible or adds onboarding friction that nobody in residential wants to own. Masquerading that as "just install this app and you're done" does not feel customer‑ or privacy‑first. Simply installing the app allows for another layer of analytics and monetization.

In other words, OpenRoaming does a great job for the devices most likely to walk through a stadium or airport, while multi‑PSK does a great job for the devices most likely to live in an apartment or home. Even if an MDU operator adopts OpenRoaming for phones and laptops, they still need a parallel story for all the non‑Passpoint devices. Two onboarding models, two sets of failure modes, and more complexity are exactly what most MDU operators do not want.

Multiple‑PSK schemes: local identity that matches expectations

This is where multiple pre‑shared key schemes are a very natural fit. Different vendors call it DPSK, PPSK, MPSK, "private PSK," or "per‑client PSK," but the pattern is the same: each tenant, unit, or device gets its own PSK, and the WLAN maps those keys to the right VLAN and policy behind the scenes.

Locality of credentials
Per‑tenant or per‑unit keys live within that property or operator. When a tenant moves out, you revoke or rotate keys locally and you are done, with no global PKI touch and no federation implications.
Tight mapping to segmentation
The mental model "one PSK per unit to one VLAN per unit" is intuitive and operationally friendly. Support can see immediately which VLAN or unit a device belongs to, and policy follows that mapping naturally.
Expectation alignment and device compatibility
Tenants expect "this is my Wi‑Fi password for this apartment," and multi‑PSK schemes preserve that while still giving operators per‑tenant control. Any device that can join a normal WPA2 or WPA3 PSK network can participate, which matches today's MDU device mix far better than a Passpoint‑only deployment.

DPSK and PPSK keep the device experience in the familiar consumer Wi‑Fi mold: select SSID, type the right PSK (it can even be pre‑provisioned for your unit), and everything from a phone to a console to a smart TV behaves as expected.

Security notes: WPA2 baggage, WPA3 potential

Most multi‑PSK schemes in the field today still ride on WPA2‑PSK, inheriting known issues around the 4‑way handshake and offline attack surfaces, even when operators bolt on tricks like external authentication or enhanced key management. That is one reason standards bodies and security‑minded architects have pushed toward WPA3 and away from legacy PSK designs.

There is real work underway to modernize this. Vendors like RUCKUS are pushing concepts such as Dynamic SAE (often referred to as DPSK3) that bring per‑device PSKs into a WPA3 or SAE‑native world instead of leaving them stuck in WPA2, combining per‑client keys with stronger cryptographic properties. For this kind of approach to graduate from vendor‑specific innovation to industry baseline, Wi‑Fi Alliance and likely IEEE would need to codify patterns that make multi‑PSK, WPA3‑native designs a core requirement in certification programs and standards discussions..

Organizations like WBA naturally have a financial and strategic interest in the success of OpenRoaming and federated identity models, but that does not, and should not, preclude WPA3‑PSK and multi‑PSK schemes from being major topics in standards conversations. In MDUs, where the device mix and tenant expectations fit the "type a passphrase and go" model, evolving PSK‑based designs into a robust WPA3 era is at least as relevant as making sure every phone can carry a roaming certificate profile.

"Can't we just use OpenRoaming with VLANs?" (Technically yes, operationally expensive)

From a pure protocol perspective, nothing stops you from combining Passpoint and OpenRoaming with dynamic VLAN assignment. The SSID can be a Passpoint or OpenRoaming profile, RADIUS still returns standard attributes like VLAN ID, Tunnel‑Private‑Group‑ID, QoS, and rate‑limits, and you can steer each device into a per‑tenant VLAN the same way you would in a traditional 802.1X or multi‑PSK design. The plumbing is familiar to anyone who has operated enterprise Wi‑Fi at scale.

In an MDU, as soon as you want per‑unit VLANs and subnets in the mix, you also need something to translate between a roaming identity and local segmentation. In practice that means a RADIUS proxy or policy engine in the middle that does exactly what you already do with DPSK and PPSK: maintain a mapping of "unit to VLANs to identity," then stamp the right attributes on each authentication. You have not eliminated the per‑unit policy database; you have just added a global federation and a RADIUS proxy layer on top of it.

With DPSK and PPSK, many cloud‑managed platforms (for example RUCKUS One, Mist IoT or MPSK, TP‑Link Omada) handle the PSK‑to‑VLAN logic entirely inside their SaaS control planes, often without any external RADIUS at all. Where you do bring in an external RADIUS platform such as Cloudpath, ElevenOS, RoamingIQ, or similar systems, it is usually because you want more onboarding, branding, or reporting capabilities, not because the basic identity model cannot stand on its own.

With OpenRoaming plus VLANs, you still need that local policy brain, but now it is fed by a federated EAP exchange and is subject to all the additional moving parts and privacy questions that come with it. Operationally, you are doing everything you would do for DPSK or PPSK and then running a roaming federation on top.

The catch is not technical feasibility; it is operational complexity when you stack global federation on top of per‑tenant VLANs, micro‑segments, complex discovery policies, and a support model where help desk staff need simple mental models. OpenRoaming does not make Sonos join the right VLAN, it does not design mDNS boundaries, and it does not simplify "my devices, not my neighbor's."

What it does add is:

A PKI and federation layer that must be monitored, patched, and debugged.
New failure modes such as RadSec fabric issues, federation metadata problems, and IdP quirks, on top of the usual Wi‑Fi and RADIUS issues.
New conversations about data, analytics, and privacy that MDUs are often not staffed or incentivized to handle.

For a stadium serving 50,000 fans where naming rights are at stake, taking on that complexity is reasonable. For a mid‑market MDU portfolio, that same complexity is often just another way to get paged at two in the morning without a clear upside.

Where OpenRoaming earns its keep

OpenRoaming really earns its PKI bill in environments with the following characteristics:

High device churn, low local service expectations
Stadiums, airports, transit systems, malls, convention centers, hospitality, and city Wi‑Fi, where the WLAN's primary job is strong, secure internet access as quickly and invisibly as possible. Local device‑to‑device services are minimal or intentionally suppressed, and client isolation is usually a feature.
Strong overlap with telco identity models
EAP‑SIM and EAP‑AKA align closely with how mobile operators already authenticate subscribers, making Wi‑Fi offload a natural extension of existing identity infrastructure rather than a bolt‑on.
Existing culture of federated identity
Campuses and research networks already live with single sign‑on across institutions and eduroam‑style roaming; for them, OpenRoaming is a logical next step for guest and visitor connectivity across multiple networks.

In these environments, "one identity everywhere" is not theoretical; it directly improves user experience, brand perception, and sometimes revenue. The federation cost and PKI overhead have clear owners and measurable returns.

Where local identity wins: MDUs and SFH

Compare that to MDUs and single‑family homes. Devices are long‑lived and local (TVs, speakers, cameras, consoles), tenants almost always bring expectations from consumer routers, and privacy expectations are personal: "no, the landlord should not see my devices everywhere I go". The success metric is not "minutes of Wi‑Fi roaming" but "my stuff just works inside my unit and around the property."

Local identity schemes based on multiple pre‑shared keys map naturally to this world. They enable simple onboarding flows such as self‑service portals that issue unit‑specific PSK bundles, clean mapping between leases and network policy where you recycle keys and VLANs when a unit churns, and predictable privacy boundaries where what happens on a tenant's VLAN stays on that tenant's VLAN.

The "one identity everywhere" OpenRoaming story has almost no upside for the average tenant but introduces several potential downsides: more complicated privacy narratives around global identities and analytics, more complex failure modes that are hard to explain in a support call, and an unclear funding model. No obvious party wants to pay for global federation so a tenant's phone can auto‑join Wi‑Fi at both the grocery store and their apartment.

A simple decision rule for practitioners

From a practical tech‑lead perspective, a rough decision rule looks like this:

If the primary job is:
"Tens of thousands of transient devices must connect securely and instantly without human interaction"
then OpenRoaming, and Passpoint in general, deserves major consideration in the design.
If the primary job is:
"A tenant's devices must see each other, not their neighbor's, and the property team must be able to reason about the design"
then lead with local identity based on multiple pre‑shared keys (DPSK, PPSK, and equivalents), solid per‑tenant segmentation, and carefully engineered discovery domains.

OpenRoaming can absolutely be layered on top of an MDU platform as an extra feature for public and common areas or for specific enterprise tenants. For the core residential experience in MDUs and single‑family homes, the boring answer is still the correct one: local identity, per‑tenant segmentation, and simple, explainable boundaries.

That is not a knock on OpenRoaming. It is a reminder that technologies designed to make a city feel like one big Wi‑Fi network do not automatically make apartment 301 a better place to listen to Spotify.

Alek (N4OG)