How Multi‑PSK Grew Up: A History of Per‑Device Keys in Wi‑Fi

The multiple pre‑shared key methodology in Wi‑Fi networks is present in most modern vendor toolkits, but outside of certain verticals (MDU and hospitality, for instance) it remains strangely under‑appreciated. The idea is that every user, device, or identity has its own pre‑shared key or passphrase on a single WPA‑Personal SSID. It solves several problems and provides new opportunities, but it can also create operational and design challenges.

This topic fascinates me, and I have been following it for several years of my Wi‑Fi journey. I wanted to consolidate as much of what I have learned as possible into one place. Whether you are a network administrator, a new Wi‑Fi practitioner, or even a seasoned pro, the goal is to give you enough background to understand where multi‑PSK came from and how it can be useful in real wireless implementations.

From one shared secret to per‑device keys

WPA2‑Personal was designed around a single shared passphrase per SSID. That passphrase is turned into a 256‑bit Pre‑Shared Key (PSK) using a password‑based key derivation function called PBKDF2, with the SSID used as the salt. The 4‑way handshake then turns that PSK into the pairwise keys that actually encrypt unicast traffic: the Pairwise Master Key (PMK), which is turned into the Pairwise Transient Key (PTK), and several sub‑keys derived from the PTK. In this model, every client shares the same PSK, so anyone who knows it can derive the same PMK.

The security implications are significant. Anyone who knows the PSK and can capture another client's 4‑way handshake (which is not difficult with basic tools) can derive that client's PTK and decrypt its traffic. If you want to revoke a user or device's access to the network, you have to change the PSK for everyone, on every device.

Multi‑PSK is the natural answer to those problems. Instead of one PSK per SSID, treat the PSK as a per‑identity secret. You assign a unique passphrase to a client (or a small group) based on its identity, and the AP uses a different PMK for each, even though they all associate to the same SSID. The over‑the‑air protocol does not change: the 4‑way handshake is identical, but the key material underneath is no longer shared across the entire network.

There are important secondary benefits as well. Revoking access becomes much easier, because you can simply remove that user's or device's passphrase from the configuration without touching anyone else. Using a single SSID also allows RF optimizations that are difficult or impossible when you deploy multiple bespoke SSIDs per identity: you can maintain robust secondary and tertiary coverage across multiple access points, reduce beacon overhead and airtime consumption, and simplify operations by managing fewer SSIDs while still keeping per‑device separation and control.

hostapd: where multi‑PSK grew up

In the open‑source world, hostapd is the reference implementation of an 802.11 access point and 802.1X/WPA/WPA2/WPA3 authenticator on Linux. When Linux moved AP logic into user space with mac80211, hostapd became the standard that glues together the wireless driver, the 4‑way handshake, and RADIUS. A huge amount of Wi‑Fi on Linux, including OpenWrt, is built directly on top of hostapd.

The interesting part for multi‑PSK history is how early hostapd implemented it. In December 2004, hostapd 0.3.0 added support for multiple WPA PSKs. Instead of only letting you configure a single PSK for an SSID, it allowed a separate wpa_psk_file containing entries that bound PSKs to individual client MAC addresses. In modern terms, we would call these "bound" MAC addresses and PSKs because you must explicitly bind a MAC address to a PSK. The AP keeps a table that binds each unique MAC address to a PSK. When a client with a known MAC address starts the 4‑way handshake, the AP performs a lookup on that MAC address, retrieves that client's PSK, derives the PMK using the SSID as the salt, and accepts or rejects the handshake.

That's per‑station PSK in its most rudimentary form. You can give every device its own key, or reuse a key across multiple MAC addresses, all on the same SSID. hostapd became the laboratory where people experimented with these ideas long before the marketing names showed up.

It also set the baseline implementation strategy of multi‑PSKs not needing new RSN elements or a different handshake. You just change how the AP chooses the PSK for each MAC address. For anything built on Linux and hostapd, including a lot of open firmware and some commercial products, this is the underlying mechanism that later branding utilizes.

The vendor name soup: PPSK, DPSK, MPSK, iPSK…

Wi‑Fi vendors eventually realized they could take the same basic idea, make it friendlier for administrators, and differentiate their stacks. The result is the familiar alphabet soup:

Vendor / ecosystem	Name	What it really is
Aerohive / Extreme	PPSK	Per‑user or per‑device PSKs, centrally managed
RUCKUS	DPSK	Per‑device PSKs, often issued dynamically
Aruba	MPSK	Multiple PSKs per SSID with group/role mapping
Cisco	iPSK	Per‑user/device PSKs via RADIUS (ISE) with policy
Linux / OpenWrt ecosystem	multi‑PSK	hostapd multi‑PSK, often exposed in controllers

Under the hood, the patterns are very similar:

Static mapping
A table of {MAC, PSK} lives somewhere the AP can reach.
RADIUS‑assisted mapping
The AP or controller uses the client's MAC address (and sometimes other hints) in a RADIUS Access‑Request. The RADIUS server replies with an Access‑Accept that includes attributes carrying the PSK or passphrase to use for that client, and optionally policy such as VLAN or role.
Policy binding
Once the AP or controller knows "this client used PSK X," it maps that identity to a VLAN, role, ACL set, or QoS profile.

For newcomers, the key idea is that all of these features turn "what passphrase did you use?" into part of the identity and policy selection. Multi‑PSK is not just about avoiding rekeying everyone when the intern leaves; it is about being able to say "devices with this PSK go into IoT‑restricted, devices with that PSK go into Staff, even though they all associate to Corp‑WiFi."

Bound vs Unbound

At this point, many implementations had already been built around what can now be called bound multi‑PSK. In a bound model, the authentication backend must know the client's MAC address before it is allowed to authenticate: each PSK is explicitly associated with one MAC address (or a small set of MACs), and the AP or controller looks up the PSK based on that MAC when the device attempts to join.

The contrasting approach is the unbound multi‑PSK mechanism. With unbound multi‑PSK, you do not need to know the MAC address beforehand. The authenticator (AP or controller) keeps a list of pre‑calculated PMKs for an SSID, each derived from a different passphrase for that SSID. When a device authenticates, the AP or controller uses information from the 4‑way handshake (for example, whether the MIC verifies with a given candidate PMK) to determine which PMK matches the client by searching a lookup table or database. Once the correct PMK is found, the AP or controller completes the handshake, derives the PTK for that client, and applies the appropriate policy entry from the same table.

This unbound model is also the base methodology used in many RADIUS‑backed services and products that provide multi‑PSK support. The heavy lifting of calculating PMKs is done ahead of time, so at runtime the system only performs fast lookups and a small number of MIC checks. That makes it practical to scale to thousands of PSKs on a single SSID, and in some designs well beyond that.

The administrative implications here mean that self‑service onboarding can be completely automated. PSKs can be dynamically assigned up front with their corresponding policies, and the first time a device authenticates, it is moved from unbound to bound. This describes the modern method of deployment for many vendors working in the MDU and Hospitality spaces.

RUCKUS, DPSK, and the patent angle

RUCKUS went beyond implementation and invested in patenting some of the flows around per‑device keys. Patents such as US 7,669,232 ("Dynamic authentication in secured wireless networks") and US 8,756,668 / 9,226,146 ("Dynamic PSK for hotspots") describe systems where each authenticated user or device gets a unique secret that is then used to derive its wireless security keys. You can search for these patent numbers on the USPTO's site here.

One of the "Dynamic PSK for hotspots" patents lays out the pattern: a user connects to an open network and hits a captive portal. The system then generates a random key for that device, associates it with a device identifier (typically the MAC), and stores it. The user is instructed to use that key on a secured SSID. When the device connects with that PSK, the AP or controller looks up the stored mapping to authenticate the device and place it into the right policy context. This is the basis for DPSK self‑service onboarding that is still used often today.

The "dynamic" in DPSK describes this lifecycle. Keys are generated on demand, bound to devices, can be revoked independently, and don't require everyone to rekey when one entry is removed. The patents cover those specific workflows and data structures, not the general notion that different clients might have different PSKs on the same SSID. That's why other vendors still offer PPSK/iPSK/MPSK: they solve the same problem, but with their own controller logic, RADIUS attributes, and key management pipelines.

Identity‑based PSK: putting a name to the pattern

Academic work eventually gave this whole ecosystem a more formal name. A 2021 thesis on identity‑based PSK (iPSK) in WPA2 and WPA3 networks takes the practical deployments that vendors and hostapd had already built and frames them as an explicit protocol design. It starts from the same critique you have seen throughout this post: in WPA2‑PSK, every client shares the same PSK, so once a user knows it, they can derive the PMK and decrypt traffic from any other client whose handshake they capture.

The "identity‑based PSK" proposal keeps the on‑air handshake exactly the same but changes how PSKs are generated. Instead of manually assigning a PSK per device or keeping a giant table, the AP or controller holds a single master secret and derives a unique PSK for each client from that master secret plus the client's MAC address using a key‑derivation function. From the station's point of view, nothing changes: it still runs a normal WPA2/WPA3‑Personal 4‑way handshake, and each device effectively ends up with its own PSK and PMK without the backend having to store thousands of individual keys.

The thesis also points out an important naming mismatch: vendor "iPSK" implementations (Cisco's in particular) are really identity‑based passphrases managed out of band. The controller or RADIUS server picks a passphrase per device or user, but the supplicant still converts that passphrase into a PSK with PBKDF2 just like any other WPA‑Personal network. It is a very practical extension and works well in the field, but it still lives in the same unstandardized space as other multi‑PSK schemes rather than being a true, interoperable identity‑based PSK protocol.

Why multi‑PSK is still not a first‑class citizen

Given the history, it is fair to say multi‑PSK lives in an awkward middle ground.

The cryptographic building blocks have existed since WPA2‑Personal shipped, and open‑source hostapd has supported multiple PSKs per SSID for roughly two decades.
Vendors have wrapped the concept in per‑device onboarding, RADIUS integrations, and patents around dynamic key management and per‑device secrets.
Academic work has argued for identity‑based PSK as a clean generalization of "WPA2‑PSK but with per‑client secrets," without changing the over‑the‑air handshake.

What never happened is a standards‑level blessing. There is no 802.11 amendment or Wi‑Fi Alliance certification that says "this is how a station indicates which PSK identity it used," or "this is how an AP should talk to AAA to obtain per‑station PSKs." Instead, each vendor defined its own RADIUS attributes and controller logic, and hostapd added its own configuration knobs, all in parallel.

If you want to go deeper into the standardization side of this story, including more detail on WPA2 vs WPA3 and the challenges of that transition, see my earlier post: Per‑Identity PSKs: The Feature Wi‑Fi Forgot to Standardize.

The irony is that multi‑PSK is probably one of, if not the, most practically impactful "non‑standard" Wi‑Fi features in widespread use today. It is how a lot of environments get most of the benefits of identity and per‑device control without going full 802.1X on every toaster, barcode scanner, and fish‑tank thermometer. And, thanks to hostapd, it has been sitting there in the open the whole time, quietly doing the job the standard never officially took on.

Alek (N4OG)