各廠商每裝置 PSK 比較：iPSK、DPSK、MPSK 與 PPSK（及 WPA3 支援）

Per-Device PSK by Vendor: iPSK, DPSK, MPSK and PPSK Compared, and WPA3 Support. A Purple Technical Briefing. Introduction and Context. Welcome to the Purple technical briefing series. I'm going to walk you through one of the most practically important - and frequently misunderstood - topics in enterprise WiFi right now: per-device pre-shared keys. Specifically, we're going to compare how each of the major vendors implements this capability, what they call it, how it actually works under the hood, and - critically - what happens when you try to move to WPA3. If you're an IT manager, network architect, or venue operations director running WiFi across a hotel estate, a retail chain, a stadium, or a public-sector campus, this briefing is for you. You've probably already encountered the alphabet soup: iPSK, DPSK, MPSK, PPSK. They all refer to the same concept - giving each device or user its own unique password on a single SSID - but the implementations differ significantly, and those differences matter when you're planning your next infrastructure refresh. Let's start with the fundamentals, then work through each vendor, and finish with the WPA3 question that everyone is wrestling with right now. Technical Deep-Dive. So what is per-device PSK, and why does it exist? Traditional WPA2-Personal uses a single shared passphrase for an entire SSID. Everyone on your guest network uses the same password. That creates two problems. First, you can't revoke access for one device without changing the password for everyone. Second, you have no per-device visibility or policy enforcement. Per-device PSK solves both. Each device or user gets a unique credential. You can revoke one without touching the others. You can assign different VLANs, bandwidth policies, or access schedules per key. It's the middle ground between the simplicity of WPA2-Personal and the complexity of full 802.1X enterprise authentication. Now let's look at how each vendor implements this. Cisco Meraki calls it iPSK - Identity Pre-Shared Key. Meraki supports two modes. Without RADIUS, you configure up to five unique PSKs directly in the Meraki dashboard, each mapped to a VLAN. It's quick to set up and requires no external infrastructure. With RADIUS - typically Cisco ISE - you can scale to thousands of keys. The client associates, the AP sends the MAC address and a PSK hint to the RADIUS server, the server returns the correct per-device key, and the standard WPA2 four-way handshake completes using that key as the Pairwise Master Key. The key insight here is that the RADIUS server is doing the lookup, not the AP. The AP just facilitates the exchange. HPE Aruba calls it MPSK - Multiple Pre-Shared Key. Aruba Central and Aruba Instant support MPSK in two modes: MPSK Local, where keys are stored on the controller or AP cluster, and MPSK with ClearPass, Aruba's RADIUS and policy engine. ClearPass can hold tens of thousands of keys, assign dynamic VLANs, and apply role-based policies per key. The authentication flow is essentially the same as Meraki's RADIUS mode - MAC-based lookup returns the per-device key before the four-way handshake. Ruckus - now part of CommScope - calls it DPSK, Dynamic Pre-Shared Key. This is arguably the most mature implementation in the market. Ruckus DPSK has been available since the early SmartZone days. In local mode, the DPSK service runs on the controller and holds the key database. In RADIUS mode, it integrates with Cloudpath, Ruckus's own network access control platform. What makes Ruckus notable is DPSK3 - their WPA3 extension of DPSK, which we'll come back to shortly. DPSK3 is available on Wi-Fi 6, 6E, and 7 access points running firmware 7.0 or later, and it operates in WPA2 slash WPA3 mixed mode. Juniper Mist calls it PPSK - Private Pre-Shared Key - or sometimes Multi-PSK. Mist stores keys in the cloud, in the Mist organisation or site key database, with a limit of 5,000 keys per site. Keys can be assigned per user, per device, or per group. Mist also integrates with its Access Assurance service - the cloud-native NAC - which adds RADIUS-based PSK lookup. Critically, Juniper has announced WPA3 RADIUS PSK support through Access Assurance, allowing a single WPA3-Personal SSID to serve multiple passphrases. This is one of the more forward-looking implementations in the market. Extreme Networks - which acquired Aerohive - calls it PPSK, Private Pre-Shared Key, through ExtremeCloud IQ. Extreme's implementation supports local key storage on the AP itself, which is useful for branch or remote sites with limited connectivity. It also supports RADIUS-based lookup via ExtremeCloud IQ's cloud RADIUS service. MAC binding is available, which ties a PPSK to a specific device MAC address for additional security. Fortinet calls it MPSK, Multiple Pre-Shared Key, managed through FortiAP and the FortiGate wireless controller. Fortinet's implementation is notable because it explicitly supports WPA3-SAE and WPA3-SAE Transition security modes in its MPSK profiles - as of FortiAP firmware 8.0. You can create an MPSK profile with WPA3-SAE keys, assign them to a VAP, and enable dynamic VLAN assignment per key. This is one of the cleaner WPA3 MPSK implementations available today. Ubiquiti UniFi calls it Private Pre-Shared Keys, or Private PSK. UniFi's implementation is local only - keys are stored in the UniFi Network controller, not in an external RADIUS server. You can assign different VLANs per key and set client limits per key. The significant limitation: as of mid-2026, UniFi Private PSK only works on WPA2 networks on 2.4 GHz and 5 GHz. WPA3 and 6 GHz are not supported. For smaller deployments this is fine, but it's a constraint worth knowing before you commit to a UniFi estate at scale. Now, the WPA3 question. This is where it gets technically interesting. WPA2-Personal uses a four-way handshake. The client and AP derive a Pairwise Transient Key from a shared Pairwise Master Key, which itself is derived from the passphrase. Because the PMK derivation happens after the RADIUS lookup, the AP can substitute a per-device key at that point. The standard doesn't care - it just sees a valid PMK. WPA3-Personal replaces the four-way handshake with SAE - Simultaneous Authentication of Equals. SAE is a Diffie-Hellman-based protocol. Both sides commit to a shared password element derived from the passphrase before the association completes. The critical difference: the password must be known to both sides before the SAE exchange begins. There's no point in the protocol where a RADIUS server can inject a different key per device. The AP and client are already doing a cryptographic dance with a single shared value. This is why WPA3 currently only allows one key per SSID in its standard form. It's not a firmware limitation. It's a protocol constraint. The workarounds fall into three categories. First, WPA3 transition mode - also called WPA2 slash WPA3 mixed mode. The SSID advertises both WPA2-PSK and WPA3-SAE. WPA2 clients use the four-way handshake and can receive per-device keys via RADIUS. WPA3 clients use SAE with a single shared password. This is the most widely deployed approach today and is supported by Cisco Meraki, HPE Aruba, Ruckus, and others. Second, proprietary extensions. Ruckus DPSK3 is the clearest example. By running in WPA2 slash WPA3 mixed mode with Cloudpath as the RADIUS backend, DPSK3 allows WPA3-capable devices to use SAE while the system manages per-device key binding through the Cloudpath integration. Juniper's Access Assurance WPA3 RADIUS PSK takes a similar approach. Fortinet's MPSK with WPA3-SAE Transition mode lets you mix WPA2-Personal and WPA3-SAE keys in the same MPSK profile. Third, moving to 802.1X. For managed endpoints - corporate laptops, staff devices, anything you can push a certificate to - WPA3-Enterprise with EAP-TLS is the clean answer. It's fully compatible with WPA3 and 6 GHz, provides per-device identity, and integrates with Microsoft Entra ID, Okta, and Google Workspace. The trade-off is deployment complexity and the need for a certificate infrastructure. Implementation Recommendations and Pitfalls. So what should you actually do? If you're running a hotel estate with a mix of guest devices, IoT sensors, and staff devices, the pragmatic answer in 2026 is a hybrid SSID design. Keep a WPA2-Personal SSID with per-device PSK for legacy IoT and guest devices. Run a WPA3-Enterprise SSID for staff devices you control. Use transition mode on your primary guest SSID to support both WPA2 and WPA3 clients without fragmenting your SSID count. If you're on Ruckus and running Wi-Fi 6 or newer hardware, DPSK3 in WPA2 slash WPA3 mixed mode with Cloudpath is worth evaluating. It gives you the closest thing to native WPA3 per-device PSK available today. If you're on Fortinet, the MPSK profile with WPA3-SAE Transition is straightforward to configure and gives you a clean migration path. If you're on UniFi, be explicit with your stakeholders that Private PSK is WPA2-only. For venues deploying Wi-Fi 6E or Wi-Fi 7 with 6 GHz radios, you'll need a different authentication strategy for that band. The biggest pitfall we see is teams assuming that enabling WPA3 on an existing per-device PSK SSID will just work. It won't. Test in a pilot site first. Check your AP firmware versions - DPSK3 requires firmware 7.0 or later on Ruckus, for example. And check your RADIUS server compatibility - Ruckus DPSK3 in mixed mode requires Cloudpath specifically, not a generic RADIUS server. A second pitfall is key sprawl. Per-device PSK is excellent for accountability, but only if you have a process to revoke keys when devices are decommissioned. Without lifecycle management, you end up with thousands of orphaned keys and no audit trail. Integrate your key provisioning with your device management workflow from day one. Rapid-Fire Questions and Answers. Can I use per-device PSK on a 6 GHz SSID? No. 6 GHz mandates WPA3-only, and WPA3 doesn't natively support per-device PSK. Use 802.1X or a separate 2.4 slash 5 GHz SSID for devices that need per-device PSK. Does per-device PSK satisfy PCI DSS requirements? Per-device PSK on WPA2 can satisfy PCI DSS 4.0 network segmentation requirements if each key maps to an isolated VLAN. But PCI DSS strongly recommends 802.1X for cardholder data environments. Check with your QSA. What's the maximum number of keys per SSID? It varies significantly. Cisco Meraki with ISE supports very large deployments. Ruckus DPSK supports tens of thousands of keys. Juniper Mist caps at 5,000 per site. UniFi is effectively limited by controller memory. Always check vendor documentation for your specific firmware version. How does Purple fit into this? Purple sits as a cloud overlay on top of your existing hardware. We integrate with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. For Guest WiFi and Staff WiFi deployments, Purple handles the identity layer - authentication, data capture, consent management - and passes the appropriate VLAN or policy assignment back to your hardware via RADIUS or API. You keep your existing per-device PSK infrastructure; Purple adds the identity and analytics layer on top. Summary and Next Steps. Let's pull this together. Per-device PSK - whether you call it iPSK, DPSK, MPSK, or PPSK - is a mature, well-supported capability across all major enterprise WiFi vendors. The implementations differ in where keys are stored, how they scale, and how they integrate with RADIUS. WPA3's SAE protocol creates a genuine technical constraint for per-device PSK. The standard doesn't support it natively. The practical answers today are transition mode, proprietary extensions like DPSK3, or moving to 802.1X for devices that support it. The vendor-by-vendor summary: Cisco Meraki iPSK works well with ISE in RADIUS mode; WPA3 support is via transition mode. HPE Aruba MPSK with ClearPass is highly scalable; WPA3 MPSK is in active development. Ruckus DPSK3 is the most mature WPA3 per-device PSK solution available. Juniper Mist Access Assurance adds WPA3 RADIUS PSK. Fortinet MPSK explicitly supports WPA3-SAE in its MPSK profiles. Extreme PPSK is solid for local and RADIUS modes. UniFi Private PSK is WPA2-only and local-only. For your next steps: audit your current per-device PSK deployment, identify which devices are WPA3-capable, and design a hybrid SSID strategy that serves both. If you're planning a hardware refresh, prioritise Wi-Fi 6 or Wi-Fi 7 APs with confirmed DPSK3 or WPA3 MPSK support. If you want to understand how Purple integrates with your specific hardware vendor to add identity management and analytics on top of your per-device PSK deployment, visit purple.ai or speak to your account team. That's it for this briefing. Thanks for listening.