Skip to main content

Uu PPSK 2023: comparing features and deployment models

This technical reference guide compares Unique per-User Private Pre-Shared Key (UU PPSK) WiFi architecture against traditional shared PSK and 802.1X deployments, with a specific focus on the 2023 landscape of vendor implementations and platform capabilities. It provides property developers, BTR operators, and MDU landlords with actionable deployment strategies, VLAN architecture guidance, and automated lifecycle management workflows. The guide covers three deployment models, real-world case studies, and the compliance implications of each authentication approach.

📖 8 min read📝 1,955 words🔧 2 worked examples4 practice questions📚 10 key definitions

Listen to this guide

View podcast transcript
UU PPSK 2023: Comparing Features and Deployment Models. A Purple Technical Briefing. Welcome. Today we are going to cover one of the most important architectural decisions you will make when designing WiFi for a multi-tenant residential property: which pre-shared key model to deploy. Specifically, we are focusing on UU PPSK, which stands for Unique per-User Pre-Shared Key, and why it has become the architecture of choice for Build to Rent operators, student accommodation providers, and multi-dwelling unit landlords across the UK. Let us start with the problem. You are managing a building where dozens or hundreds of separate households share the same physical network infrastructure. Each resident needs a private, home-like WiFi experience. Their Chromecast needs to find their phone. Their smart speaker needs to talk to their bulbs. And critically, none of that should be visible to the resident in the flat next door. The traditional answer was either a shared password, which is a security liability at scale, or a full 802.1X enterprise deployment, which requires a Public Key Infrastructure, certificate management, and a RADIUS server that most property operators simply do not have the IT resource to run. Neither option is right for a 200-unit Build to Rent block. That is where PPSK comes in. PPSK stands for Private Pre-Shared Key. The concept is straightforward: instead of one shared WiFi password for the whole building, each resident gets their own unique passphrase. They connect to the same SSID, the same network name, but their key is theirs alone. If they move out, you revoke their key. It has zero effect on any other resident. Now, there are three distinct models here, and understanding the difference is critical to making the right architectural decision. The first model is a standard shared PSK. One password, everyone on the same network. This is what most buildings still run today. It is simple to deploy, but it is a single point of failure. One resident shares the password on a forum, and you have lost control of your network. You want to remove a contractor's access? You have to change the password for everyone. At scale, this is not manageable. The second model is Group PPSK. Here, you assign a unique key to each group of users, perhaps one key per floor, or one key per tenancy type. It is better than a shared password, but it still has a blast radius problem. If one key in a group is compromised, the entire group is affected. You still cannot isolate individual residents from each other at the network layer. The third model, and the one we are focusing on today, is UU PPSK. Unique per-User Pre-Shared Key. Also called iPSK by Cisco Meraki, DPSK by Ruckus, and MPSK by HPE Aruba. The terminology varies by vendor, but the concept is identical. Every single resident, every single device group, gets its own cryptographically unique key. And that key maps to its own VLAN, its own network segment, completely isolated from every other resident in the building. This is the architecture that delivers what we call the WiFi bubble. Resident A's devices can see each other, they can cast, they can pair, they can share files, exactly as they would on a home network. But Resident A cannot see a single device belonging to Resident B, even though they are both connected to the same access point, on the same SSID, using the same physical cable infrastructure. Let me walk you through the technical authentication flow, because this is where the mechanism becomes clear. When a resident's device connects to the SSID, the wireless LAN controller intercepts the connection attempt. During the WPA2 four-way handshake, the device presents its pre-shared key. The controller looks up that key in the PPSK database. It returns the unique VLAN ID assigned to that resident. The controller validates the key, and the device is authenticated and placed on its dedicated VLAN. Critically, that VLAN assignment also carries the correct bandwidth policy and firewall rules. So the device does not just get authenticated. It gets automatically placed on the correct network segment, from a single SSID. No SSID proliferation. No beacon overhead. One network name, hundreds of isolated private networks underneath it. Now, a word on MAC address randomisation, because this is the pitfall that catches most deployments out. Since iOS 14, Android 10, and Windows 11, devices use randomised MAC addresses by default for privacy reasons. If your authentication platform is doing a MAC lookup and the device presents a randomised address, the lookup fails and the device cannot connect. The solution is to implement a pre-registration workflow where residents register their device before connecting. Purple's platform handles this automatically as part of the resident onboarding flow. Let us talk about deployment models, because UU PPSK can be deployed in three distinct ways, and the right choice depends on your building size, your IT resource, and your budget. The first is controller-local PPSK. Here, the unique keys are stored directly on the wireless controller, with no external RADIUS server required. This works well for smaller deployments, up to around 50 units, and it is the simplest to operate. Ubiquiti UniFi supports this natively. The limitation is scalability. Most controllers cap out at a few hundred local PPSK entries, and you lose the centralised lifecycle management that makes UU PPSK operationally viable at scale. The second model is RADIUS-backed PPSK. Here, the keys are stored in an external RADIUS server, and the controller queries the RADIUS server for every new connection. This scales to thousands of units. Ruckus SmartZone, HPE Aruba ClearPass, and Cisco ISE all support this model. The operational overhead is higher, but the scalability and lifecycle management capabilities are significantly better. The third model, and the one Purple recommends for Build to Rent and multi-dwelling unit operators, is cloud RADIUS-as-a-Service. Here, the RADIUS infrastructure is hosted and managed by Purple, and you connect your access points to it via a cloud overlay. This gives you the scalability of RADIUS-backed PPSK without the operational overhead of running your own RADIUS server. Purple's platform sits on top of your existing hardware, whether that is Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet, and provides the orchestration layer for key provisioning, lifecycle management, and resident onboarding. The key lifecycle is fully automated. A resident moves in, their key is provisioned via the property management system integration. They move out, their key is revoked instantly, with no impact on any other resident. No manual intervention, no security gaps, no password rotation drama. Let me give you two concrete deployment scenarios to bring this to life. The first is a 250-unit Build to Rent development. The developer had specified Cisco Meraki access points throughout the building. They needed each resident to have a private WiFi experience with full IoT support, same-day move-in readiness, and the ability to support 15 to 25 devices per household. The architecture deployed was a single SSID across the building, with UU PPSK via Purple's cloud RADIUS service. Each resident received a unique key at move-in, delivered via the resident app. The key mapped to a dedicated VLAN with a private subnet, giving each household a fully isolated network segment. mDNS reflection was enabled within each VLAN, so Chromecast, Apple TV, and Sonos all worked as expected. The building went live with 250 active resident VLANs on day one, with zero manual RADIUS configuration required by the on-site team. The second scenario is a 400-bed purpose-built student accommodation block. The challenge here is the annual cohort turnover. Every August, 400 students move out and 400 new students move in, often within the same week. With a shared PSK model, that means a building-wide password rotation affecting every returning resident. With UU PPSK, it means revoking 400 keys and provisioning 400 new ones, all automated via the student management system integration. The deployment used Ruckus SmartZone with DPSK, backed by Purple's RADIUS service. Each student received their unique key via email during pre-arrival registration. The operations team reported a 70% reduction in WiFi-related support tickets in the first term, primarily because the Chromecast and smart TV pairing issues that had plagued the previous shared PSK deployment were completely eliminated. Now let me cover three practical rules of thumb before we move to the rapid-fire questions. Rule one: if your building has more than 50 units, use RADIUS-backed UU PPSK, not controller-local PPSK. The scalability ceiling of controller-local PPSK will cause you problems within 12 months of go-live. Rule two: plan for MAC randomisation from day one. Build a pre-registration workflow into your resident onboarding process. Do not assume devices will present their permanent MAC address by default. Rule three: automate the key lifecycle. The operational value of UU PPSK over a shared PSK is entirely dependent on keys being provisioned and revoked automatically. Manual key management at scale is not viable. Integrate with your property management system from the outset. Right, let us do a rapid-fire round on the questions I get asked most often. Does UU PPSK work with WPA3? Yes, with caveats. WPA3-SAE changes the handshake mechanism. Most modern controllers support UU PPSK in WPA2 and WPA3 transition mode for backward compatibility. If you are specifying WiFi 6E access points that mandate WPA3 on the 6 gigahertz band, verify your vendor's specific support before purchasing hardware. How many unique keys can a single SSID support? This depends on your controller platform. With an external RADIUS server, the practical limit is your RADIUS database capacity. Purple's cloud RADIUS service scales to tens of thousands of concurrent keys. Is UU PPSK a replacement for 802.1X? No. For fully managed corporate device fleets, 802.1X remains the right answer. UU PPSK is the right answer for residential networks where you need per-household isolation, IoT support, and operational simplicity at scale. What about GDPR compliance? UU PPSK gives you a complete audit trail. Every connection is tied to a specific resident key, which is tied to a specific tenancy record. With a shared PSK, that accountability is impossible. UU PPSK is the only architecture that allows you to respond accurately to a subject access request or a law enforcement enquiry. To summarise: UU PPSK is the authentication architecture that makes multi-tenant WiFi operationally viable at residential scale. It delivers per-resident network isolation, automates key lifecycle management, and supports the full range of consumer IoT devices without requiring enterprise certificate infrastructure. For any Build to Rent development or multi-dwelling unit property with more than 50 units, it is the architecture you should be specifying today. If you want to explore how Purple's Multi-Tenant WiFi solution can work with your existing hardware, visit purple dot ai or speak to one of our network architects. Thank you for listening.

header_image.png

Executive summary

For IT managers and network architects operating multi-tenant environments, delivering secure, home-like WiFi at scale presents a distinct architectural challenge. Traditional shared passwords fail security audits and create operational bottlenecks when residents move out. Standard 802.1X enterprise authentication requires a RADIUS server and a supplicant on every device, rendering it incompatible with the vast majority of consumer smart home and IoT hardware.

Unique per-User Private Pre-Shared Key (UU PPSK) bridges this gap. It provides per-resident network isolation, automates key lifecycle management, and delivers a secure WiFi experience that supports the 15 to 25 devices found in a typical modern household. In 2023, Ubiquiti UniFi added native PPSK support, completing the picture across all major enterprise hardware platforms. This guide details how to implement UU PPSK, compares vendor-specific features across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet, and outlines the deployment architecture required to support multi-tenant properties efficiently. For related context on the broader PPSK landscape, see What is PPSK: comparing features and deployment models .

Technical deep-dive

The fundamental premise of UU PPSK is straightforward: instead of broadcasting multiple SSIDs or relying on a single shared password, the wireless controller assigns a unique passphrase to each resident or device group. When a device authenticates using its specific key, the controller maps that connection to a dedicated VLAN. This architecture creates a WiFi bubble for each resident. Their devices can discover each other, cast media, and share files exactly as they would on a standard home network, while remaining completely isolated from every other resident in the building.

The authentication flow

When a device connects to the SSID, the access point intercepts the association request. During the WPA2 or WPA3 four-way handshake, the device presents its pre-shared key. The wireless LAN controller (or the cloud management platform) looks up this key in the PPSK database. If the key is valid, the controller identifies the associated VLAN and tags the device's traffic accordingly from that point forward.

architecture_overview.png

This mechanism differs fundamentally from 802.1X. While 802.1X requires an EAP (Extensible Authentication Protocol) exchange and a client-side supplicant, PPSK operates at the WPA Personal layer. The device simply sees a standard WiFi network requiring a password. This ensures compatibility with headless IoT devices, smart TVs, and gaming consoles that cannot process enterprise certificates. For a detailed comparison of when 802.1X is the right choice versus PPSK, the Three SSIDs to rule them all guide covers the three-SSID architecture in full.

Vendor implementations and terminology in 2023

The underlying mechanism is standardised, but vendor terminology varies significantly. Understanding which term maps to which platform is essential when evaluating hardware or reading vendor documentation.

Vendor Feature Name WPA3 Support Max Keys (local) RADIUS-backed
Cisco Meraki iPSK (Identity PSK) Yes (transition mode) 5,000 per network Yes (Cisco ISE)
HPE Aruba MPSK / PPSK WPA2 only for MPSK Unlimited via ClearPass Yes (ClearPass)
Ruckus DPSK (Dynamic PSK) Yes (SmartZone 6.1+) 10,000 per zone Yes (SmartZone)
Juniper Mist ePSK Yes Unlimited via Mist cloud Yes (Mist cloud)
Ubiquiti UniFi PPSK WPA2 only 1,000 per network Yes (external RADIUS)
Cambium ePSK Yes Unlimited via cnMaestro Yes (cnMaestro)
Extreme Private PSK Yes Unlimited via ExtremeCloud Yes (ExtremeCloud)
Fortinet MPSK Yes Unlimited via FortiGate Yes (FortiAuthenticator)

A significant milestone in 2023 was Ubiquiti UniFi shipping native PPSK support in October of that year. This completed enterprise-grade per-user key management across the full hardware stack. The UniFi implementation is currently WPA2 only, which means it will not function on the 6 GHz band. For deployments specifying WiFi 6E hardware, this is a critical constraint to evaluate before committing to a platform.

WPA3 and 6 GHz considerations

The introduction of WPA3 and the 6 GHz band (WiFi 6E and WiFi 7) introduces new variables. WPA3 replaces the traditional PSK handshake with Simultaneous Authentication of Equals (SAE), providing protection against offline dictionary attacks. However, not all vendor implementations of PPSK currently support WPA3-SAE. If you are specifying 6 GHz access points, which mandate WPA3, you must ensure your chosen platform supports PPSK over WPA3, or you will be forced to restrict PPSK clients to the 2.4 GHz and 5 GHz bands.

comparison_chart.png

Implementation guide

Deploying UU PPSK in a Build to Rent (BTR) or multi-dwelling unit (MDU) environment requires careful planning across three phases: logical design, hardware configuration, and resident onboarding.

Phase 1: Logical design and VLAN architecture

Begin by mapping your resident count and device categories. A standard BTR deployment requires a dedicated VLAN for each apartment unit. For a 200-unit building, you need 200 resident VLANs. Additionally, you must provision separate VLANs for building management systems, IoT sensors, and common area Guest WiFi .

Allocate sufficient IP addresses. British Property Federation research indicates an average of 15 to 25 connected devices per household. A /24 subnet per apartment provides 254 usable addresses, which comfortably accommodates future IoT expansion without exhausting the DHCP pool. A /23 subnet provides 510 usable addresses for higher-density households.

A recommended VLAN scheme for a 200-unit BTR property:

VLAN Range Purpose Subnet Size
VLAN 10 to 209 Resident units (one per flat) /24 per VLAN
VLAN 300 Building management systems /24
VLAN 400 IoT sensors and access control /24
VLAN 500 Common area Guest WiFi /23
VLAN 600 Staff and management devices /24

Phase 2: Hardware and RADIUS configuration

For deployments exceeding 50 units, rely on RADIUS-backed PPSK rather than controller-local storage. Connect your access points to a cloud RADIUS service. Configure a single SSID across the property. Map the RADIUS attributes to return the correct VLAN ID based on the authenticated key. Ensure all trunk ports between the access layer switches and the distribution core permit the full range of resident VLANs.

Enable mDNS (Multicast DNS) reflection within each resident VLAN. This is the step most commonly missed in initial deployments, and its absence is the primary cause of Chromecast, Apple TV, and Sonos pairing failures. mDNS reflection allows devices on the same VLAN to discover each other while preventing cross-VLAN discovery.

Phase 3: Automated lifecycle management

The operational viability of UU PPSK depends entirely on automated key management. Integrate your property management system (PMS) with the WiFi authentication platform via REST API. When a tenancy agreement is signed, the system must automatically generate a unique key and assign it to an available VLAN. Deliver this key to the resident via email or a secure resident portal prior to move-in. When the tenancy ends, the system must instantly revoke the key, terminating access for all associated devices without manual IT intervention.

Purple's Multi-Tenant WiFi solution provides this orchestration layer as a cloud overlay on top of your existing hardware. It integrates with property management systems via API, automates key provisioning and revocation, and provides the WiFi Analytics dashboard to monitor network performance across all resident VLANs.

Best practices

Prevent SSID proliferation. Broadcast a maximum of three SSIDs per radio: one for residents (UU PPSK), one for staff and management (802.1X), and one for guests in common areas. Every additional SSID consumes airtime for beacon frames. In a dense residential building, six or eight SSIDs per access point degrades performance for everyone. See Three SSIDs to rule them all for a detailed breakdown of this architecture.

Address MAC randomisation from day one. Modern operating systems including iOS 14 and later, Android 10 and later, and Windows 11 use randomised MAC addresses by default. Implement a pre-registration workflow where residents register their devices, or ensure your portal guides them to disable private addressing for their home network. Failing to address this is the most common cause of authentication failures in new deployments.

Validate trunk ports during commissioning. Design a clean VLAN scheme, deploy the access points, and then test a device on each VLAN before residents move in. Silent traffic dropping due to incomplete trunk port configuration is the most common post-deployment failure mode. Document every trunk port configuration and verify it against your VLAN scheme.

Size your DHCP scopes correctly. A 200-unit building with 20 devices per household requires DHCP capacity for 4,000 devices. Ensure your DHCP server can handle lease renewals at the scale of your deployment, particularly during move-in surges when hundreds of devices attempt to connect simultaneously.

Troubleshooting & risk mitigation

The most common failure mode in UU PPSK deployments is silent traffic dropping due to incomplete VLAN trunking. If a device authenticates successfully but fails to obtain an IP address, verify that the assigned VLAN is permitted across all uplink ports from the access point back to the DHCP server.

A second frequent issue involves smart home devices failing to connect. This often occurs when residents attempt to connect 2.4 GHz-only IoT devices while their phone is connected to the 5 GHz band, and the setup app fails to bridge the gap. Ensure your access points use band steering appropriately, or provide a dedicated 2.4 GHz IoT onboarding SSID that maps to the same resident VLAN.

MAC randomisation failures present as intermittent authentication errors where a device connects successfully on the first attempt but fails on subsequent connections. The device presents a different randomised MAC address each time, causing the RADIUS lookup to fail. The fix is to configure the SSID to request permanent MAC addresses, or to implement a device pre-registration workflow.

For GDPR compliance, maintain a complete audit log of key provisioning and revocation events. Every connection must be traceable to a specific resident key and tenancy record. With a shared PSK, this accountability is impossible. UU PPSK is the only architecture that allows you to respond accurately to a subject access request or a law enforcement enquiry.

ROI & business impact

Implementing UU PPSK delivers measurable business value for property operators. By eliminating building-wide password rotations and automating key provisioning, operators typically see a 50% to 70% reduction in WiFi-related support tickets during peak move-in periods, based on deployment data from Purple's Multi-Tenant WiFi customers.

Providing a secure, high-performance network that supports resident IoT devices out of the box increases tenant satisfaction and retention. For BTR operators, WiFi is now a standard amenity included in rent, and the quality of that service directly influences lease renewal rates.

From a compliance perspective, UU PPSK ensures you meet GDPR requirements for data accountability. Because every connection is tied to a specific resident key, you maintain a clear audit trail of network activity. You can track network performance and utilisation effectively using WiFi Analytics , ensuring you deliver the service quality promised in the tenancy agreement.

For operators in the hospitality and retail sectors, the same UU PPSK architecture applies to staff networks, where per-employee keys replace shared staff passwords and eliminate the security risk of former employees retaining network access after they leave.

Purple has operated across 80,000+ live venues since its founding in 2012, with 99.999% uptime and ISO 27001 certification. The Multi-Tenant WiFi product is hardware-agnostic, operating as a cloud overlay on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet infrastructure. For further reading on the broader PPSK feature set, see What is PPSK: comparing features and deployment models and the Spanish-language equivalent Qué es PPSK: comparación de funciones y modelos de despliegue .

Key Definitions

UU PPSK (Unique per-User Private Pre-Shared Key)

An authentication method that assigns a unique WiFi passphrase to every individual user or household on a single SSID. Each key maps to a dedicated VLAN, isolating the user's traffic from all other users on the same physical infrastructure.

Used in multi-tenant environments to provide network isolation without requiring enterprise 802.1X certificates. The standard architecture for BTR and MDU WiFi deployments.

VLAN (Virtual Local Area Network)

A logical subnetwork that groups a collection of devices together, isolating their broadcast traffic from other devices on the same physical infrastructure.

In a UU PPSK deployment, each resident's unique key maps to their own dedicated VLAN, creating a private network segment that functions like a home router.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised authentication, authorisation, and accounting management for users who connect and use a network service. Defined in RFC 2865.

Enterprise PPSK deployments use a RADIUS server to store keys and return the correct VLAN assignment to the access point. Cloud RADIUS-as-a-Service eliminates the need to operate your own RADIUS infrastructure.

mDNS (Multicast DNS)

A protocol that resolves hostnames to IP addresses within small networks that do not include a local name server. Defined in RFC 6762.

Must be enabled and reflected within resident VLANs so devices like Apple TV, Chromecast, and Sonos can be discovered by smartphones on the same VLAN. Without mDNS reflection, casting and smart home pairing fails.

MAC randomisation

A privacy feature in modern operating systems that generates a randomised MAC address for each WiFi network the device connects to, preventing tracking across networks.

Can interfere with PPSK authentication workflows that use MAC address lookups. Requires a pre-registration workflow or SSID-level configuration to request permanent MAC addresses.

802.1X

An IEEE standard for port-based network access control that provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. Requires a RADIUS server and a client-side supplicant.

The enterprise alternative to PPSK, suitable for managed corporate device fleets. Not suitable for consumer IoT devices, smart TVs, or gaming consoles that lack a supplicant.

WPA3-SAE (Simultaneous Authentication of Equals)

The authentication mechanism used in WPA3 Personal, replacing the traditional PSK handshake with a Dragonfly key exchange that provides protection against offline dictionary attacks.

Mandatory for the 6 GHz band (WiFi 6E). Not all vendor implementations of PPSK support WPA3-SAE, which can restrict PPSK clients to the 2.4 GHz and 5 GHz bands on WiFi 6E hardware.

SSID proliferation

The negative performance impact caused by broadcasting too many network names from a single access point. Each SSID consumes airtime with beacon frames, reducing available bandwidth for data traffic.

UU PPSK solves this by allowing hundreds of isolated resident networks to operate under a single SSID, rather than requiring a separate SSID per resident or per floor.

iPSK (Identity PSK)

Cisco Meraki's implementation of per-user pre-shared key authentication. Functionally equivalent to UU PPSK. Supports up to 5,000 unique keys per network and integrates with Cisco ISE for RADIUS-backed deployments.

The term used in Meraki documentation and the Meraki dashboard. When evaluating Meraki hardware for a BTR deployment, iPSK is the feature to specify.

DPSK (Dynamic PSK)

Ruckus Networks' implementation of per-user pre-shared key authentication. Supports up to 10,000 keys per zone in SmartZone deployments and integrates with Purple's cloud RADIUS service.

The term used in Ruckus documentation. Ruckus SmartZone 6.1 and later adds WPA3 support for DPSK, enabling use on the 6 GHz band.

Worked Examples

A 250-unit Build to Rent development in Manchester needs to provide secure WiFi included in the rent. Residents expect to connect smart TVs, Sonos speakers, and gaming consoles from day one. The IT team wants to minimise support tickets during the September move-in surge and ensure that when a resident moves out, their access is revoked without affecting any other resident.

Deploy a single building-wide SSID using UU PPSK backed by Purple's cloud RADIUS service. Integrate the RADIUS platform with the property management system via REST API. Assign a /24 subnet and a dedicated VLAN to each of the 250 units (VLAN 10 through VLAN 259). Configure the API integration to generate a unique PPSK upon lease signing and email it to the resident with a QR code. Enable mDNS reflection within each VLAN to support Sonos, Chromecast, and Apple TV discovery. Configure the PMS integration to automatically revoke the key on the tenancy end date. Use Cisco Meraki iPSK with the Meraki dashboard connected to Purple's cloud RADIUS for key storage and VLAN assignment.

Examiner's Commentary: This approach eliminates the need for 802.1X supplicants, ensuring 100% compatibility with consumer IoT devices. The API integration removes manual provisioning, allowing the network to handle 250 simultaneous move-ins without IT intervention. The dedicated VLANs provide the required security isolation. mDNS reflection is the critical step that enables smart home functionality within each isolated VLAN. The automated revocation on tenancy end date eliminates the security gap that exists in manual key management workflows.

A 400-bed purpose-built student accommodation block currently uses a single shared password. Students frequently complain that they can see other people's Chromecasts, and the operator cannot revoke access for students who have moved out without changing the password for everyone. The operator also needs to handle annual cohort turnover, where 400 students move out and 400 new students move in within the same week.

Migrate from the shared PSK to a UU PPSK architecture using Ruckus SmartZone with DPSK, backed by Purple's RADIUS service. Provision 400 unique keys, one per student room, each mapping to a distinct VLAN. Distribute the keys via the student management system portal during pre-arrival registration, delivered by email with a QR code. Configure automatic key expiry aligned to contract end dates. At annual turnover, the system revokes 400 expired keys and provisions 400 new ones automatically via the student management system integration.

Examiner's Commentary: This resolves the broadcast domain issue immediately. Students will only see devices on their own VLAN, securing their Chromecasts and eliminating the cross-resident device visibility complaints. The automated lifecycle management solves the annual turnover problem by isolating key revocation to the individual user, preventing disruption to the rest of the cohort. Pre-arrival key distribution via email eliminates the move-in day connection surge, as students arrive with their key already configured on their devices.

Practice Questions

Q1. You are designing the network for a 300-unit Build to Rent property. The developer wants to use Ubiquiti UniFi access points and store the PPSK keys locally on the controller to save costs. What is the primary risk of this approach, and what would you recommend instead?

Hint: Consider the scalability limits of local controllers versus cloud RADIUS, and the operational impact of manual key management at 300-unit scale.

View model answer

The primary risks are scalability and lack of automated lifecycle management. Ubiquiti UniFi's local PPSK implementation supports up to 1,000 entries per network, which a 300-unit building will approach quickly when accounting for multiple devices per household. More critically, local storage prevents API integration with the property management system, forcing the IT team to manually provision and revoke keys for every move-in and move-out. At 300 units with typical BTR turnover rates, this becomes a full-time operational burden. The recommendation is to use UniFi hardware but connect it to an external cloud RADIUS service via the RADIUS integration option, enabling automated key lifecycle management through the PMS API.

Q2. A resident reports that their smartphone connects to the UU PPSK network perfectly, but they cannot pair their new smart lightbulbs. The lightbulbs only support 2.4 GHz, while the smartphone is connected to the 5 GHz band. How should you resolve this?

Hint: Think about how the manufacturer's setup app communicates with the bulb during the initial pairing process, and what band both devices need to be on simultaneously.

View model answer

The issue is that the smartphone's setup app needs to communicate directly with the bulb during provisioning, which requires both devices to be on the same frequency band. The smartphone is on 5 GHz, the bulb is on 2.4 GHz, and the setup app cannot bridge this gap. The solution is to temporarily disable band steering for the resident's VLAN, or to provide a dedicated 2.4 GHz IoT onboarding SSID that maps to the same resident VLAN. Once the bulb is provisioned and connected to the resident's VLAN, the smartphone can return to the 5 GHz band and control the bulb via the cloud service or mDNS discovery within the VLAN.

Q3. Your organisation is upgrading to WiFi 6E access points, which require WPA3 for the 6 GHz band. You plan to use UU PPSK for resident authentication. What critical compatibility check must you perform before purchasing hardware, and what is your fallback if the check fails?

Hint: Not all vendor implementations of PPSK support WPA3-SAE. The 6 GHz band mandates WPA3.

View model answer

You must verify that the specific vendor's implementation of PPSK supports WPA3-SAE on the 6 GHz radio. Ubiquiti UniFi's PPSK is WPA2 only and will not function on the 6 GHz band. HPE Aruba's MPSK also has WPA3 constraints. Ruckus SmartZone 6.1 and later adds WPA3 support for DPSK. If your chosen hardware does not support PPSK on WPA3, the fallback is to configure the 6 GHz radio for WPA3-only corporate or staff traffic (802.1X), and restrict PPSK resident traffic to the 2.4 GHz and 5 GHz radios using WPA2. This is a valid architecture but limits resident devices to WiFi 6 speeds rather than WiFi 6E.

Q4. You receive a GDPR subject access request from a former resident asking for all network activity data associated with their tenancy. Your building currently uses a shared PSK. Can you fulfil this request accurately, and what architectural change would enable you to do so in future?

Hint: Consider how traffic is attributed to individual users in a shared PSK environment versus a UU PPSK environment.

View model answer

With a shared PSK, you cannot fulfil the request accurately. Every device on the network presents the same network credentials, making it impossible to attribute specific network activity to a specific resident. You can identify traffic by MAC address, but MAC randomisation means even this is unreliable. Migrating to UU PPSK resolves this. Each resident's unique key is tied to their tenancy record in the property management system. Every connection event is logged against that key, creating a complete audit trail that can be extracted and provided in response to a subject access request. This also satisfies the GDPR accountability principle under Article 5(2).