If your network currently uses Identity Pre-Shared Keys (iPSKs) also known as multiple PSKs per SSID, you’ll need to plan carefully before jumping to WPA3 or enabling 6 GHz for Wi-Fi 7.
While iPSK has been a brilliant way to provide simple, secure access control without the complexity of 802.1X, it doesn’t play nicely (yet) with the new security requirements introduced by WPA3.
This isn’t just a Cisco Meraki issue, it’s an industry-wide limitation that affects most vendors as Wi-Fi standards evolve.
Let’s unpack what’s going on, why it matters, and what you can do about it.
⚙️ What is iPSK?
Identity Pre-Shared Key allows you to use multiple unique pre-shared keys on a single SSID.
It’s been hugely popular for networks that need:
-
Easy onboarding without RADIUS or certificates
-
Segmentation between users or devices
-
Simple, scalable credential management
Each device or group of devices gets its own key, mapped to a specific VLAN, policy, or group. It’s been a great middle ground between open PSKs and full enterprise authentication.
🚧 The Setback: iPSK and WPA3 Don’t Get Along (Yet)
The move to WPA3 introduces Simultaneous Authentication of Equals (SAE), a more secure handshake than WPA2-PSK.
However, SAE isn’t currently designed to support multiple pre-shared keys per SSID the way WPA2 could.
That means if you’re using iPSK today, whether on Meraki, Aruba, Mist, Ruckus, or others - you’ll hit the same roadblock:
WPA3 currently only allows one key per SSID.
This becomes especially important in 6 GHz, where WPA3 is mandatory. You can’t run WPA2 or mixed-mode PSK at all in the new band.
📉 Why This Matters
-
Loss of segmentation – If you’ve built policies or VLAN assignments around individual PSKs, those won’t carry over directly in WPA3/6 GHz.
-
Onboarding friction – IPSK made device onboarding easy for non-802.1X devices - that simplicity is lost without workarounds.
-
Mixed client environments – Supporting both WPA2 (legacy 2.4/5 GHz) and WPA3 (6 GHz) complicates SSID design.
In short, you can’t just “turn on WPA3” and expect your iPSK environment to keep working.
🧠 Why It’s Not a Meraki Problem
It’s tempting to assume this is a Cisco Meraki limitation, but it’s not.
All major vendors face the same issue because this stems from how WPA3 is defined in the IEEE 802.11 standard.
-
Aruba: MPSK works only under WPA2; WPA3 support is still in development.
-
Mist/Juniper: PPSK (their version of iPSK) has similar WPA3 constraints.
-
Ruckus, Extreme, Ubiquiti: Same story single PSK only under WPA3.
This is one of those rare cases where everyone is waiting on standard evolution, not just firmware updates.
🧩 Potential Workarounds and Options
Until iPSK or similar functionality is natively supported under WPA3, here are your best options:
1️⃣ Split SSIDs by Function or Device Type
Instead of one SSID with many keys, create multiple SSIDs for different device groups.
-
Pros: Simple and standards-compliant.
-
Cons: Adds management overhead and potential channel contention.
-
Wouldn’t recommend to exceed more than 7 SSIDs on same frequency band
-
Having a higher MBR will help with this, 24 Mbps would be our recommendation here.
2️⃣ Use 802.1X (RADIUS) for Enterprise Devices
For corporate or managed endpoints, migrating to WPA2/WPA3-Enterprise provides stronger security and native compatibility with zero-trust models.
-
Integrates with Azure AD, Okta, or on-prem AD.
-
Works perfectly with WPA3 and 6 GHz.
-
Meraki’s Access Manager will soon simplify this without needing a full RADIUS stack.
3️⃣ Keep IPSK on WPA2 for 2.4/5 GHz
You can maintain existing IPSK SSIDs for legacy devices on WPA2 while creating new WPA3-only SSIDs for 6 GHz.
-
A pragmatic hybrid design during transition periods.
-
Ensures compatibility while preparing for the future.
4️⃣ Identity-Based Access via Meraki Access Manager (Future)
Meraki’s new Access Manager (currently in early access) offers a cloud-native alternative to RADIUS.
It enables identity-based policies directly from the dashboard using:
-
Certificate-based auth (EAP-TLS)
-
iPSK + context-aware rules
-
Security Group Tags (SGT) and VLAN assignments
As Access Manager matures, it will provide a more scalable way to deliver the per-device control of iPSK but with WPA3 and zero-trust compliance baked in.
🧭 What to Consider Before Upgrading
Before enabling WPA3 or rolling out Wi-Fi 7 (6 GHz), review these key points:
|
Consideration |
Recommendation |
|
Using iPSK heavily today |
Keep WPA2 SSIDs until iPSK support evolves |
|
Deploying Wi-Fi 7 / 6 GHz |
Use WPA3-Enterprise for managed devices |
|
IoT / headless devices |
Plan for MAB, iPSK, or VLAN isolation |
|
Zero-trust alignment |
Explore Meraki Access Manager or 802.1X |
|
Migration timing |
Test in pilot sites before network-wide changes |
✅ Final Thoughts
Identity Pre-Shared Key (iPSK) has been one of the best features in the Meraki ecosystem, balancing simplicity with segmentation.
But with WPA3 and 6 GHz, the landscape is changing.
Until IPSK evolves to work with SAE, the best strategy is a hybrid approach:
-
Keep IPSK for legacy bands and devices,
-
Use WPA3-Enterprise for 6 GHz and Wi-Fi 7 clients,
-
Prepare for the future with Meraki Access Manager for identity-based, cloud-native access control.
📦 Need help planning your WPA3 or Wi-Fi 7 migration?
Contact The Networking Nerds we’ll help you design a strategy that balances security, simplicity, and scalability.