The iPSK Challenge: What to Know Before Upgrading to WPA3, 6 GHz, or Wi-Fi 7

The iPSK Challenge: What to Know Before Upgrading to WPA3, 6 GHz, or Wi-Fi 7

Oct 29, 2025Liam Francis

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.

More articles