PPSK 12: comparing features and deployment models

Welcome to the Purple technical briefing. Today we're covering PPSK 12 - that's Private Pre-Shared Key with a minimum 12-character key length - 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 with 50, 100, or 300 units, you have a WiFi problem that neither a shared password nor a full enterprise 802.1X deployment solves cleanly. A shared password means every resident is on the same network. One person moves out, you rotate the password, and you've broken every other resident's smart home setup. Full 802.1X is the gold standard for corporate managed devices, but it requires a Public Key Infrastructure, certificate management, and supplicant configuration on every device. Your residents' Chromecasts, smart speakers, and gaming consoles simply cannot do that. PPSK sits precisely between those two extremes. Every resident gets their own unique pre-shared key - a minimum of 12 characters, mixing upper and lower case, numbers, and symbols. All residents connect to the same SSID. From the resident's perspective, it feels exactly like a home WiFi network. From your perspective as the operator, each connection is individually identified, individually encrypted, and individually revocable. Section one: the technical architecture. When a device connects to a PPSK-enabled SSID, the wireless LAN controller intercepts the connection attempt and forwards the device's MAC address to a RADIUS server. RADIUS - Remote Authentication Dial-In User Service - is the authentication engine. The RADIUS server looks up that MAC address in its identity store and returns an Access-Accept response. Embedded in that response is the unique pre-shared key for that resident, plus a VLAN assignment. The controller validates the key the device presented against the key the RADIUS server returned. If they match, the device authenticates and lands on the correct network segment. The result is what we call a per-resident WiFi bubble. Every device on resident A's key sees every other device on resident A's key. Their phone discovers their Chromecast. Their smart speaker pairs with their bulbs. Their console finds their TV. No device on resident A's key sees any device on a different key. Resident B's devices are invisible to resident A, even though they're on the same physical access point. The major vendors each implement this slightly differently. Cisco Meraki calls it iPSK - Identity PSK. HPE Aruba calls it MPSK - Multi-PSK. Ruckus calls it DPSK - Dynamic PSK. Juniper Mist uses PPSK. The underlying principle is identical across all four. The implementation details differ around how RADIUS attributes are structured and how many unique keys a single SSID can support. On key length: the 12-character minimum is not arbitrary. WPA2-PSK keys are derived using PBKDF2 with 4,096 iterations of HMAC-SHA1. A key shorter than 12 characters is vulnerable to offline dictionary attacks, particularly with modern GPU-accelerated cracking tools. At 12 characters with mixed character classes, the keyspace is large enough to make brute-force attacks computationally infeasible. Some platforms, including UniFi, enforce this minimum at the UI level. You should enforce it in your key generation policy regardless of whether the platform requires it. Section two: deployment models. There are three deployment architectures for PPSK, and choosing the right one depends on your property portfolio and your team's capacity. The first is cloud RADIUS. Your access points authenticate against a RADIUS service hosted in the cloud, typically across multiple availability zones. This is the right choice for multi-site portfolios - a BTR operator with properties across several cities, for example. Cloud RADIUS eliminates per-site hardware, automates certificate rotation, and scales elastically. Purple's platform delivers 99.999% uptime on its authentication infrastructure. The trade-off is WAN dependency: if the internet connection at a site drops, new devices cannot authenticate until connectivity is restored. Mitigate this with SD-WAN and local credential caching on the controller. The second is on-premise RADIUS. A RADIUS server - typically Microsoft NPS or FreeRADIUS - runs on hardware or a virtual machine at the property. This gives you sub-millisecond authentication latency, full data sovereignty, and no WAN dependency. It's the right choice for a single large property with strict data residency requirements, or for environments where internet connectivity is unreliable. The operational cost is higher: your team manages patching, certificate rotation, and server health. Certificate expiry is the most common cause of complete authentication outages in on-premise deployments. Build automated certificate renewal into your runbook from day one. The third is hybrid. Cloud RADIUS handles guest and IoT SSIDs. On-premise RADIUS handles any corporate or staff SSID that authenticates against an internal Active Directory. This is a pragmatic model for mixed-use developments - a BTR building with ground-floor retail or coworking space, for example. Purple's platform supports this hybrid model natively, running on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. Section three: key lifecycle management. The technology is the easy part. Key lifecycle management is where deployments succeed or fail operationally. At move-in, a resident's unique key is generated and provisioned automatically - ideally via API integration with your property management system. The resident receives the key through a welcome email or the resident app. All their devices connect using that single key. At move-out, the key is revoked. No other resident is affected. No password rotation. No support tickets. Mid-tenancy, residents add devices. A self-service portal or resident app that issues the resident's existing key to a new device - without exposing that key to other residents - is the correct approach. Purple's platform provides this workflow out of the box. The critical operational risk is MAC address randomisation. iOS 14 and later, Android 10 and later, and Windows 11 all randomise MAC addresses by default for privacy reasons. If a device presents a randomised MAC, your RADIUS server won't find a matching record and will reject the connection. The solution is to configure your SSID to require clients to use their device's permanent MAC address, or to implement a pre-registration workflow. This needs to be in your deployment plan from day one, not discovered during go-live. Section four: WPA3 and the 6 GHz consideration. A word on WPA3, because this is where I see operators make planning errors. PPSK as currently implemented relies on WPA2-PSK's four-way handshake. WPA3 introduces SAE - Simultaneous Authentication of Equals - which changes the handshake mechanism. SAE currently supports only one key per SSID. That means a pure WPA3 SSID cannot support multiple unique pre-shared keys. In the 6 GHz band, introduced with WiFi 6E, WPA3 is mandatory. You cannot run WPA2 in the 6 GHz band at all. So if you're deploying WiFi 6E or WiFi 7 access points and you want to use the 6 GHz band, PPSK is not available there today. The practical recommendation for 2025 and 2026 deployments is a dual-band strategy. Run your PPSK SSID on 2.4 GHz and 5 GHz in WPA2 or WPA2/WPA3 transition mode. Use a separate WPA3-Enterprise SSID on 6 GHz for managed devices that support it. This gives you the per-resident isolation of PPSK for the broad device fleet, and the enhanced security of WPA3 for devices that can use it. Vendors including Cisco Meraki, HPE Aruba, and Juniper Mist are actively working on WPA3-compatible PPSK implementations. Section five: compliance and data privacy. PPSK deployments in residential settings sit in a more sensitive privacy context than guest WiFi. Residents have an ongoing relationship with you, and the data exposure extends over years rather than minutes. Resident isolation is itself a privacy requirement under GDPR. You have a duty of care to prevent one resident from discovering or interacting with another resident's devices. PPSK is the technical mechanism that delivers this. Per-resident VLAN assignment ensures Layer 2 isolation even on shared physical infrastructure. Authentication logs should be retained only as long as required for security and operations. Six months is a common ceiling for residential deployments. Purple stores data in selectable regions, supporting UK, EU, and US data residency requirements. For BTR operators with ground-floor retail or food and beverage tenants, PCI-DSS is relevant. PPSK with per-tenant VLAN assignment allows you to demonstrate that payment processing devices are on a cryptographically isolated segment, even on shared physical infrastructure. That's a meaningful compliance advantage over a shared-password deployment. Section six: rapid-fire questions. How many unique keys can a single SSID support? This is controller-dependent. Cisco Meraki supports up to 5,000 iPSKs per SSID without RADIUS, and effectively unlimited with RADIUS. Ruckus DPSK supports thousands per zone. In practice, the limiting factor is your RADIUS server's database capacity and query performance, not the wireless controller. Does PPSK work with IoT devices? Yes. IoT devices - smart speakers, thermostats, sensors, locks - connect using the resident's key exactly as any other device does. They land in the resident's VLAN and can discover other devices on the same key. This is the primary reason PPSK is the correct architecture for BTR and MDU deployments, where 15 to 25 devices per household is now the norm. What's the business case? A managed WiFi amenity with per-resident isolation commands a rent premium of £15 to £30 per unit per month in BTR research from the British Property Federation. Void periods reduce by five to ten days when move-in WiFi is ready on day one. Support ticket volume for Chromecast and smart home issues drops to near zero when PPSK is correctly deployed. Summary and next steps. PPSK with a 12-character minimum key length is the correct WiFi authentication architecture for BTR, MDU, student accommodation, and social housing deployments. It delivers per-resident isolation, full IoT support, and automated key lifecycle management without the infrastructure overhead of 802.1X. Choose cloud RADIUS for multi-site portfolios. Choose on-premise RADIUS for single large properties with data sovereignty requirements. Use a hybrid model for mixed-use developments. Plan for MAC address randomisation from day one. Build a dual-band strategy for WiFi 6E and WiFi 7 deployments while WPA3-compatible PPSK implementations mature. The three things to do this quarter: audit your current authentication model against these criteria, assess your RADIUS infrastructure, and define your key lifecycle management workflow, including integration with your property management system. Purple's Multi-Tenant WiFi platform runs on the access points you already own, across 80,000 live venues, and delivers 99.999% uptime on its authentication infrastructure. Thank you for joining this Purple technical briefing.