PPSK life: comparing features and deployment models

Welcome to the Purple WiFi technical series. Today we're covering PPSK life - that's Private Pre-Shared Key - comparing its features and deployment models for property developers, landlords, and build-to-rent operators. Let's start with context. If you're managing a residential building - whether that's a 50-unit BTR development, a student accommodation block, or a co-living space - you've almost certainly run into the same WiFi problem. One shared password for the whole building. Someone moves out, you rotate the key, and suddenly 200 residents can't connect their devices. Or worse, you don't rotate it, and your ex-tenant still has access. Standard PSK - Pre-Shared Key - was never designed for this. It was designed for a household of four people who all trust each other. Not for a building of 300 residents who don't. So what is PPSK? Private Pre-Shared Key gives every single resident, or every single device, its own unique WiFi password. They all connect to the same network name - the same SSID - but each key is unique to that resident. When resident A connects, the network knows it's resident A. When they move out, you revoke their key. Nobody else is affected. Not one other resident needs to reconnect a single device. Now, you might be thinking - isn't that just what 802.1X does? And you'd be half right. 802.1X, the IEEE enterprise authentication standard, also gives individual credentials. But it requires a certificate infrastructure, a RADIUS server, and client-side supplicant configuration. Your residents' Chromecasts, PlayStation consoles, and smart thermostats cannot do 802.1X. They don't have the software stack for it. PPSK works with every device that can connect to WiFi - because from the device's perspective, it's just entering a password. This is the core insight of PPSK life. You get individual accountability - the security benefit of 802.1X - without the infrastructure overhead or the device compatibility headache. Now let's talk about the vendor landscape, because the terminology varies. Aruba calls it MPSK - Multi-PSK. Cisco Meraki calls it iPSK - Identity PSK - and has recently added WiFi Personal Network on top of that. Ruckus calls it DPSK - Dynamic PSK. Extreme Networks, where the technology was pioneered, calls it PPSK. Juniper Mist uses ePSK. The underlying concept is identical across all of them. One SSID, many keys, per-user isolation. At Purple, we sit above all of these as a hardware-agnostic cloud overlay. We run on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. We manage the key lifecycle - provisioning, rotation, revocation - regardless of which access points are in the ceiling. Let's get into the architecture. In a PPSK deployment, the access point - or the controller behind it - holds a table mapping each key to a VLAN. When a device connects with resident A's key, the AP assigns that device to resident A's VLAN. Resident B's devices land on resident B's VLAN. At Layer 2, they are completely invisible to each other. This is what we call the WiFi bubble. Every resident gets a private area network - their own logical home network - even though they're sharing physical infrastructure. Their phone discovers their Chromecast. Their smart speaker pairs with their bulbs. Their console gets NAT type Open. It works exactly like a home router, because from the network's perspective, it is a home router - just a virtual one. The RADIUS server is optional in some vendor implementations for smaller deployments, but for anything above a few dozen units, you want RADIUS in the loop. It gives you centralised logging, dynamic VLAN assignment, and the ability to integrate with your identity provider - Microsoft Entra ID, Okta, or Google Workspace. Purple provides RADIUS-as-a-Service as part of the platform, so you don't need to run your own server. Now, WPA3 adds another layer here. WPA3-Personal introduced SAE - Simultaneous Authentication of Equals - which replaces the older 4-way handshake. SAE is resistant to offline dictionary attacks, meaning even if someone captures the handshake, they can't brute-force the key offline. For PPSK deployments, WPA3 transition mode - supporting both WPA2 and WPA3 clients simultaneously - is the right starting point for 2025 and beyond. Most access points from Cisco Meraki, HPE Aruba, and Ruckus support this today. Let's walk through two real-world deployment scenarios, because theory only gets you so far. First scenario: a 200-unit build-to-rent development in Manchester. The developer is pre-wiring the building with HPE Aruba access points - one per floor, corridor-mounted. They want residents to have WiFi from day one of their tenancy, with no broadband wait, and they want to charge a premium for the service as part of the amenity package. The architecture here is straightforward. One SSID across the building - let's call it the building name. Purple provisions a unique MPSK key for each unit during the pre-tenancy onboarding flow. The resident receives their key by email before they move in. They arrive, connect their phone, and every other device they add uses the same key. Their Chromecast works. Their Alexa works. Their PlayStation gets NAT type Open. When they move out, the property management system triggers a webhook to Purple's API. Purple revokes the key. The next resident gets a new key. Nobody else in the building is affected. The whole lifecycle - provisioning, rotation, revocation - is automated. The property manager doesn't touch the network. The commercial outcome: research from the British Property Federation shows BTR operators command a rent premium of fifteen to thirty pounds per unit per month when WiFi is included as a managed amenity. Void periods reduce by five to ten days because move-in-day connectivity is guaranteed. And the per-door cost of a software overlay on owned hardware is typically thirty to fifty percent lower than per-unit broadband contracts. Second scenario: a 600-bed purpose-built student accommodation block. The challenge here is cohort week - the first week of September, when six hundred students arrive simultaneously, each with an average of seven devices. Laptops, phones, tablets, consoles, smart speakers. That's over four thousand devices trying to onboard in 48 hours. With a standard PSK setup, this is a support nightmare. With PPSK, each student receives their key in the pre-arrival welcome email. They arrive, connect once, and all their devices are on their private segment. The gaming console gets the right NAT type. The smart TV streams without buffering. The laptop connects to the university VPN without interference from other residents' traffic. The key operational difference from BTR is the annual cohort rotation. Every August, you bulk-provision new keys for the incoming cohort and bulk-revoke the outgoing cohort's keys. Purple handles this via SCIM integration with the student management system, or via a CSV import if the system doesn't support SCIM. Either way, it's a scheduled operation, not a manual one. Now let me cover the implementation pitfalls, because there are a few that catch people out. First: VLAN exhaustion. Each resident segment needs its own VLAN. A 500-unit building needs 500 VLANs. Most enterprise switches support 4,096 VLANs under the 802.1Q standard, so you're unlikely to hit the ceiling, but you need to plan your VLAN range at design time. Don't leave it as an afterthought. Second: mDNS and device discovery. By default, mDNS - the protocol that Chromecast, AirPlay, and Sonos use to discover devices - doesn't cross VLAN boundaries. You need mDNS reflection or proxy configured on your controller or gateway to allow discovery within a resident's VLAN while blocking it between VLANs. Every major vendor supports this, but it's not always enabled by default. Check it before go-live. Third: MAC address randomisation. Modern iOS and Android devices randomise their MAC address per network to protect privacy. This breaks any MAC-based authentication or device registration flow. PPSK sidesteps this entirely - authentication is key-based, not MAC-based - but if you're running any supplementary MAC filtering rules, you need to account for randomisation. Fourth: key length and complexity. PPSK keys should be at least 20 characters, randomly generated, and never reused across residents. A weak key undermines the entire isolation model. Purple generates cryptographically random keys by default. If you're generating keys manually or through a property management system integration, enforce a minimum length in your provisioning workflow. Fifth: the IoT onboarding flow. Smart home devices - thermostats, door locks, smart plugs - often use a Bluetooth or temporary WiFi setup mode before joining the main network. Your onboarding instructions to residents need to account for this. The device needs to join the resident's PPSK network, not the building's management network. A clear, illustrated setup guide reduces support tickets significantly. Let's do a rapid-fire Q and A to cover the questions we hear most often. Question: Do I need a RADIUS server for PPSK? Answer: It depends on scale and vendor. Cisco Meraki's iPSK supports up to 50 keys without RADIUS, but scales to 5,000 with RADIUS via WiFi Personal Network. Aruba MPSK requires RADIUS for dynamic VLAN assignment. For any deployment above 50 units, use RADIUS. Purple provides RADIUS-as-a-Service, so you don't need to run your own. Question: Can residents use PPSK on all their devices, including gaming consoles and smart TVs? Answer: Yes. That's the primary advantage over 802.1X. Any device that supports WPA2-Personal - which is every WiFi device made in the last 15 years - works with PPSK. No certificates, no supplicant configuration, no captive portal. Just a password. Question: What happens when a resident loses their key or gets a new phone? Answer: They request a new key through the resident portal or app. Purple issues a new key, and the old key can optionally be revoked. The new key works on all their devices. This is a self-service flow - no IT involvement required. Question: Is PPSK compliant with GDPR? Answer: PPSK itself is a network access mechanism, not a data collection tool. GDPR compliance depends on what data you collect and how you process it. Purple is GDPR and ISO 27001 certified. Resident WiFi logs should be retained only as long as operationally necessary - six months is a common ceiling. Aggregate analytics are generally fine; individual behaviour tracking inside a resident's unit is not. Question: How does PPSK compare to Passpoint and OpenRoaming? Answer: Different use cases. Passpoint - also known as Hotspot 2.0 - is designed for seamless roaming between venues and carriers. OpenRoaming builds on Passpoint for global roaming. PPSK is for persistent, identity-based access within a single property or estate. They're complementary, not competing. A BTR development might use PPSK for residents and Passpoint for visitor access in common areas. Let me close with the key takeaways. One: PPSK is the right authentication model for multi-tenant residential WiFi. It gives you per-resident isolation, IoT compatibility, and automated lifecycle management - without the certificate infrastructure of 802.1X. Two: the vendor terminology varies - iPSK, MPSK, DPSK, ePSK - but the concept is identical. Choose your hardware based on your building's requirements, and use a hardware-agnostic overlay like Purple to manage the lifecycle across any vendor. Three: plan your VLAN range, mDNS reflection, and IoT onboarding flow before go-live. These are the three most common sources of post-deployment support tickets. Four: PPSK delivers a measurable commercial return. Fifteen to thirty pounds per unit per month in BTR rent premium, five to ten days shorter void periods, and thirty to fifty percent lower per-door cost versus per-unit broadband contracts. Five: WPA3 transition mode is the right target for new deployments in 2025 and beyond. It supports both WPA2 and WPA3 clients, and SAE protection significantly hardens keys against offline attacks. If you want to go deeper, the Purple multi-tenant WiFi guide covers subnet sizing, DHCP range planning, and sector-specific deployment models for BTR, student accommodation, social housing, and coworking. There's also a free iPSK subnet designer tool on the Purple website. Thanks for listening. If you have questions, speak to one of our network architects at purple dot ai. Until next time.