Ppsk-kiosk: comparing features and deployment models

Welcome to the Purple Technical Briefing. Today we're covering PPSK-kiosk deployments - what they are, how they compare to the alternatives, and where they actually make sense to deploy. Let's start with the problem. In a traditional WPA2 Personal network, every device shares the same password. That's fine at home. It's a liability in a 200-unit Build to Rent development, a hotel with 300 rooms, or a conference centre running back-to-back events. When one resident moves out or a guest checks out, you either change the password for everyone - breaking every other device in the building - or you leave the old credential active. 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 sit on VLAN 99. The access point handles the key-to-VLAN mapping automatically. No RADIUS server required. No certificate infrastructure. No 802.1X supplicant on the device. Now, the kiosk element is where this gets operationally interesting for property developers and venue operators. A PPSK-kiosk is a self-service terminal - typically a tablet in a fixed stand - placed in a lobby, reception, or common area. A visitor or new resident walks up, enters their name or scans a QR code, and the kiosk generates and issues a unique PPSK on the spot. The key is tied to their identity record, has a defined expiry, and maps to the correct VLAN for their access tier. No front-desk staff involved. No IT ticket. No shared password written on a whiteboard. Let's talk about the terminology, because it varies by vendor and that causes genuine confusion. Aruba calls it PPSK - Private Pre-Shared Key. Cisco Meraki calls it iPSK - Identity PSK. 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 is 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 has 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, 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 deployment models in production today. The first is the cloud-controller model. 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 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. 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 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 straightforward. 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. Let me give you two real-world scenarios that illustrate this in practice. Scenario one: a 180-unit Build to Rent development in a city centre. The operator wanted WiFi included in rent as an amenity, with move-in-day activation and full smart home support. They deployed HPE Aruba access points managed through Aruba Central. Each flat gets a unique PPSK key generated at tenancy sign-up. The key is emailed to the resident with a QR code. They scan it, all their devices connect, and their Chromecast, smart speaker, and console all work immediately. When a resident moves out, the property manager deletes the key in the portal. The new resident gets a fresh key at move-in. The operator reported a 30% reduction in WiFi-related support tickets compared to their previous shared-password deployment. Scenario two: a 400-bed purpose-built student accommodation block. The challenge here is cohort move-in week, with hundreds of students arriving simultaneously, all trying to connect dozens of devices at once. The operator used Ruckus access points with SmartZone, deploying PPSK with one key per room. Keys were pre-generated and included in the welcome pack sent before arrival. Students scanned the QR code on arrival and were connected within seconds. The network handled the move-in surge without degradation because each student's traffic was isolated to their own VLAN segment. 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 platform sits as a cloud overlay and handles the API calls to the underlying hardware, so your property management system talks to one endpoint regardless of which access point vendor you're running. What about GDPR compliance? PPSK key generation collects identity data - name, email, unit number. That data needs a lawful basis under UK GDPR, a clear retention policy, and secure storage. Purple stores data in EU, UK, or US regions at your choice, with configurable retention periods and consent capture built into the onboarding flow. To summarise, PPSK-kiosk is the right architecture when you need per-user or per-household WiFi isolation, IoT device support, and self-service onboarding at scale. It runs on hardware you likely already own - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet. It does not replace 802.1X for staff networks where individual audit trails matter. And the kiosk element - the self-service terminal - is what makes it operationally viable at the scale of a 200-unit BTR development or a 500-delegate conference. If you're planning a deployment and want to talk through the architecture, Purple's team works across 80,000 venues and can map the right model to your specific property type. The link is in the guide. Thanks for listening.