PPSK WiFi: comparing features and deployment models

Welcome to the Purple Technical Briefing. Today we're covering PPSK WiFi - Private Pre-Shared Key - what it is, how it compares to the alternatives, and where it actually makes sense to deploy it. [medium pause] Let's start with the problem it solves. In a traditional WPA2 Personal network, every device on the network 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 console in the process - or you leave the old resident with access. Neither option is acceptable. [short pause] 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. No certificate infrastructure. No 802.1X supplicant on the device. [medium pause] 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. [short pause] 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. [medium pause] 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. [short pause] 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. [medium pause] Let's look at the deployment models. There are three primary patterns in production today. [short pause] 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. [short pause] 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. It's the right model for mixed environments - say, a coworking space where you have both managed corporate devices and member-owned IoT equipment. [short pause] 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. [short pause] 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: VLAN 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. [short pause] Then document your IP addressing scheme. In a 200-unit building, you're looking at 3,000 to 5,000 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. [medium pause] 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. [short pause] One critical constraint to flag: UniFi's PPSK implementation is WPA2 only. If you're specifying Wi-Fi 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. [medium pause] Now let's talk about the pitfalls. These are the failure modes I see repeatedly in production deployments. [short pause] 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. [short pause] 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. [short pause] 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. [short pause] The fourth pitfall, specific to IoT, is putting smart home devices on the resident's PPSK segment without thinking through the implications. A compromised IoT device on a resident's VLAN can potentially attack other devices on that same VLAN. For high-risk IoT categories, consider a separate IoT VLAN with egress filtering, even if it means residents need to configure their smart home apps to use a different network. [medium pause] Let's look at two real-world scenarios. [short pause] 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. Zero password rotation drama. The operator reports a 30% reduction in WiFi-related support tickets compared to their previous shared-password deployment. [short pause] 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. [medium pause] Now for a rapid-fire Q and A on the questions that come up most often. [short pause] 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. [short pause] 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. [short pause] 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. You can automate key creation and revocation as part of your tenancy management workflow. [short pause] What's the security difference between PPSK and 802.1X? The fundamental difference is that PPSK is a shared-secret model. The key is a string of characters that can be shared or intercepted. 802.1X with EAP-TLS uses digital certificates, which cannot be shared in the same way and provide mutual authentication. For residential environments where the threat model is primarily inter-resident isolation, PPSK provides adequate security. For corporate staff networks, 802.1X is the correct choice. [medium pause] To bring this together: PPSK WiFi is the right authentication model for multi-tenant residential deployments, IoT-heavy environments, and any scenario where you need per-user or per-household isolation without the infrastructure overhead of 802.1X. It runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. It integrates with property management systems via API. And it solves the three core operational problems that shared-password networks cannot: move-out without breaking everyone, smart home device support, and per-resident accountability. [short pause] The decision framework is straightforward. If your devices support 802.1X and you have RADIUS infrastructure, use 802.1X for staff and managed devices. If you're running a multi-tenant residential property, use PPSK. If you have IoT devices that can't do 802.1X, use PPSK with a dedicated IoT VLAN. If you need guest WiFi in common areas, use a standard PSK or open network with a captive portal on top. [short pause] For next steps: review the architecture overview diagram in the guide, which shows the full PPSK deployment stack from ISP uplink to resident device. Use the decision flowchart to map your specific environment to the right authentication model. And if you're planning a BTR or MDU deployment and want to understand how Purple's Multi-Tenant WiFi platform sits on top of your existing hardware to provide the key management, resident portal, and analytics layer, the link is in the guide. [medium pause] That's it for today's briefing. Thanks for listening. Let me go deeper on the security model, because this is where I see the most confusion in the market. [short pause] PPSK operates at the WPA Personal layer. Each key is a pre-shared secret. The security guarantee PPSK provides is inter-resident isolation - device A on key A cannot communicate with device B on key B, even when they're associated to the same physical access point. That isolation is enforced at the VLAN layer, not at the encryption layer. The encryption between each device and the access point uses the same WPA2 or WPA3 cipher suite regardless of which PPSK key the device used to authenticate. [short pause] What PPSK does not provide is the mutual authentication that 802.1X delivers. In an 802.1X deployment with EAP-TLS, the client authenticates to the network and the network authenticates to the client. Both sides present certificates. This prevents rogue access point attacks. With PPSK, the client has no way to verify it's connected to the legitimate network rather than a rogue AP broadcasting the same SSID. For a residential building where the threat model is primarily about isolating residents from each other, this is an acceptable trade-off. For a corporate environment handling sensitive data, it is not. [medium pause] Now let's talk about the WPA3 upgrade path. WPA3-SAE, which stands for Simultaneous Authentication of Equals, replaces the WPA2 four-way handshake with a more secure key exchange protocol called Dragonfly. The critical improvement for PPSK deployments is forward secrecy: even if an attacker captures the WiFi traffic and later obtains the pre-shared key, they cannot decrypt the captured traffic. WPA2-PSK does not provide forward secrecy. WPA3-SAE does. If you're deploying new hardware today, specify WPA3-SAE support and enable it for your PPSK SSID. Clients that don't support WPA3 will fall back to WPA2 in transition mode, so you don't need to force a hard cutover. [short pause] The GDPR angle is worth addressing directly. In a multi-tenant residential deployment, you're processing personal data - specifically, the association between a WiFi key and a named resident. That association is personal data under the UK GDPR and the EU GDPR. You need a lawful basis for processing it. In a BTR context, the lawful basis is typically the performance of a contract - the tenancy agreement - or legitimate interests. You need a privacy notice that covers WiFi data processing. You need a data retention policy for connection logs. And you need to be able to respond to subject access requests, which means your PPSK management platform needs to be able to export all data associated with a specific resident's key. [short pause] Purple's Multi-Tenant WiFi platform is built with this in mind. Data is stored in ISO 27001 certified infrastructure. We're GDPR and CCPA compliant. Data residency is selectable - UK, EU, or US - so you can meet your regulatory obligations regardless of where your properties are located. And our platform provides the audit trail and data export capabilities you need for compliance. Let me address the ROI question, because this comes up in every BTR procurement conversation. [short pause] The British Property Federation's research consistently shows WiFi quality as a top-five amenity factor in Build to Rent leasing decisions. Operators who include managed WiFi as an amenity report rent premiums of fifteen to thirty pounds per unit per month compared to equivalent properties without included connectivity. On a 200-unit building, that's between thirty-six thousand and seventy-two thousand pounds per year in additional rental income. Against a typical PPSK deployment cost - hardware amortised over five years plus a software overlay licence - the payback period is typically under 18 months. [short pause] The operational savings are equally significant. A shared-password network in a 200-unit building generates a predictable volume of support tickets: residents who can't connect their Chromecast, residents whose smart speaker won't pair, residents whose console shows NAT type strict. These tickets cost time and money to resolve. A correctly deployed PPSK network eliminates the majority of them. One operator we work with reported a 30% reduction in WiFi-related support contacts in the first six months after migrating from a shared-password to a PPSK deployment. [short pause] Void periods are the other lever. A building where WiFi is active and working on move-in day reduces friction for new residents. A building where a new resident has to wait for a broadband engineer appointment - typically seven to fourteen days in the UK - creates a negative first impression that affects retention. PPSK with move-in-day activation removes that friction entirely. [medium pause] One more area to cover: the coworking and mixed-use application. PPSK isn't only for residential. It's also the right model for coworking spaces where you want per-member or per-company isolation without the overhead of 802.1X. A coworking operator with 200 members can give each member their own PPSK key, map it to a dedicated VLAN, and ensure that member A's devices are invisible to member B. When a membership lapses, the key is revoked. When a new member joins, a new key is generated. The member experience is identical to a home network. [short pause] For coworking, the hybrid model works particularly well. Members get PPSK. Visitors to members - clients attending meetings, for example - get a separate guest WiFi SSID with a captive portal. Building staff get 802.1X against the operator's identity provider. Three authentication models, one physical infrastructure, clean separation between all three user groups. [medium pause] That covers the full picture. PPSK WiFi is a mature, well-supported technology that solves a specific and important problem: per-user or per-household isolation in multi-tenant environments, without the infrastructure overhead of 802.1X. It's hardware-agnostic, API-driven, and deployable today on the access points you already own. The decision criteria are clear. The deployment patterns are proven. And the business case, particularly in Build to Rent and purpose-built student accommodation, is well-evidenced.