Uu PPSK pdf: comparing features and deployment models

Welcome to the Purple Technical Briefing. Today we're covering PPSK - Private Pre-Shared Key WiFi - what it is, how it compares to the alternatives, and where it actually makes sense to deploy it in a multi-tenant residential or commercial property. Let's start with the problem it solves. In a standard WPA2 Personal network, every device shares the same password. That's fine for a home. It's a liability for a 200-unit build-to-rent development, a student accommodation block, or a hotel with 300 rooms. When one resident moves out, you either change the password for everyone - breaking every other resident's smart TV, thermostat, and games console in the process - or you leave the old resident with access. Neither option is acceptable. PPSK solves this by giving each resident, each flat, or each device group its own unique WiFi key. They all connect to the same SSID - the same network name - but each key maps to a separate VLAN. Flat 12 is on VLAN 10. Flat 13 is on VLAN 20. The IoT devices are on VLAN 99. The access point handles the key-to-VLAN mapping automatically. No RADIUS server required for the basic model. No certificate infrastructure. No 802.1X supplicant on the device. Now let's talk about the terminology, because it varies by vendor and that causes genuine confusion in the market. Aruba calls it PPSK - Private Pre-Shared Key. Cisco Meraki calls it iPSK - Identity PSK, or Personal Private Network. Juniper Mist uses ePSK. Extreme Networks, who originally developed the concept under the Aerohive brand, call it Private PSK. Ubiquiti UniFi simply calls it PPSK. Cambium also uses ePSK. The underlying mechanism is identical across all of them: one SSID, multiple unique keys, each key tied to a VLAN or a policy group. Technically, here's what happens at the association layer. When a device connects, it presents its pre-shared key during the WPA2 four-way handshake. The access point - or the cloud controller behind it - looks up that key in the PPSK store, identifies which VLAN it maps to, and tags the device's traffic accordingly from that point forward. The device sees a normal WiFi connection. It has no idea it's been placed in an isolated segment. Its Chromecast works. Its smart speaker pairs. Its console gets the right NAT type. Everything behaves like a home network - because from the device's perspective, it is. This is the key distinction from 802.1X, which is the enterprise standard for staff networks and corporate environments. 802.1X requires a RADIUS server, an identity provider - Microsoft Entra ID, Okta, or Google Workspace - and a supplicant on every device. That supplicant is the software component that handles the EAP authentication exchange. Every managed laptop, every corporate phone, has one. Your resident's smart fridge does not. Your building's HVAC controller does not. Your IoT sensors do not. PPSK works with all of them because it operates at the WPA Personal layer, not the WPA Enterprise layer. That said, PPSK is not a replacement for 802.1X in corporate environments. It's a different tool for a different problem. If you're running a staff network where individual accountability matters - where you need to know that a specific person authenticated at a specific time, and you need to revoke their access the moment they leave the organisation - 802.1X is the right answer. If you're running a residential network where you need per-household isolation, IoT support, and operational simplicity at scale, PPSK is the right answer. Let's look at the three primary deployment models in production today. The first is the cloud-controller model, which is the most common for new deployments. Your access points - whether that's Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet - connect to a cloud management platform. The PPSK key store lives in the cloud controller. When you provision a new resident, you create a key in the portal, assign it to a VLAN, and the controller pushes the policy to every access point in the building. The resident gets their key - via email, SMS, or a QR code in a welcome pack - and connects. When they move out, you delete the key. Their devices stop connecting. Nobody else is affected. The second deployment model is PPSK with a local RADIUS backend. Some enterprise deployments use a RADIUS server to store and validate PPSK credentials, which gives you centralised logging, audit trails, and integration with your identity management platform. This adds infrastructure overhead but gives you the accountability of 802.1X with the device compatibility of PPSK. It's the right model for mixed environments - say, a coworking space where you have both managed corporate devices and member-owned IoT equipment. The third model is hybrid: PPSK for residents and IoT, 802.1X for staff and management systems. This is the architecture Purple recommends for build-to-rent and multi-dwelling unit deployments. Residents get PPSK. Building management systems, CCTV, and access control get their own IoT VLAN with PPSK. The property management team's devices use 802.1X against Microsoft Entra ID or Okta. Three distinct authentication models, three distinct VLANs, one physical infrastructure. Now let's get into implementation. If you're deploying PPSK for a build-to-rent development or a multi-dwelling unit property, here's the sequence that works. Start with your logical design before you touch hardware. Map out your resident count, your IoT device categories, and any staff or management systems. Assign VLANs. A typical BTR deployment looks like this: VLANs 10 through to whatever your unit count requires for residents - one VLAN per flat or one VLAN per floor depending on your density. VLAN 99 for IoT. VLAN 100 for building management. VLAN 200 for guest WiFi in common areas. Then document your IP addressing scheme. In a 200-unit building, you're looking at three thousand to five thousand devices on the network at any given time. That's the 15 to 25 devices per household figure from British Property Federation research. Your DHCP scopes need to accommodate that. Use RFC 1918 private addressing with sufficient subnet sizes per VLAN. A slash 24 gives you 254 usable addresses. A slash 23 gives you 510. Size accordingly. On hardware selection: PPSK is supported across all major enterprise access point platforms. Cisco Meraki calls it iPSK and manages it through the Meraki dashboard with per-SSID key policies. HPE Aruba implements it natively in ArubaOS and Aruba Central. Ruckus supports it through SmartZone and the Ruckus Cloud platform. Juniper Mist uses ePSK with AI-driven RF management. Ubiquiti UniFi has had PPSK since 2023, though note it's currently WPA2 only and won't work on the 6 gigahertz band. Cambium and Extreme both support it through their respective cloud platforms. One critical constraint to flag: UniFi's PPSK implementation is WPA2 only. If you're specifying WiFi 6E access points and want to use the 6 gigahertz band for PPSK clients, you'll need a platform that supports WPA3-SAE with PPSK, or you'll need to restrict PPSK clients to the 2.4 and 5 gigahertz bands. Aruba, Ruckus, and Meraki all support PPSK on WPA3 configurations. Now let's talk about the pitfalls. These are the failure modes I see repeatedly in production deployments. The first is SSID proliferation. Every SSID you broadcast consumes airtime for beacon frames. In a dense residential building, if you're broadcasting six or eight SSIDs per access point, you're degrading performance for everyone. Keep it to a maximum of four SSIDs per radio. Use PPSK to serve multiple resident segments from a single SSID rather than creating a separate SSID per flat or per floor. The second pitfall is insufficient trunk port configuration. You design a clean VLAN scheme, you deploy the access points, and then traffic silently drops because someone forgot to permit the relevant VLANs on a trunk link between the distribution switch and the access layer. Validate every trunk port during commissioning. Document it. Test it with a device on each VLAN before residents move in. The third pitfall is key distribution. Generating keys is easy. Getting them to residents in a way that's secure and operationally manageable is harder. A QR code in the welcome pack works well for move-in day. A resident portal where they can retrieve their key and add new devices is better for ongoing operations. Build the key distribution workflow before you deploy, not after. Now for a rapid-fire Q and A on the questions that come up most often. How many PPSK keys can a single access point handle? Most enterprise platforms support thousands of keys per SSID. Cisco Meraki supports up to 5,000 iPSK entries per network. Aruba supports similar scale. Ubiquiti UniFi supports up to 1,000 PPSK entries per network. For a 200-unit building, you're well within limits on any platform. Does PPSK work with WPA3? Yes, on most enterprise platforms. WPA3-SAE provides stronger protection against offline dictionary attacks compared to WPA2-PSK, so deploying PPSK on WPA3 where your client devices support it is the right approach. The exception is UniFi, which is currently WPA2 only for PPSK. Can I integrate PPSK with my property management system? Yes, through the vendor's API. Aruba Central, Meraki, Ruckus, and Mist all expose REST APIs for PPSK key management. Purple's Multi-Tenant WiFi platform sits on top of these APIs and provides a single management layer across all hardware vendors, with webhooks to trigger key provisioning and revocation from your property management system automatically. What about GDPR? PPSK keys are credentials, not personal data in themselves. However, if you link a key to a named resident - which you will, for operational reasons - that linkage is personal data under UK GDPR. Store it securely, retain it only as long as needed, and ensure your data processing agreement with your WiFi platform provider covers this. Purple is ISO 27001 certified, GDPR compliant, and Cyber Essentials certified. Let's close with the key takeaways. First: PPSK is the right authentication model for multi-tenant residential environments. It gives you per-household isolation, IoT compatibility, and operational simplicity that standard PSK and 802.1X cannot match simultaneously. Second: the terminology varies by vendor - PPSK, iPSK, ePSK, Personal Private Network - but the mechanism is the same. Don't let the naming confusion delay your procurement decision. Third: design your VLAN scheme before you touch hardware. The logical design is the hard part. The physical deployment follows from it. Fourth: keep your SSID count below four per radio. Use PPSK to consolidate segments onto a single SSID rather than proliferating network names. Fifth: build your key distribution workflow before go-live. Move-in day is not the time to discover your onboarding process has gaps. If you want to go deeper on any of this - hardware selection, VLAN design for a specific property, or integrating PPSK with your property management system - the Purple Multi-Tenant WiFi team can walk you through it. You'll find the full written guide and architecture diagrams at purple.ai. Thanks for listening.