PPSK umpsa: comparing features and deployment models

[0:00 - 1:00] Introduction & Context Welcome to the Purple Technical Briefing. Today we're covering PPSK - Private Pre-Shared Key - specifically in the context of multi-tenant residential and mixed-use deployments. If you're a property developer, a build-to-rent operator, or managing a student accommodation portfolio, this is directly relevant to decisions you'll be making this year. Let's start with the basics, because the terminology here is genuinely confusing. PPSK goes by several names depending on which vendor you're talking to. Aruba calls it PPSK. Cisco Meraki calls it Personal Private Network. Extreme Networks uses the term Private PSK. Juniper Mist and Cambium use ePSK. Ubiquiti UniFi calls it Private Pre-Shared Keys. They all describe the same concept: instead of every user sharing a single password, each user or group gets their own unique credential. [1:00 - 6:00] Technical Deep-Dive Now, why does that matter? Think about a traditional shared password on a building WiFi. Every resident uses the same key. When someone moves out, you have two choices: either you leave their access active, which is a security problem, or you change the password for everyone, which breaks every other resident's devices until they reconnect. Neither option is acceptable at scale. PPSK eliminates that problem entirely. You revoke one key, one resident loses access. Everyone else is completely unaffected. There are three distinct deployment models worth understanding here, and choosing the wrong one for your context will cost you operationally. The first is standard shared PSK - the traditional single password for everyone. It's the simplest to set up and fine for a home network. In a multi-tenant building, it's essentially unusable at any meaningful scale. One leaked password compromises the entire network. No VLAN isolation between residents. No individual revocation. Avoid it. The second model is group-level PPSK. Here, you assign a unique password to each group - perhaps each floor, each department in an office building, or each property in a portfolio. This gives you group-level VLAN segmentation and group-level revocation. It works well for events, conferences, and office environments where you want departmental separation without per-user complexity. The operational overhead is low, and you don't necessarily need a RADIUS server - many access points handle group PPSK natively. The third model - and the one we recommend for BTR, student accommodation, and any residential deployment - is per-user iPSK. Identity Pre-Shared Key. Every single resident gets their own unique credential. Their devices all use that one credential, which places them in their own private VLAN - their own WiFi bubble. Their phone sees their smart TV, their laptop sees their Chromecast, their smart speaker pairs with their lights. But they cannot see any other resident's devices, even though they're all on the same physical access point and the same SSID. This is the architecture that makes managed WiFi genuinely work as a residential amenity. The resident experience is identical to having their own home broadband router. The operator retains full control of the infrastructure. Let me walk you through the technical architecture, because understanding this helps you ask the right questions of vendors and integrators. In a PPSK deployment without RADIUS, the access point itself holds a local database of keys and their associated VLAN assignments. When a device connects, the AP looks up the key, identifies which VLAN it maps to, and places the device there. This works well for smaller deployments - up to a few hundred keys on most enterprise access points. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet all support some variant of this. For larger deployments - a two-hundred-unit BTR building, a thousand-bed student accommodation block - you want PPSK backed by a RADIUS server. The access point forwards the credential to the RADIUS server, which validates it against a directory, returns the appropriate VLAN assignment, and the AP places the device accordingly. This scales to tens of thousands of keys, integrates with identity providers like Microsoft Entra ID, Okta, or Google Workspace, and gives you centralised audit logging - which matters for GDPR compliance. Speaking of compliance - this is an area where the choice of deployment model has real legal implications. Under GDPR, you have an obligation to protect resident data. If resident A can see resident B's network traffic, that's a data protection issue. Per-user VLAN isolation, delivered through iPSK, is the technical mechanism that satisfies that obligation. It's not just a nice-to-have; it's a compliance requirement in any residential context where you're processing personal data. PCI DSS is relevant if you have any payment processing on the same network infrastructure - a retail element in a mixed-use development, for example. VLAN segmentation isolates payment traffic from residential traffic, which is a core PCI DSS requirement. IEEE 802.1X is the underlying standard for port-based network access control, and while full 802.1X with EAP-TLS and certificates is the gold standard for enterprise security, PPSK with RADIUS is a pragmatic middle ground that delivers most of the security benefits with significantly lower deployment complexity. [6:00 - 8:00] Implementation Recommendations & Pitfalls Now let me give you two concrete scenarios, because the theory only goes so far. Scenario one: a two-hundred-and-fifty-unit build-to-rent tower in a city centre. The developer wants WiFi included in the monthly rent as a premium amenity. Residents expect their smart home devices to work - Sonos, Philips Hue, Amazon Echo, smart TVs, games consoles. They expect to be able to add new devices without calling a helpdesk. And they expect their neighbour not to be able to see their network traffic. The right architecture here is a single SSID across the building, backed by iPSK with RADIUS. Each resident gets a unique key at move-in - delivered via a resident app or a QR code in their welcome pack. All their devices use that key. The RADIUS server maps the key to a dedicated VLAN per unit. When they move out, the key is revoked in the management platform. The next resident gets a new key. No password changes, no disruption to other residents. The hardware runs on whatever access points are already specified - Cisco Meraki, HPE Aruba, Ruckus, or Ubiquiti UniFi are all common in this sector. Purple's platform sits as a cloud overlay, managing the key lifecycle, VLAN assignments, and resident onboarding without requiring a forklift upgrade of the physical infrastructure. Scenario two: a mixed-use development with ground-floor retail, a coworking space on floors two and three, and residential from floor four upwards. You have three distinct user populations with completely different network requirements. Retail needs PCI-compliant payment isolation. Coworking members need business-grade reliability and VPN compatibility. Residents need the home network experience we just described. Here, you'd typically run three SSIDs - one per population - or use a single SSID with PPSK and role-based VLAN assignment to separate the three groups. The three-SSID approach is cleaner operationally and maps more naturally to the different onboarding flows. Retail staff use 802.1X with corporate credentials. Coworking members get group-level PPSK per company. Residents get per-unit iPSK. All three populations share the same physical access point infrastructure, but their traffic never intersects. Let me cover the most common implementation pitfalls, because I see the same mistakes repeatedly. The first is underestimating device density. A two-hundred-unit building doesn't have two hundred devices on the WiFi. It has three thousand to five thousand. Fifteen to twenty-five devices per household is the current average, and that number grows every year as smart home adoption increases. Your DHCP scope, your VLAN subnet sizing, and your access point capacity planning all need to account for this. The second pitfall is choosing PPSK without RADIUS for a large deployment to save cost, then discovering the access point's local key database has a hard limit. For anything above one hundred units, budget for a RADIUS server from the start. Cloud-hosted RADIUS services eliminate the on-premises infrastructure burden. The third pitfall is neglecting the two-point-four gigahertz band. You want to steer residents to five gigahertz and six gigahertz for performance. But IoT devices - smart plugs, older sensors, some smart speakers - often only support two-point-four gigahertz. Your PPSK configuration needs to handle both bands. The fourth pitfall is the move-out workflow. PPSK only delivers its operational benefits if the key revocation process is actually executed at move-out. If your property management system doesn't integrate with your network management platform, keys accumulate. Automate the revocation workflow through an integration between your tenancy management system and your WiFi management platform. [8:00 - 9:00] Rapid-Fire Q&A Now, a few rapid-fire questions I get asked regularly. Do I need to replace my existing access points to deploy PPSK? In most cases, no. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet all support PPSK or iPSK variants on current firmware. Is PPSK as secure as 802.1X with certificates? No. Full 802.1X with EAP-TLS and digital certificates is more secure. But for residential deployments where you're onboarding non-technical residents with consumer devices, PPSK with RADIUS is the pragmatic choice that delivers adequate security with manageable operational complexity. What about WPA3? PPSK can run over WPA3-Personal, and you should enable it where your access point hardware supports it. Running a transition mode that supports both WPA2 and WPA3 clients on the same SSID is the standard approach during the transition period. [9:00 - 10:00] Summary & Next Steps To wrap up: the decision framework is straightforward. If you're deploying WiFi in a multi-tenant residential context - BTR, student accommodation, social housing - you want per-user iPSK with RADIUS. If you're deploying for events, conferences, or office departmental segmentation, group-level PPSK without RADIUS is often sufficient. If you're still on a single shared password for a multi-tenant building, that needs to change this year. The operational benefits are measurable. A managed BTR deployment with iPSK typically sees support ticket volumes drop by over ninety percent compared to unmanaged or shared-PSK deployments. Move-out credential management drops from a disruptive building-wide event to a single database entry. Thanks for listening to the Purple Technical Briefing. If you want to go deeper on the architecture, visit purple dot ai. If you have questions about your specific deployment, speak to one of our network architects.