Logo guild iPSK: a comprehensive guide for businesses

Welcome to the Purple technical briefing. Today we are covering logo guild iPSK, which stands for Identity Pre-Shared Key, and why it has become the definitive WiFi security model for property developers, BTR operators, and multi-tenant residential developments. Let me start with the problem you are actually trying to solve. You manage a Build-to-Rent development. Could be 100 units, could be 500. You want every resident to have secure, private WiFi from day one. You do not want to install a separate router in every flat. You do not want to manage hundreds of separate networks. And you absolutely cannot have Resident A browsing Resident B's smart TV on the network. Standard WPA2-PSK, the shared password model, fails immediately at this scale. One password for the whole building means one breach affects everyone. And you cannot revoke access for a single resident without changing the password for all of them. That is operationally impossible. The other extreme is WPA3-Enterprise with 802.1X. Very secure. But it requires digital certificates or username-password credentials for every device. Your residents' gaming consoles, smart speakers, and thermostats simply cannot connect to an 802.1X network. They have no supplicant. You would be fielding support calls every single day. iPSK sits exactly in the middle. Every resident gets their own unique pre-shared key. To the resident, it looks and feels exactly like a home WiFi password. They type it in once, and every device they own connects. Behind the scenes, however, the wireless access point sends a RADIUS request to the Purple cloud, containing the client's MAC address. Our RADIUS server looks up that MAC, finds the matching authorisation profile, and returns the correct PSK. The access point then validates the connection using that individual key. The result: one SSID for the entire building, but every resident is isolated in their own private network segment. Now let me walk you through the architecture, because this is where the real power lies. The authentication flow has four steps. First, the client device sends an association request to the access point. Second, the wireless controller, whether that is a Cisco Meraki, an HPE Aruba, a Ruckus, or a Juniper Mist, sends a RADIUS Access-Request to the Purple cloud, carrying the client MAC address. Third, our RADIUS server evaluates the authorisation policy. It matches the MAC address to the resident record, retrieves the assigned PSK, and returns an Access-Accept response containing the VLAN ID for that resident. Fourth, the access point drops the client onto their dedicated VLAN. From the resident's perspective, this is indistinguishable from a standard home WiFi connection. The complexity is entirely server-side. That is the elegance of iPSK. VLAN override via RADIUS means Resident A lands on VLAN 101, Resident B on VLAN 102, and your building IoT devices, door sensors, CCTV, smart meters, sit on a completely separate VLAN with no cross-contamination. A word on what we call the Private Area Network, or PAN. This is the virtual bubble created around each resident's devices. Even though hundreds of residents share the same WiFi infrastructure, iPSK ensures Layer 2 isolation. Resident A's phone can see their own Chromecast and printer. Resident B in the next flat cannot see or interact with those devices at all. This also enables something called mDNS Reflection, which allows devices to discover each other within their own private segment. So casting Netflix to a Chromecast works perfectly, just as it would on a home router, but it does not bleed into the corridor or into any other resident's network. Let me now compare iPSK against the alternatives, because the choice of authentication model is one of the most consequential decisions you will make in your network design. Standard PSK, WPA2-Personal, gives you simplicity. Everyone uses the same password. But there is no central control. If one resident leaks the password, the entire network is at risk. Rotating the password when a resident leaves affects every other resident. At 200 units, this is unmanageable. 802.1X EAP-TLS is the high-security corporate standard. It provides per-device certificate-based authentication. You can revoke individual access instantly. But it requires a certificate authority, certificate management, and a supplicant on every device. Gaming consoles, smart TVs, Amazon Alexa devices, none of them support 802.1X. In a residential environment, this is a non-starter. iPSK gives you the per-device identity of 802.1X with the operational simplicity of a home password. It supports 100% of devices, including every headless IoT device your residents own. And it scales to thousands of units without adding management overhead, because the lifecycle is automated. Vendor terminology varies, and it is worth knowing the equivalents. HPE Aruba calls this MPSK, Multi-PSK. Ruckus and Juniper Mist use DPSK, Dynamic PSK. Ubiquiti UniFi calls it PPSK, Private PSK. The concept is identical across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. Purple deploys as a cloud overlay on all of these platforms. You do not need to replace your access points. Now let me walk you through implementation, because this is where deployments go wrong. The first and most common mistake is under-sizing the DHCP scope. Network engineers sometimes assign a slash-28 subnet per apartment to save IP address space. That is 14 usable addresses. In 2026, a couple in a BTR flat will exhaust 14 IPs by Tuesday. A phone, a laptop, a tablet, a smart TV, a games console, a smart speaker, a couple of smart bulbs. You are already at eight devices before they have had a friend round. Always default to a slash-24 subnet per resident. The second critical detail is client isolation. You must ensure client isolation is disabled within the resident's VLAN. If you leave client isolation on, you break the smart home functionality that iPSK is designed to enable. Devices on the same key will not communicate with each other, and you will be fielding Chromecast support tickets all week. The third consideration is roaming. If a resident walks from their flat on the fourth floor down to the gym on the ground floor, their connection needs to persist. This means their specific VLAN must be trunked to the access point in the gym, or you need to tunnel the traffic back to a central controller. This is a common oversight in initial deployments. Now, the elephant in the room: WPA3 and the 6 GHz band. WiFi 6E and WiFi 7 mandate WPA3 security on the 6 GHz band. WPA3 replaces the old four-way handshake with Simultaneous Authentication of Equals, or SAE. The problem is that the IEEE 802.11 standard for SAE does not currently support multiple passwords per SSID in the way WPA2 does. This is not a Cisco Meraki problem or an Aruba problem. It is an industry-wide limitation rooted in the IEEE standard itself. The current best practice is a hybrid approach. Maintain a WPA2 iPSK SSID on the 2.4 and 5 GHz bands for legacy devices and IoT hardware. For the 6 GHz band, deploy a separate SSID using 802.1X for managed corporate endpoints. There is also the MAC address randomisation challenge. Apple iOS 14 and Android 10 introduced per-network randomised MAC addresses. In a MAC-based iPSK deployment, the access point sends the randomised MAC to the RADIUS server. The server does not recognise it. Authentication fails. Cisco Meraki's Easy PSK mode largely resolves this by authenticating via EAPOL parameters rather than MAC lookup. If you are on Meraki and you have iOS or Android clients, use Easy PSK mode. Two real-world scenarios to make this concrete. Scenario one: a 350-unit Build-to-Rent development. The operator wanted residents to receive their WiFi credentials before move-in day. Purple's Multi-Tenant WiFi platform integrated with the property management system. When a lease was signed, the PMS triggered an API call to Purple, which generated a unique iPSK and provisioned it automatically. The resident received their key by email. They walked in on day one, connected all their devices, and the network was live. When they moved out, the key was revoked automatically. Zero manual intervention from the facilities team. The operator reduced WiFi-related support calls by over 60% compared to their previous shared-password model. Scenario two: a 180-room hotel property. The hotel wanted to eliminate the captive portal login that guests complained about repeatedly. With iPSK, each room received a unique key printed on the key card or sent via the booking confirmation email. Guests connected once. Their phone, tablet, and laptop all joined automatically on subsequent visits within the same stay. IoT devices in the room sat on a separate VLAN, isolated from guest traffic. Keys were generated at check-in and revoked at check-out without any manual steps at the front desk. Rapid-fire questions now. Can iPSK work without Cisco ISE? Yes. FreeRADIUS and Microsoft NPS both support the Tunnel-Password attribute that iPSK requires. Purple acts as the RADIUS server, so you do not need to deploy or manage your own RADIUS infrastructure at all. Is iPSK PCI DSS compliant? iPSK supports the network segmentation requirements of PCI DSS 4.0. Cardholder data environments must be isolated from guest and IoT networks. iPSK's VLAN override capability is the mechanism that achieves this segmentation. What is the commercial case? Research from the British Property Federation indicates that managed WiFi commands a 15 to 30 pound rent premium per unit per month in UK Build-to-Rent developments. You also eliminate the five to ten day void period while a resident waits for an ISP engineer. To summarise. iPSK gives you per-device identity on a single SSID, without the complexity of 802.1X certificates and without the security failures of a shared password. It is the right model for Build-to-Rent, hotels, retail, and any multi-tenant environment where you need to isolate traffic, automate access lifecycle, and support every device type. Five rules before you go. One: if you have more than 50 devices or users on a single SSID and you need per-device access control, iPSK is almost certainly the right model. Two: always plan your VLAN architecture before you configure iPSK. Three: if you are on Cisco Meraki with iOS or Android clients, use Easy PSK mode. Four: do not deploy iPSK without a lifecycle management layer. Five: plan your WPA3 migration now. Purple's Multi-Tenant WiFi platform handles the lifecycle automation piece, connecting your property management system or identity provider to your hardware, automating key provisioning and revocation at scale, across 80,000 live venues and counting. If you want to go deeper, whether that is an architecture review, a configuration walkthrough, or a pilot deployment, the link to speak to our team is in the guide. Thanks for listening.