Meraki iPSK vs Aruba MPSK: Per-Device WiFi Keys Compared

Meraki iPSK and Aruba MPSK do the same job. Both give each device its own WiFi key on a single SSID. iPSK (Identity Pre-Shared Key) is Cisco Meraki’s version. MPSK (Multi Pre-Shared Key) is Aruba’s. Each has a local mode with no server, and a server mode that looks up the key by MAC address. The catch is simple. Each one is vendor-locked. And MAC-based lookup struggles with modern MAC randomization. A vendor-neutral, MAC-address-less PPSK solves both.
IN THIS ARTICLE
What is Meraki iPSK?
iPSK stands for Identity Pre-Shared Key. It is Cisco Meraki’s way to give each device its own key on one SSID. Each key maps to a Meraki group policy. That policy sets the VLAN, the access rules, and the bandwidth.
Meraki iPSK runs in two ways.
- iPSK without RADIUS. You create the keys in the Meraki dashboard. No server needed. This supports up to 50 keys per SSID on MR 27–29 firmware, and up to 5,000 on MR 30.1 and newer.
- iPSK with RADIUS. A RADIUS server (often Cisco ISE) returns the key based on the device’s MAC address. This adds profiling and identity groups, but requires MAC-based provisioning.
iPSK uses WPA2 (PSK-AES) encryption. It is a common fix for IoT devices that cannot run 802.1X. PPSK is the generic name for this approach — see our PPSK explainer.
What is Aruba MPSK?
MPSK stands for Multi Pre-Shared Key. It is Aruba’s version of the same idea. Each device gets its own key on a shared SSID. Each key maps to an Aruba role.
MPSK also runs in two ways.
- MPSK Local. You configure the keys locally, with no ClearPass or RADIUS. MPSK Local supports up to 24 keys per SSID. It works with WPA2-PSK-AES.
- MPSK with ClearPass. ClearPass performs a MAC authentication lookup and returns the device’s key and role. This scales further, but relies on the device’s MAC address.
The concept matches iPSK exactly. Only the product names and limits differ. For the definition, see our Multi-PSK glossary entry.
Meraki iPSK vs Aruba MPSK: the side-by-side comparison
Both solve the same problem. The differences are in scale, naming, and how each ties to its vendor.
| Criterion | Meraki iPSK | Aruba MPSK |
|---|---|---|
| Vendor | Cisco Meraki | Aruba (HPE) |
| Local mode (no server) | Yes | Yes (MPSK Local) |
| Keys per SSID, local | 50 (MR 27–29); 5,000 (MR 30.1+) | Up to 24 |
| Server mode | iPSK with RADIUS (e.g., Cisco ISE) | MPSK with ClearPass |
| Server-mode identifier | MAC address | MAC address |
| Policy mapping | Meraki group policy | Aruba role |
| Encryption | WPA2 (PSK-AES) | WPA2 (PSK-AES) |
| Works across vendors | No — Meraki only | No — Aruba only |
| MAC randomization | A problem (MAC-based lookup) | A problem (MAC-based lookup) |
| 6 GHz / WiFi 7 (WPA3-SAE) | Not supported (PSK-based) | Not supported (PSK-based) |
The pattern is clear. Same concept, two ecosystems, both tied to MAC-based identity in server mode.
What do iPSK and MPSK have in common?
More unites them than divides them. Both:
- Give each device a unique key on one SSID.
- Map each key to a policy or role (VLAN, access, bandwidth).
- Offer a local mode for small deployments and a server mode for scale.
- Use MAC-based lookup in server mode.
- Run on WPA2 (PSK-AES), so they live on the 2.4 and 5 GHz bands.
- Serve the same core need: per-device access without 802.1X.
If you understand one, you understand the other. The hard part is not the concept. It is running it at scale, across devices and vendors.
What are the limits of iPSK and MPSK?
Both work well inside their own ecosystem. Three limits show up at scale.
- Vendor lock-in. iPSK is Meraki-only. MPSK is Aruba-only. If your property portfolio mixes vendors, you run and maintain two separate systems with two sets of rules.
- MAC-based identity. In server mode, both look up the key by MAC address. Modern phones and laptops randomize their MAC for privacy. That breaks MAC-bound keys and forces re-registration.
- Local-mode caps. The no-server modes are capped — 24 keys for Aruba MPSK Local, 50 for Meraki iPSK on older firmware. Past that, you need ISE or ClearPass, which is a project of its own.
For a single-vendor site, these are manageable. For a multi-site, multi-vendor property portfolio, they add real operational cost.
How do you run per-device keys across both Meraki and Aruba?
This is where a vendor-neutral platform changes the math. Cloud4Wi delivers MAC-address-less PPSK across access-point vendors — including Meraki and Aruba — from one place.
Two things matter here.
- One system, every vendor. You manage the same per-device keys across Meraki, Aruba, Ruckus, and more. No separate iPSK and MPSK configs to keep in sync.
- No MAC registration. The key identifies the device — not its MAC. So MAC randomization is not a problem, and there is no MAC list to maintain.
For property teams, this unlocks the resident experience. Each resident gets one key. That key becomes their private network — a Personal Area Network (PAN) — across the whole property. Move-in provisions the key. Move-out revokes it instantly. This is the core of the MDU WiFi solution, powered by the PPSK feature and delivered on the Cloud NAC platform. PPSK works with or without RADIUS, so you are not forced into an ISE or ClearPass project to scale.
Which should you choose?
If your whole estate is one vendor, the native tool is fine. Choose Meraki iPSK on an all-Meraki network. Choose Aruba MPSK on an all-Aruba network. Both do the job inside their ecosystem.
Choose a vendor-neutral PPSK when:
- Your portfolio mixes access-point vendors.
- You manage housing, student accommodation, or multi-tenant buildings.
- You want per-resident keys with automatic move-in and move-out.
- You want to avoid MAC registration and MAC-randomization headaches.
Most property portfolios are mixed and growing. That is exactly where one MAC-address-less PPSK layer beats two vendor tools. Start by mapping which vendors each site runs. Then decide whether you want to maintain two systems — or one.
Frequently asked questions




