Skip to main content
English (UK)

How to deploy iPSK on Cisco Meraki, HPE Aruba and Ruckus

This hands-on reference guide shows how to deploy iPSK on Cisco Meraki, MPSK on HPE Aruba Central and DPSK on Ruckus SmartZone, with a short UniFi PPSK appendix. It focuses on key issuance, VLAN or policy placement, RADIUS decision flows and revocation tests that prove a deployment works in a live venue.

By Marketing TeamPublished Updated
📖 13 min read2,812 words2 worked examples10 key definitions

Video overview

Listen to this guide

View podcast transcript
Welcome to the deployment briefing on iPSK for Cisco Meraki, HPE Aruba and Ruckus. The operational problem is familiar. You have more device types than you want SSIDs. Hotel room devices, resident devices, building systems, contractor equipment and temporary event technology need different access decisions. A shared password does not give you a clean offboarding path. A separate SSID for every cohort adds radio overhead and makes the service harder to operate. Identity pre-shared key deployments address that gap. The shared SSID stays the same, but each device or group receives a different key. The key can lead to a different VLAN, policy or role. The names differ by vendor. Cisco Meraki uses iPSK with RADIUS. HPE Aruba uses MPSK. Ruckus uses DPSK. UniFi calls its local option Private Pre-Shared Keys, or PPSK. The operating principle is the same: you replace one shared secret with an access decision that you can issue, inspect and revoke. Start with the wired design. Build the VLANs that you really need and make sure each AP uplink carries them. Do not begin by creating keys in a dashboard. Agree the access outcomes first. In a multi-tenant building, that might be resident, building operations, room device and test. In a hotel, it could be room device, back-office and contractor. In a stadium, it could be production, event operations and temporary device. The names are less important than the fact each one has a clear owner and a defined purpose. Then decide how granular the key must be. A device-specific key is easier to revoke and investigate. A group key is easier to distribute, but a leak affects every device that shares it. This distinction matters most during offboarding. If a contractor leaves with a group key, you may need to rotate an entire cohort. If the contractor has a personal key, you can remove one record and preserve everyone else’s access. Cisco Meraki gives you a RADIUS-backed iPSK route. In Dashboard, go to Wireless, Configure, Access control. Choose your SSID and select Identity PSK with RADIUS. Set direct access rather than a splash page, then configure the RADIUS server. This is the point where you need clear ownership. The access point is the RADIUS client. Your authentication platform is the decision point. Keep the RADIUS shared secret in your approved secrets store. Do not leave it in a deployment spreadsheet. Meraki documents a MAC-based model and an Easy PSK model. In the MAC-based model, the RADIUS record associates a device MAC address with the key. In the Easy PSK model, the AP forwards specific handshake material to RADIUS. The RADIUS server finds a matching known key and sends an Access-Accept containing the key information Meraki expects. The AP restarts the handshake and completes the connection. Where segmentation matters, run the Meraki SSID in bridge mode. Give it a default VLAN. Then enable the documented RADIUS override so the successful response can replace that default tag. You may also apply a Dashboard group policy for firewall or traffic controls. The test is not complete until the device has the intended address range and the expected policy. A RADIUS accept is necessary. It is not the finished outcome. There are two hard gates in the cited Meraki workflow. The documented iPSK with RADIUS capability does not support WPA3. It also does not work when the SSID tunnels traffic to an MX Concentrator. Treat those as decisions made before the pilot, not as a ticket discovered after launch. HPE Aruba approaches the same goal through MPSK and ClearPass. In Aruba Central, open Manage, Devices, Access Points, Config, then WLANs. Add or edit the SSID, open Security, select Personal, choose MPSK-AES and select ClearPass Policy Manager as the primary server. The workflow explains why ClearPass matters. A device registers and receives a device-specific or group-specific passphrase. It joins using WPA2-PSK-AES. The AP performs the documented MAC authentication exchange with ClearPass. ClearPass returns an Access-Accept with authorisation information and an Aruba MPSK passphrase attribute. The AP generates the key and completes the four-way handshake. If the passphrase is wrong, or ClearPass rejects the device, the join fails. Do not manually add MAC authentication to an MPSK WLAN just because the process uses a MAC lookup. Aruba explicitly treats MPSK and manual MAC authentication as mutually exclusive. It also identifies denylisting and the internal RADIUS server as incompatible combinations. Capture those constraints in the change record before you touch a live profile. One Aruba point deserves extra attention: caching. Aruba documents that an AP caches MPSK information for roaming. A cached record can mean the AP does not perform a new MAC authentication lookup. That is useful for roaming. It is also why a quick retry is not proof of revocation. We will return to the test plan in a moment. So far, the practical pattern is clear. Build the network segments. Set the shared SSID. Configure the vendor’s key lookup path. Associate each key with a definite policy outcome. Then prove that the decision changes when the key disappears. That last part is where many otherwise sound pilots fail. Now, let’s look at Ruckus, the RADIUS and VLAN mapping concept, and the revocation test that makes an iPSK deployment operationally credible. On Ruckus SmartZone, you first confirm that the WLAN is DPSK-enabled. Then open Security, Access Control, Dynamic PSK and choose Generate DPSKs. Select the WLAN, choose the number of keys, enter or generate the username and passphrase, select the user role, set the VLAN ID and decide whether the key is a group DPSK. Ruckus makes the key type visible in the operating model. An unbound DPSK becomes bound when a device first uses it. A group DPSK remains shareable. A bound key can be imported with a MAC address. Use unbound keys for controlled handover. Use group keys only where shared use is intentional and the owner accepts the rotation consequence. Use bound records where a trusted device inventory already exists. The policy decision can sit in the role or in the selected VLAN. Ruckus documents that a user role carries attributes and permissions including VLAN, UTP and time restrictions. It also lets you select a VLAN during key generation. Whichever design you choose, map it back to the switch and gateway configuration. A correct key record cannot overcome a missing VLAN on an AP uplink. For the vendor-neutral view, RADIUS carries an authentication and authorisation result. It does not force every controller to interpret it in the same way. In Cisco Meraki, RADIUS can provide the key information and override the SSID’s default VLAN tag. In Aruba, ClearPass returns the MPSK passphrase and authorisation information. In Ruckus DPSK, SmartZone can use its own DPSK record, user role and VLAN choice. RFC 4675 describes RADIUS attributes for dynamic VLAN assignment in IEEE 802 networks and recognises that a WiFi device can be handled as a virtual port. That means your test evidence must cross four layers. First, the device used the intended SSID and key. Second, the access point or controller accepted the key. Third, the policy service returned the expected authorisation. Fourth, the device landed in the intended VLAN or policy and could reach only the services allowed there. If you stop at the controller event, you have not proved segmentation. The revocation test is your most important acceptance test. Start with a positive control. Connect a test device with an issued key. Capture the RADIUS or ClearPass acceptance where relevant, the controller client record and the observed VLAN or policy. Then revoke the key at the true source of control. Remove or deny the Meraki RADIUS mapping. Remove the ClearPass registration or authorisation that supplies the Aruba decision. Delete the Ruckus DPSK. In UniFi PPSK, remove the password-to-VLAN mapping using the current UniFi configuration guidance. Then force a fresh association. Forget the SSID, or disable and re-enable WiFi, and retry with the old key. The pass condition is a denied fresh join and a log entry that tells you why. Do not use the absence of a key in a dashboard as the result. You are testing whether the network rejects access, not whether an administrator completed a deletion form. For Aruba, include cache behaviour in the test design. A cached MPSK may avoid a new lookup. Define the cache-handling or expiry step in your production procedure and only then run the fresh association test. For every platform, repeat the join with an unaffected key on the same SSID. It should still work. This catches a broken WLAN profile, an over-broad RADIUS change or a missing VLAN on the wired path. A short rollout sequence works well. Begin with two policy outcomes and a handful of representative devices. One should be an easy device such as a managed tablet. One should be a difficult device such as an older room controller or IoT unit. Test issuance, allowed access, wrong-key denial, revocation and unaffected-key continuity. Write down the device identifier, key owner, policy name, time of issue and evidence location. Only then move to a larger cohort. For venue operations, keep the support procedure brief. The first-line team needs the SSID name, a device identifier, the issued-key owner, the time of failure and instructions not to reissue a key before the controller event is captured. Network engineering needs ownership of RADIUS, ClearPass, SmartZone role mapping and wired VLAN transport. That division avoids a familiar waste of time: replacing a key when the actual fault is an AP trunk or a misapplied role. A final word on scope. iPSK can support segmentation and access control, but it does not make a network automatically compliant with GDPR or PCI DSS. GDPR requires appropriate technical and organisational security measures. PCI DSS provides requirements for protecting payment account data. Treat the iPSK deployment as one input to the wider security and data-handling design, not as a compliance certificate. The next step is practical. Choose one production-like site, two policy outcomes and one test device for each. Build the decision path, capture the evidence and run the revocation test before you issue more than a few keys. If that test works, you have the foundations for a Multi-Tenant WiFi service that is easier to operate, easier to revoke and clearer to support.

Part of our core series: Multi-Tenant WiFi Guide →

How to deploy iPSK on Cisco Meraki, HPE Aruba and Ruckus

Cisco Meraki, HPE Aruba, and Ruckus each allow you to place different devices or groups on different policies without creating a separate SSID for each group. Configure a WPA2 Personal SSID, create or obtain a personal key, associate it with a VLAN or role, and then prove that deletion blocks new associations. 1 2 3

What does an iPSK deployment actually do?

An Identity Pre-Shared Key, or iPSK, provides a unique password to a device or group while maintaining a shared SSID. Vendors use different names for this. Cisco Meraki calls its RADIUS-backed option iPSK. HPE Aruba calls this Multi Pre-Shared Key, or MPSK. Ruckus calls this Dynamic PSK, or DPSK. Ubiquiti UniFi calls its local option Private Pre-Shared Key, or PPSK.

The practical result of this is controlled access on a single personal WiFi network. You can segregate a room device, resident device, or operational device without broadcasting a separate SSID for each use case. The control point varies by platform. Cisco Meraki can obtain key and VLAN overrides through RADIUS. HPE Aruba retrieves encrypted passphrases and authorisation information from ClearPass. Ruckus can place a DPSK directly into a user role or VLAN. UniFi PPSK maps passwords to VLANs locally. 1 2 3 4

This is not an alternative to 802.1X. IEEE 802.1X provides port-based network access control, whereas iPSK is suitable for devices that require a shared SSID and personal-key access. 5

Platform Credential Control Plane Supported Policy or VLAN Association via Stated Workflow Key Design Constraint
Cisco Meraki External RADIUS Bridge-mode SSID with RADIUS VLAN override, plus Dashboard Group Policy iPSK with RADIUS does not support WPA3, and it cannot operate on an SSID tunnelled to an MX Concentrator. 1
HPE Aruba ClearPass Policy Manager ClearPass Access-Accept includes authorisation information and Aruba MPSK passphrase attribute MPSK uses WPA2-PSK-AES and is mutually exclusive with manual MAC authentication. 2
Ruckus SmartZone SmartZone Dynamic PSK Store User role and VLAN ID selected during DPSK creation Operational ownership of bound, unbound, and group keys varies. 3
Ubiquiti UniFi UniFi Network Configuration One PPSK password for each configured VLAN PPSK is WPA2 only and does not work on the 6 GHz band. 4

What do you need before you begin?

Start with a forwarding design rather than the dashboard. Create target VLANs and ensure that any VLAN that can return an SSID is active on each AP uplink. Choose policy outcomes that operators can explain, such as resident, building operations, room device, and test. Decide whether keys will be per-device or by controlled group. Per-device keys allow precise revocation, while group keys reduce troubleshooting effort but increase the impact of a leak. 3 For a RADIUS-backed design, register the access points or their management subnet as RADIUS clients. Use the same shared secret on the access points and the RADIUS server. Cisco Meraki documents this relationship in its RADIUS server configuration. Keep the secret code in your approved secrets store and set a designated owner for each key population. 1

Record the SSID, policy outcome, key source, test device MAC address, and revocation result where applicable. MAC randomisation can complicate MAC-bound workflows, which is cited by Cisco Meraki as a reason for Easy PSK. 1

How do you configure Cisco Meraki iPSK with RADIUS?

Use Cisco Meraki iPSK with RADIUS when you require centralised control. In the dashboard, open Wireless > Configure > Access control, select the target SSID, and choose Identity PSK with RADIUS. Set the splash page to None (Direct access), then add the RADIUS server details. Cisco Meraki's guide includes current screens and examples. 1

For MAC-based workflows, your RADIUS record binds the client MAC address and PSK via Tunnel-Password. In Easy PSK, the AP provides Meraki vendor-specific handshake attributes; RADIUS finds the iPSK and sends an Access-Accept, after which the AP restarts the key handshake. 1

Configure bridge mode where you require per-device VLAN placement. Set the default SSID VLAN under Client IP and VLAN, then enable the documented RADIUS override so that an Access-Accept can replace that default VLAN tag. If you also require firewall, traffic-shaping, or other dashboard policies, create a matching dashboard group policy under Network-wide > Configure > Group Policies. Cisco Meraki's validation sequence is to connect a test device, check the RADIUS live logs, and inspect the client in the dashboard. 1

Cisco Meraki does not support this iPSK with RADIUS capability on WPA3 or on SSIDs tunnelled to an MX Concentrator. Confirm both before starting a pilot project. 1

How do you configure HPE Aruba MPSK in Aruba Central?

Use HPE Aruba MPSK with ClearPass when you require ClearPass to issue device-specific or group-specific passphrases and authorisation decisions. The documented path in Aruba Central is Manage > Devices > Access Points > Config > WLANs. Add an SSID or edit an existing SSID, open Security, select Personal, select MPSK-AES under key management, select ClearPass Policy Manager as the primary server, and save. 2

The documented flow is straightforward. A device registers and receives a passphrase. It connects with WPA2-PSK-AES. The AP performs MAC authentication against ClearPass. ClearPass returns an Access-Accept with authorisation information and the Aruba-MPSK-Passphrase vendor-specific attribute. The AP generates the PSK and completes the four-way key exchange. An incorrect passphrase or Access-Reject prevents connection. 2 Do not manually enable MAC authentication on the WLAN just because the flow includes a MAC lookup. Aruba states that MPSK and manual MAC authentication are mutually exclusive. It also notes that MPSK is mutually exclusive with denylisting and internal RADIUS servers. Consider those restrictions as design review checkpoints before changing production profiles. 2

Plan revocation based on cache. Aruba's documentation states that the AP stores the MPSK passphrase in a local cache for roaming and can bypass MAC authentication when it finds a matching entry. Therefore, simply deleting a registration or changing a policy is not sufficient proof. Your acceptance test must include a new association after the cached state has stopped allowing the old credential. Use current Aruba and ClearPass operating documents to define cache-clearing or expiry processes for your release. 2

How do you generate Ruckus DPSK keys on SmartZone?

Use Ruckus DPSK when SmartZone is your operational control point and you want the controller to generate and revoke keys. First, ensure the WLAN is DPSK-enabled. Then go to Security > Access Control > Dynamic PSK and select Generate DPSKs. Select the WLAN, choose the number of keys, then enter or generate a username and passphrase. Select a user role, set the VLAN ID, and choose whether the key is a group DPSK. 3

Choose the DPSK type carefully. An unbound key is bound at first use, a group key can serve multiple devices, and a bound key can be imported by MAC address using a CSV. 3

Ruckus links the selected user role to the role's attributes and permissions, which include VLAN, UTP, and time restrictions. You can also set the VLAN ID during key creation. This allows you to use a consistent SSID while keeping the access control decision tied to the DPSK record or its role. 3

For revocation, select the DPSK in the Dynamic PSK list and use Delete. Test deletion with the same device used to issue the key. Forget the SSID or disconnect it, then attempt a new connection using the removed key. Record a denied join as a pass condition. Do not declare success based solely on the key's absence from the controller list. 3

How does RADIUS map a key to a VLAN or policy?

RADIUS does not make every vendor work the same way. It carries the authentication and authorisation decision. The AP or controller determines which returned attributes they support. RFC 4675 describes RADIUS attributes for dynamic VLAN assignment in IEEE 802 networks and notes that a wireless network device can treat a security association as a virtual port. 6

Phase Cisco Meraki iPSK with RADIUS HPE Aruba MPSK Ruckus DPSK What you must verify
Device initiates association Client presents its configured PSK; AP forwards documented iPSK material to RADIUS. 1 Client associates with MPSK passphrase. 2 Client associates with DPSK-enabled WLAN. 3 Correct SSID and current key are used.
Authorisation lookup RADIUS matches key flow and returns Access-Accept with key information. 1 ClearPass returns Access-Accept with authorisation information and MPSK passphrase VSA. 2 SmartZone reads DPSK record and selected role or VLAN. 3 Lookup source identifies device or key group.
Access outcome RADIUS override can replace SSID default VLAN tag; Dashboard group policy can apply additional controls. 1 Aruba documents authorisation information from ClearPass. Create and verify your ClearPass policy independently. 2 User role transfers its permissions, which include VLAN; VLAN can also be selected at key generation. 3 Device receives expected subnet and policy.
Negative outcome Absence of valid RADIUS acceptance means no successful iPSK association. 1 Incorrect passphrase or Access-Reject fails authentication. 2 Delete DPSK, then test new association. 3 Logs show denial, not just client-side error.

For Cisco Meraki, test both the default VLAN and RADIUS-override outcomes, then place the returned VLAN and AP trunk configuration in a change record. For Aruba, prove the ClearPass policy outcome in your own environment. For Ruckus, keep the role or VLAN selected during DPSK generation compatible with the switch and gateway design. 1 2 3

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.

How do you test whether key revocation works?

Include revocation in the very first deployment. You are testing the operational response to a lost local device, an offboarded contractor, or an incorrectly issued key. The success condition is not "we deleted the record". The success condition is "the device cannot complete a new association with the removed key, and the logs identify the reason".

Start with a positive test. Connect a test device using the issued key. Capture the controller or RADIUS acceptance event, the assigned client policy, and the network segment observed by the device. For Cisco Meraki, check the Dashboard client details and your RADIUS logs. For Ruckus, capture the DPSK record, role or VLAN, and association outcome. For Aruba, capture the ClearPass outcome as well as the AP outcome. 1 2 3

Then revoke the key from its source of truth. Remove or deny the corresponding Cisco Meraki RADIUS mapping. Remove the ClearPass registration or authorisation that provides the Aruba MPSK decision. Delete the Ruckus DPSK. For UniFi PPSK, remove the password-to-VLAN mapping in the current UniFi configuration and validate it according to current UniFi documentation before using the workflow in a production environment. 1 2 3 4 Force a new association. Disable and re-enable WiFi or forget the SSID, then attempt to rejoin with the old key. Check the exact logs. For Aruba, additional caching must be considered because a cached MPSK can bypass a new MAC authentication lookup. A new test that uses a cached state does not demonstrate timely revocation. 2

Finally, test a nearby unaffected key on the same SSID. It should still join and receive its intended policy. This catches over-broad changes in the WLAN, RADIUS client registration, or switch trunks. Record the time from revocation to failed new association. That measurement tells venue operations what the joiners, movers, and leavers process can actually promise.

How to deploy iPSK on Cisco Meraki, HPE Aruba and Ruckus - ipsk revocation test

What goes wrong, and how do you fix it?

Symptom Potential Configuration Area First Check
Client never joins with Cisco Meraki key SSID mode or RADIUS return Confirm Identity PSK with RADIUS, direct access, RADIUS reachability, and expected RADIUS outcome. 1
Client joins but lands on incorrect Cisco Meraki subnet VLAN override or AP uplink Compare default SSID VLAN, RADIUS override outcome, and AP trunk allowance. 1
Aruba MPSK join fails after profile edit Unsupported combination Confirm WPA2-PSK-AES, ClearPass as primary server, and no manual MAC authentication, denylisting, or internal RADIUS combination. 2
Aruba revocation appears slow Roaming cache Establish whether the AP used the documented local MPSK cache before declaring the design faulty. 2
Ruckus key is shared unexpectedly DPSK type Review whether a group DPSK was selected instead of a key intended to be bound. 3
UniFi PPSK missing from 6 GHz design Security mode and band PPSK is WPA2 only and does not work on 6 GHz. Use the cited UniFi guidance to redesign the access method. 4

Where does iPSK fit in Multi-Tenant WiFi design?

iPSK is an access-control pattern, not an entire WiFi operating model. It fits in Multi-Tenant WiFi where residents, building systems, and staff devices require different access decisions. Pair it with Guest WiFi for visitors. For building contract decisions, see Bulk internet agreement vs managed WiFi: which model fits your building.

This pattern applies in Hospitality, Retail, Transport, and Healthcare. Purple can deliver its hardware-agnostic cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, or Ubiquiti UniFi infrastructure. See Guest WiFi Management: Smart Authentication & Segmentation and Cloud WiFi Management: Secure Enterprise Connectivity 2026 for broader context.

Detailed example: In-room hotel devices and building operations

A 200-room hotel requires an operational SSID for in-room devices and a separate building operations segment, without creating a separate SSID for each device category. Network architects select Cisco Meraki iPSK with RADIUS in bridge mode. The RADIUS design contains a key record and desired VLAN decision for each device category. The SSID has a default VLAN, and only defined RADIUS responses can override it. 1

The measurable acceptance set is discrete. A test room device must connect with its issued key and receive the room-device segment. A building operations device must receive the operations segment. A key removed from the RADIUS store must fail a new association. Another valid key must still be able to connect. This proves that access, segmentation, and revocation processes work together rather than as isolated demonstrations.

Detailed example: Stadium operations and temporary event devices

A stadium uses Ruckus SmartZone for temporary event teams that require controlled access during setup. Engineers generate unbound DPSKs for single-device handovers and independently controlled group DPSKs for shared equipment. SmartZone contains clear role or VLAN options for each key. 3

The measurable outcome is the join matrix. A key that binds after first use must not grant access to an unplanned second device. A group key must land each authorised device on its intended VLAN. Once the event concludes, removing the key must prevent a new association by the original test device. This gives venue operations repeatable issue-and-revoke control without SSID sprawl.

How to deploy iPSK on Cisco Meraki, HPE Aruba and Ruckus - radius lookup flow

Frequently asked questions

Can I deploy iPSK on existing Cisco Meraki access points?

Yes, Cisco Meraki documents iPSK with RADIUS on its wireless access-control configuration, subject to its stated feature limits. You configure the SSID, RADIUS servers, and bridge-mode VLAN overrides where required in the Dashboard. Ensure the SSID is not tunnelled to an MX Concentrator, and do not plan for WPA3 with the documented iPSK with RADIUS workflow. 1

Is ClearPass required for HPE Aruba Central MPSK?

Yes, the stated HPE Aruba Central MPSK workflow selects ClearPass Policy Manager as the primary server. ClearPass provides device-specific or group-specific passphrases and returns documented Access-Accept authorisation information. Check the combinations excluded by Aruba before rollout, specifically manual MAC authentication, denylisting, and internal RADIUS servers. 2

Can Ruckus DPSK place a device on a separate VLAN?

Yes, Ruckus SmartZone allows you to select a VLAN ID when generating a DPSK and allows you to assign a user role whose permissions include a VLAN. You must still ensure the WLAN, AP uplinks, switches, and gateways carry that segment. Create and test a key for each desired policy outcome before issuing keys at venue scale. 3

Are Ubiquiti UniFi Private PSK and RADIUS-assigned VLANs the same?

No, UniFi describes PPSK and RADIUS-assigned VLANs as separate options. PPSK maps passwords on a shared SSID to a VLAN. RADIUS-assigned VLANs use unique profiles and require WPA2 Enterprise or WPA3 Enterprise. UniFi PPSK is WPA2 only and does not work on the 6 GHz band. 4

How much effort is required for an iPSK deployment?

A pilot requires a defined SSID, target VLANs, an access control source, AP-to-RADIUS connectivity at relevant locations, and a revocation test. Effort scales with the number of key owners and policy outcomes, not the number of SSIDs. Start with two policies and a few devices, then document the issuance, support, and offboarding steps before a broader rollout.

Can iPSK help with GDPR or PCI-DSS compliance?

iPSK can support segmentation and access control design, but it does not certify compliance. GDPR Article 32 requires appropriate technical and organisational security measures. PCI-DSS provides technical and operational requirements to secure account data. Evaluate your actual data flows, logging, retention, access rights, and payment environment with your relevant compliance owner. 7 8

What should I test before issuing keys to residents or staff?

Test one permitted join, the expected VLAN or policy outcome, a denied join with a removed key, and one unaffected key on the same SSID. Capture controller and RADIUS or ClearPass evidence for each test. Aruba deployments must also consider the documented MPSK cache, as a cached passphrase can alter what is proven by an immediate retry. 1 2 3

References

Key Definitions

iPSK

A distinct pre-shared key used on a shared SSID, enabling an access decision per device or group.

Use it when devices need simpler onboarding than enterprise credentials but you still need traceable issue and revocation.

MPSK

HPE Aruba’s Multi Pre-Shared Key capability, documented with ClearPass-issued device-specific or group-specific passphrases.

Use it in an Aruba Central and ClearPass design that needs personal-key access control.

DPSK

Ruckus Dynamic PSK, created and managed in SmartZone for a DPSK-enabled WLAN.

Use it when SmartZone is the control point for issuing, binding and deleting keys.

PPSK

Ubiquiti UniFi Private Pre-Shared Keys, which map a password to a VLAN on a shared SSID.

Use it for UniFi local VLAN segmentation within the documented WPA2 and band constraints.

RADIUS

A protocol and service model for authentication, authorisation and accounting decisions between an access point and a policy service.

Use it where the platform documents a RADIUS-backed iPSK or MPSK workflow and you need central control.

VLAN

A logical network segment that separates broadcast domains and can be assigned as part of an access decision.

Use it to keep resident, guest, operational and device traffic on distinct policy paths.

RADIUS Access-Accept

The success response from a RADIUS server, which may include vendor-specific key or authorisation information.

Inspect it when troubleshooting why a device joined, which policy it received or why a VLAN outcome changed.

RADIUS override

A platform capability that lets a successful RADIUS response replace an SSID’s default VLAN tag.

Use it on supported Cisco Meraki bridge-mode designs when central policy should control the client VLAN.

Four-way key handshake

The WPA key-establishment exchange used after association to establish traffic protection keys.

It explains why a correct personal key and accepted policy result are both needed before a client can use the network.

Revocation test

A controlled fresh-association test showing that a removed or denied key no longer permits network access.

Run it before wider rollout and after any access-control change to prove the joiners, movers and leavers process.

Worked Examples

A 200-room hotel needs room devices and building operations on one SSID with separate network segments.

Configure Cisco Meraki iPSK with RADIUS in bridge mode. Maintain a RADIUS record and intended VLAN decision for each device category, set a default SSID VLAN and enable the documented RADIUS override. Validate a room-device join, an operations-device join, a revoked-key denial and an unaffected-key connection. [1]

A stadium needs controlled access for temporary event devices without creating multiple operational SSIDs.

In Ruckus SmartZone, generate unbound DPSKs for controlled single-device handover and a governed group DPSK for shared equipment. Assign the intended role or VLAN at generation. Validate that a newly bound key rejects an unplanned second device, the group key receives its policy and deletion blocks a fresh join after teardown. [3]

Sources

  1. Cisco Meraki: iPSK with RADIUS authentication
  2. HPE Aruba: Support for MPSK in WLAN SSID
  3. Ruckus SmartZone: Generating Dynamic PSKs
  4. Ubiquiti UniFi: PPSK and RADIUS for multiple VLANs
  5. RFC 3580: IEEE 802.1X RADIUS usage guidelines
  6. RFC 4675: RADIUS attributes for VLAN and priority support
  7. EUR-Lex: General Data Protection Regulation
  8. PCI Security Standards Council: PCI Data Security Standard

Continue reading in this series

Bulk internet agreement vs managed WiFi: which model fits your building

A practical procurement reference for property, IT and operations leaders comparing resident-paid retail broadband, a bulk internet agreement and managed WiFi. It clarifies ownership, resident move-in, security, cost scope and contractual exit, using US bulk-internet framing and UK equivalents.

Read the guide →

Apartment WiFi solutions: a comprehensive guide for businesses

This guide covers the architecture, deployment, and business case for apartment WiFi solutions in Build to Rent and multi-dwelling unit properties. It explains how Identity Pre-Shared Key (iPSK) technology creates secure, isolated network bubbles for each resident while supporting smart devices and IoT. Property developers, landlords, and BTR operators will find actionable deployment guidance, ROI data, and worked implementation scenarios.

Read the guide →

Cox business managed WiFi: a comprehensive guide for businesses

This guide details how property developers and BTR operators can deploy scalable, secure networks using Cox Business managed WiFi. It covers network architecture, vendor-neutral hardware deployment, and the business impact of transitioning connectivity from an operational headache to reliable infrastructure.

Read the guide →

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.