Parkside plasma cutter PPSK 40 b2: comparing features and deployment models

Welcome to the Purple Technical Briefing. Today we're talking about something that property developers, BTR operators, and landlords often get wrong at the design stage - and it costs them dearly once residents move in. We're covering PPSK - Private Pre-Shared Key - specifically the architecture known as PPSK 40 B2, which refers to a 40-character key length with the B2 deployment profile. We'll compare the three main deployment models, walk through the authentication architecture, and give you a clear framework for making the right decision for your building. Whether you're specifying a new development or retrofitting an existing one, this briefing will save you time and money. Let's start with the problem. If you're managing a multi-tenant building - a build-to-rent block, a student accommodation development, an MDU - you have a fundamental tension in your network design. Every resident needs a private, home-like WiFi experience. Their Chromecast needs to find their phone. Their smart speaker needs to talk to their bulbs. Their work laptop needs to stay off the same network segment as their neighbour's devices. But you're sharing physical infrastructure. One set of access points, one uplink, one building-wide network. How do you give 200 residents 200 private networks without running 200 separate SSIDs? The answer is PPSK - and specifically, the unique per-user variant that we call UU PPSK. But before we get there, let me walk you through the three models you'll encounter, because understanding the differences is the whole point of this briefing. Model one: shared PSK. One password, everyone on the same network. This is what most buildings still run today. It's simple to deploy, but it's a single point of failure. One resident posts the password on a forum, and you've lost control of your network. You want to remove a contractor's access? You have to change the password for everyone. At scale, this is simply not manageable. And from a GDPR perspective, it's a compliance gap - you cannot attribute network activity to a specific resident when every device looks identical from the RADIUS server's perspective. Model two: Group PPSK. Here, you assign a unique key to each group of users - perhaps one key per floor, or one key per tenancy type. It's better than a shared password, but it still has what I call a blast radius problem. If one key in a group is compromised, the entire group is affected. And you still can't isolate individual residents from each other at the network layer. Group PPSK is a reasonable interim step for smaller deployments, but it doesn't scale. Model three: UU PPSK. Unique per-User Pre-Shared Key. Every single resident, every single device group, gets its own cryptographically unique key. And that key maps to its own VLAN - its own network segment, completely isolated from every other resident in the building. This is the architecture that delivers what I call the WiFi bubble. Resident A's devices can see each other - they can cast, they can pair, they can share files, exactly as they would on a home network. But Resident A cannot see a single device belonging to Resident B, even though they're both connected to the same access point, on the same SSID, using the same physical cable infrastructure. Now let me walk you through the technical authentication flow, because this is where the architecture earns its keep. When a resident's device connects to the SSID, the Wireless LAN Controller intercepts the connection attempt and forwards the device's MAC address to a RADIUS server. The RADIUS server - which can be cloud-hosted, as Purple's is - looks up that MAC address in its identity store. It returns an Access-Accept response containing the unique pre-shared key assigned to that resident. The controller validates the key the device presented against the returned key. If they match, the device is authenticated and placed on the resident's dedicated VLAN. Critically, that RADIUS response also carries the VLAN assignment. So the device doesn't just get authenticated - it gets automatically placed on the correct network segment, with the correct bandwidth policy, the correct firewall rules, all from a single SSID. No SSID proliferation. No beacon overhead. One network name, hundreds of isolated private networks underneath it. Now, the PPSK 40 B2 designation is worth unpacking. The 40 refers to the minimum key length - 40 characters. This matters because shorter keys are vulnerable to offline dictionary attacks. A 40-character key generated from a cryptographically random source has an entropy level that makes brute-force attacks computationally infeasible with current hardware. The B2 profile refers to the deployment model: RADIUS-backed PPSK with cloud orchestration, as opposed to B1 which is controller-local storage. B2 is the profile you want for any deployment above 50 units. Let me now cover the three deployment models in practical terms. The first is controller-local PPSK. Here, the unique keys are stored directly on the wireless controller, with no external RADIUS server required. This works well for smaller deployments - up to around 200 units - and it's the simplest to operate. Ubiquiti UniFi supports this natively. The limitation is scalability. Most controllers cap out at a few hundred local PPSK entries, and you lose the centralised lifecycle management that makes UU PPSK operationally viable at scale. The second model is RADIUS-backed PPSK. Here, the keys are stored in an external RADIUS server, and the controller queries the RADIUS server for every new connection. This scales to thousands of units. The operational overhead is higher, but the scalability and the lifecycle management capabilities are significantly better. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist - all support this model. The third model - and the one Purple recommends for BTR and MDU operators - is cloud RADIUS-as-a-Service. Here, the RADIUS infrastructure is hosted and managed by Purple, and you connect your access points to it via a cloud overlay. This gives you the scalability of RADIUS-backed PPSK without the operational overhead of running your own RADIUS server. Purple's platform sits on top of your existing hardware - whether that's Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet - and provides the orchestration layer for key provisioning, lifecycle management, and resident onboarding. Let me give you two concrete deployment scenarios. The first is a 250-unit Build to Rent development. The developer had specified Cisco Meraki access points throughout the building. They needed each resident to have a private WiFi experience with full IoT support, same-day move-in readiness, and the ability to support 15 to 25 devices per household. The average BTR household now connects 18 devices to WiFi - from phones and laptops to smart speakers, streaming sticks, and connected appliances. The architecture deployed was a single SSID across the building, with UU PPSK via Purple's cloud RADIUS service. Each resident received a unique key at move-in, delivered via the resident app. The key mapped to a dedicated VLAN with a private subnet, giving each household a fully isolated network segment. mDNS reflection was enabled within each VLAN, so Chromecast, Apple TV, and Sonos all worked as expected. The building went live with 250 active resident VLANs on day one, with zero manual RADIUS configuration required by the on-site team. The second scenario is a 400-bed purpose-built student accommodation block. The challenge here is the annual cohort turnover. Every August, 400 students move out and 400 new students move in, often within the same week. With a shared PSK model, that means a building-wide password rotation affecting every returning resident. With UU PPSK, it means revoking 400 keys and provisioning 400 new ones - all automated via the student management system integration. The operations team reported a 70% reduction in WiFi-related support tickets in the first term, primarily because the Chromecast and smart TV pairing issues that had plagued the previous shared PSK deployment were completely eliminated. Now let me cover the implementation pitfalls, because there are three that catch most deployments out. Pitfall one: MAC address randomisation. Since iOS 14, Android 10, and Windows 11, devices use randomised MAC addresses by default for privacy reasons. If your RADIUS server is doing a MAC lookup and the device presents a randomised address, the lookup fails and the device can't connect. The solution is to configure your SSID to request that clients use their permanent hardware MAC address, or to implement a pre-registration workflow where residents register their device before connecting. Purple's platform handles this automatically as part of the resident onboarding flow. Pitfall two: mDNS isolation. By default, mDNS - which is the protocol that Chromecast, AirPlay, and Sonos use to discover devices - does not cross VLAN boundaries. If you isolate residents into separate VLANs without enabling mDNS reflection, their smart devices won't work. Make sure your controller or your cloud overlay supports per-VLAN mDNS reflection before you commit to the architecture. Pitfall three: key lifecycle management. The operational value of UU PPSK over a shared PSK is entirely dependent on keys being provisioned and revoked automatically. Manual key management at scale is not viable. Integrate with your property management system or student management system from the outset. If you're using Purple's platform, this integration is available out of the box. Three rules of thumb before we close. Rule one: if your building has more than 50 units, use RADIUS-backed UU PPSK, not controller-local PPSK. The scalability ceiling of controller-local PPSK will cause you problems within 12 months of go-live. Rule two: plan for MAC randomisation from day one. Build a pre-registration workflow into your resident onboarding process. Don't assume devices will present their permanent MAC address by default. Rule three: automate the key lifecycle. The operational value of UU PPSK over a shared PSK is entirely dependent on keys being provisioned and revoked automatically. Integrate with your property management system from the outset. Rapid-fire questions. Does UU PPSK work with WPA3? Yes, with caveats. WPA3-SAE changes the handshake mechanism. Most modern controllers support UU PPSK in WPA2 and WPA3 transition mode for backward compatibility. Check your vendor's specific documentation before specifying a pure WPA3 deployment. How many unique keys can a single SSID support? With an external RADIUS server, the practical limit is your RADIUS database capacity. Purple's cloud RADIUS service scales to tens of thousands of concurrent keys. Is UU PPSK a replacement for 802.1X? No. For fully managed corporate device fleets with MDM-enrolled devices, 802.1X with EAP-TLS remains the gold standard. UU PPSK is the right choice for residential and mixed-use environments where you cannot guarantee that every device supports 802.1X supplicant configuration. To summarise. PPSK 40 B2 - 40-character keys, RADIUS-backed, cloud-orchestrated - is the correct WiFi authentication architecture for BTR, MDU, student accommodation, and social housing deployments above 50 units. It delivers per-resident network isolation, automated key lifecycle management, full IoT device support, and a complete GDPR audit trail, all from a single SSID. Purple's Multi-Tenant WiFi platform deploys this architecture on top of Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet hardware, with no forklift upgrades required. If you're specifying a new development or reviewing an existing deployment, the next step is a Purple architecture review. We'll assess your current hardware, your resident count, your property management system integration requirements, and give you a clear deployment recommendation. You can find more at purple.ai. Thanks for listening to the Purple Technical Briefing.