Per‑Identity PSKs: The Feature Wi‑Fi Forgot to Standardize

Multiple Pre-Shared Key networks are at the center of many modern Wi‑Fi designs, but you would not know that from reading the 802.11 standards. Most major Wi-Fi vendors ship some flavor of this technology, yet there is still no clean, common, standardized way to describe it in the language of WPA2, WPA3, or 802.11. That gap is more than cosmetic; it makes life harder for Multi-Dwelling Units (MDUs) and multi-family housing, hospitality, AAA vendors, and anyone who wants to build sane operational workflows instead of bespoke glue for each vendor.

Problem statement: Per‑Identity PSKs (I'm going to call them this for now and I'll explain in a bit) including all the DPSK/MPSK/PPSK/iPSK variants, are how MDUs and some hospitality actually deliver per‑tenant and per‑room segmentation on shared SSIDs, but they exist entirely as vendor features with no shared naming, no explicit Authentication and Key Management (AKM) or Robust Security Network (RSN) signaling, and no Wi‑Fi Alliance profile to make them interoperable or testable. As more vendors bolt their own interpretations onto WPA2‑PSK and WPA3‑SAE, the ecosystem drifts into fragmentation, making it harder to treat per‑identity PSK as a first‑class, portable capability instead of a bag of impressive proprietary tricks.

From “multiple PSK” to “per‑identity PSK”

If you've read Simon Lok's multiple‑PSK article, you know how the basic mechanism works. Multiple PSK is not a bespoke encryption handshake; it is a way to use the existing key hierarchy and association flow to give individual keys to multiple clients on the same SSID. The AP or controller collaborates with a system that knows which key to use and then lets the normal WPA‑Personal machinery do exactly what it was designed to do.

Vendors then layered branding on top of that mechanism:

  • DPSK focused on dynamically generating and distributing per‑client keys.
  • MPSK / Multiple‑PSK / Multi‑PSK emphasized “many PSKs, one SSID.”
  • PPSK, iPSK, IPSK, UPSK, xPSK and others tried to highlight “private,” “identity,” or some other nuance of the same basic pattern.

Almost all of these started from the assumption that the “identity” equals a MAC address on the wire. That was a convenient first step, but it is not how operators actually think about ownership or policy in MDUs and hospitality today.

Why “per‑identity” is the right mental model

In real-world deployments, the thing you care about is not the NIC. It is the identity boundary you want to consider.

  • In an MDU, the identity might be a tenant and all of their devices mapped to a unit.
  • In student housing, the identity might be an individual student living as a roommate of a group of other students that all share a physical network.
  • In hospitality, the identity is often the room itself: TVs, set‑top boxes, hubs, and guest devices that all exist inside one network segment while the guest is checked in. The guest is typically another identity that gets put on the same segment.

Conceptually, the workflow is always the same:

  1. Define an identity (device, person, unit, room, bed, tenant).
  2. Give that identity its own pre‑shared key.
  3. Map that identity to policy (VLANs, QoS, ACLs, billing, logging).

The mechanism Simon describes, mapping multiple PSKs to policy, does not care whether the lookup key is a MAC address, a tenant ID, or a room number. That is why “per‑identity PSK” is a better umbrella term: it captures the real design intent, with per‑device PSK as just one important specialization.

Names, layers, and why none of this is standardized

The naming chaos mirrors the standardization story: per‑identity PSKs grew up in the vendor layer, not in the standards bodies.

The Wi‑Fi ecosystem splits across three layers:

  • IEEE 802.11 defines over‑the‑air behavior: frames, RSN, ciphers, AKMs, and the association/key exchange machinery.
  • The Wi‑Fi Alliance builds specifications like WPA2, WPA3, and OpenRoaming on top of specific slices of 802.11, with test plans and provides certification logos.
  • Vendors ship real‑world features on top, solving onboarding and segmentation problems in MDUs, hospitality, and enterprise.

Per‑Identity PSKs live almost entirely in that vendor layer. WPA2‑based deployments still use the standard 4‑way handshake, while WPA3‑SAE uses its own password‑authenticated key exchange, which then feeds into essentially the same key hierarchy. In both cases, the client just thinks it is doing normal WPA‑Personal for that mode. The interesting behavior lives behind the scenes, where controller and AAA logic decide which pre‑shared key, and which policie(s), belong to this particular identity.

Because that behavior never got a dedicated AKM name, a RSN capability bit, or a Wi‑Fi Alliance feature profile or test plan, each vendor invented its own label, its own RADIUS attributes, and its own way of wiring policy to keys. The result is what everyone sees today: most serious platforms “have it,” nobody calls it the same thing, and interoperability depends more on guesswork than specification.

“Just use WPA3 + X” is not enough

Vendors that do not yet have a clean WPA3‑SAE + Multi‑PSK story are understandably leaning on alternatives. You will see recommendations along the lines of:

  • “Use OpenRoaming or Passpoint because they already support WPA3.”
  • “Move everything to EAP‑TTLS or EAP‑TLS and be done with PSKs.”
  • “Rely on identity‑based roaming and 802.1X instead of per‑device or per‑room keys.”

All of those are valid tools in the right context, but in MDUs and hospitality they run into the same set of realities:

  • Administrative and PKI overhead
    OpenRoaming and Passpoint bring federation, certificate management, policy frameworks, and roaming fabrics that make sense for stadiums and airports. In a 300‑unit MDU, that machinery is a lot of weight to carry just to replace per‑unit PSKs that already work.

  • True BYOD device mixes
    MDUs and hotels are full of TVs, consoles, streaming sticks, smart speakers, cameras, and IoT widgets that will never do 802.1X gracefully or accept EAP‑TLS/TTLS profiles. Those devices live in a “select SSID, type PSK” world, and no amount of roaming identity hand‑waving changes that.

  • Dynamic VLAN assignment as the anchor
    Per‑unit and per‑room VLANs are how operators reason about isolation, troubleshooting, and billing. Multi‑PSK models map very cleanly to that: PSK → identity → VLAN. You can bolt VLAN assignment onto other schemes, but it often becomes brittle or opaque compared to the straightforward PSK‑to‑VLAN mapping that MDUs and hospitality already rely on.

The result is that “WPA3 + X” might look great on a slide, but on the ground it usually means higher operational overhead, more moving parts, and a stubborn pile of devices that still just want a simple PSK.

I was recently asked by a few customers and team members about OpenRoaming and I went down a pretty deep rabbit hole on what it's capable of and how to implement it. You can read my thoughts Here, but be aware it's quite a bit more opiniated than this entry.

WPA3‑SAE + MPSK: déjà vu, but messier

WPA2‑PSK plus vendor‑specific “multiple PSK” (let's just go with MPSK for brevity and irony) was already fragmented: different names, different back‑end expectations, same general on‑air story. As WPA3‑SAE support for per‑identity PSKs gains relevance, the pattern is repeating, but this time the divergence is starting earlier and more visibly.

Some vendors already have production‑ready per‑identity PSK models built on SAE, while others are at various points in the beta/roadmap cycle or limiting support to narrow use cases. Each of those implementations risks making its own assumptions about how keys are selected, how identity is represented, and how AAA participates (or doesn’t) in the decision.

If that continues, the WPA3‑SAE + MPSK world will end up even more fragmented than WPA2‑PSK + MPSK. Without some intervention in the next 12–18 months, whether that is clearer 802.11 standards, well‑defined AAA profiles, or a Wi‑Fi Alliance feature, we are on track to lock in three to five incompatible WPA3‑SAE MPSK flavors that will be painful, or impossible, to reconcile later.

What “fixing it” would actually require

Fixing this does not require new cryptography; it requires admitting that per‑identity PSK is a first‑class workflow and then spreading that reality across the standards stack.

At a high level, that looks like:

In 802.11

  • Acknowledging that an authenticator can maintain multiple PSKs per SSID and select among them based on identity, not just one shared secret.
  • Potentially introducing a new AKM, or clarifying existing PSK/SAE AKMs, to explicitly describe this functionality instead of leaving it as “implementation detail.”

In AAA profiles

  • Defining a standard way to export the necessary context (nonces or equivalent handshake inputs, MAC addresses, SSID, identity hints) to an external policy engine. With the growing horsepower of access points, it could even exist semi‑locally as a lightweight policy engine at the edge.
  • Defining how that engine returns “this is the key for identity X” or “reject this association,” in a profile that independent AAA vendors can implement.

In Wi‑Fi Alliance programs (WPA3 and beyond)

  • Creating an optional (or mandatory) feature that says “this device supports per‑identity PSK,” with associated test cases for both WPA2‑PSK and WPA3‑SAE modes.
  • Possibly surfacing a capability indicator so controllers and AAA platforms can tell when they can rely on this behavior.

This is the same pattern that made things like Enhanced Open or OpenRoaming feel real: optional capabilities became normal once they had names, test plans, and certification logos attached. Per‑identity PSKs are stuck in the pre‑logo phase.

A quick note on EAP‑MPSK

EAP-MPSK is a bit of a cautionary tale. If you look outside pure 802.11, there has been at least one attempt to treat “multiple PSK” as a first‑class problem: EAP‑MPSK. EAP‑MPSK is (or was) an IETF EMU working‑group Internet‑Draft that defined an EAP method where the client and server share a set of PSKs and agree on which one to use during the EAP exchange. On paper, that gives you a standards‑based way to say “this identity has multiple candidate keys” without inventing a new handshake.

In practice, the draft has sat in “00” form since early 2024, has now expired, and never really evolved beyond a sketch. No updates, no adoption as a working‑group item with momentum, and no corresponding Wi‑Fi Alliance profile that would drive actual implementations. It is more of a signal that people recognize the multiple‑PSK use case than a usable building block today, and it underlines the main point of this post: per‑identity PSKs are solving real problems in production long before the standards world has figured out how to describe them end‑to‑end. I'm not advocating for reviving EAP-MPSK specifically, but rather for learning from its fate: incremental drafts without vendor commitment go nowhere.

One way to make this real would be a small, well‑defined RADIUS (or RADSEC, Diameter, etc) profile for per‑identity PSKs. For example, access points could send a standard RADIUS attribute bundle that includes "Who?" (MAC, SSID, optional identity hint) and “How?” (WPA2‑PSK vs WPA3‑SAE), and AAA servers could reply with a simple set of attributes such as an Identity-PSK-Selector (which key to use for the identity) and an Identity-Policy-Group (which VLAN and policy this identity belongs to). The exact names are not important here; the point is that everybody would be speaking the same small vocabulary instead of inventing yet another VSA file for each controller or vendor.

Why this matters for MDUs, hospitality, and OpenRoaming‑style worlds

In the OpenRoaming in MDUs context, there is already a tension between global identities (roaming, federated access) and local realities (units, rooms, leases, IoT devices that do not travel). Per‑identity PSKs live right at that intersection and give operators a way to align security, billing, and policy with how they actually think about their environments.

Standardizing this space would unlock practical advantages:

  • Cleaner MDU and hospitality workflows where property systems treat “Wi‑Fi access for Unit 201” or “Room 1203” as first‑class objects, with identity‑bound keys that follow leases and stays, not just devices.
  • A healthier AAA and SaaS ecosystem where identity providers integrate once against a well‑defined per‑identity PSK profile instead of re‑implementing every vendor’s private flavor of DPSK/PPSK/iPSK. Anyone who has worked with me knows that I am a huge proponent of development partner networks and how they lift each other up in functionality.
  • Hybrid identity models where roaming frameworks like OpenRoaming can federate a person into the building, then map that person to a local per‑identity PSK realm for in‑unit access, combining the best of identity‑based roaming with the operational simplicity of PSKs.

Per‑identity PSKs are already doing this work in the background. The real conundrum is that the standards still behave as if the only choices are "one PSK for everyone" or "go full 802.1X," while operators have been living in the space between those two extremes for years. The path forward requires coordination between IEEE 802.11, the Wi‑Fi Alliance, and the major infrastructure vendors, but the first step is admitting what is already deployed and depending on it. If you are building MDU or hospitality infrastructure, or AAA platforms that plug into them, start asking direct questions of your vendors (including me!) and using every feedback channel you have into standards and certification bodies to push per‑identity PSKs from “vendor trick” to “documented behavior.”

This topic is important to me. I welcome your feedback and corrections and I'm willing to work with you on making this standardization a reality. While I sometimes speak from a vendor pulpit, this topic is truly a non-biased one in the long-term. For a bit more on the history of multi-PSK and another argument for the identity-based thought process, see my post here: How Multi‑PSK Grew Up: A History of Per‑Device Keys in Wi‑Fi.

Alek (N4OG)

References