iPSK ind: a comprehensive guide for businesses

Welcome to the Purple Technical Briefing. Today we are covering iPSK ind - Identity Pre-Shared Key for individual devices - and why it has become the authentication standard of choice for property developers, build-to-rent operators, and multi-dwelling unit landlords deploying managed WiFi at scale. If you are managing WiFi across a residential development, a student accommodation block, or a mixed-use property, you have almost certainly hit the same wall. Your residents expect the same WiFi experience they get at home - simple, reliable, and private. But your network team needs individual access control, security segmentation, and the ability to revoke access the moment a tenancy ends. Traditional options force you to choose one or the other. iPSK ind removes that compromise entirely. Let me give you the context first. There are two established WiFi authentication models that most organisations have been working with for years. The first is WPA2-Personal - what most people call a shared password. Everyone on the network uses the same passphrase. It is simple, it works on every device, and it requires minimal infrastructure. The problem is that it is a single point of failure. If one resident shares their password, or one device is compromised, the entire network is exposed. And if you need to revoke access for one person - say, a tenant who has moved out - you have to change the password for everyone. In a development with two hundred apartments, that is simply not manageable. The second model is WPA2 or WPA3 Enterprise, which uses the IEEE 802.1X authentication framework. Here, every user authenticates with individual credentials - typically a username and password, or a digital certificate - validated against a RADIUS server. It is highly secure, it gives you granular per-user access control, and it is the gold standard for corporate managed devices. But it has a critical weakness in residential and hospitality environments: complexity. Setting up a Public Key Infrastructure, managing certificates, and configuring supplicants on every device is a significant undertaking. And crucially, many devices simply cannot do it. Gaming consoles, smart TVs, IoT sensors, Chromecasts, Amazon Echo devices - these headless devices have no mechanism to handle certificate-based authentication. In a build-to-rent development, 802.1X is a non-starter for a meaningful proportion of your residents' device fleet. This is where iPSK ind sits. The core concept is elegant. Every resident or device receives its own unique pre-shared key, but they all connect to the same SSID - the same network name. From the resident's perspective, it feels exactly like connecting to a home WiFi network. They enter a passphrase, and they are on. From the network's perspective, each connection is individually identified, individually encrypted, and individually controllable. You get the simplicity of a shared password model with the granularity of enterprise-grade access control. Now let me walk you through the technical architecture, because understanding this is key to deploying it correctly. When a device attempts to connect to an iPSK-enabled SSID, the Wireless LAN Controller - the WLC - intercepts the connection attempt and forwards the device's MAC address to a RADIUS server. This is where the intelligence lives. The RADIUS server looks up that MAC address in its identity store and returns an Access-Accept response. Critically, embedded in that response is the unique pre-shared key assigned to that specific device or resident. The WLC receives this passphrase and uses it to validate the key the device presented during the WPA2 four-way handshake. If they match, the device is authenticated. What makes this architecture genuinely useful for property operators is what happens alongside that authentication. The RADIUS response can also carry VLAN assignment, bandwidth policy, and access control attributes. So not only does the device get its own unique encryption key, but it is automatically placed on the correct network segment. Residents on VLAN ten. IoT devices on VLAN twenty. Staff and maintenance on VLAN thirty. All from a single SSID, all managed centrally. The major hardware vendors have each implemented their own flavour of this technology. Cisco Meraki calls it iPSK. HPE Aruba calls it MPSK. Ruckus calls it DPSK - Dynamic PSK. Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet all support equivalent implementations. The underlying principle is identical across all of them. There is one feature of iPSK ind that is particularly relevant for multi-tenant deployments, and that is the Private Area Network concept. iPSK enables Layer 2 isolation between residents. Even though hundreds of devices share the same physical infrastructure and the same SSID, each resident's traffic is cryptographically isolated from every other resident's traffic. And with mDNS reflection enabled, a resident can still discover and use their own devices - casting to their Chromecast, printing to their portable printer - without any risk of their neighbour seeing or accessing those devices. That is the home-like experience that residents in a premium build-to-rent development expect, delivered on shared infrastructure. Let me move on to implementation, and specifically the pitfalls I see most often in deployments. The most common mistake is treating iPSK ind as a purely technical project rather than an operational one. The technology itself is relatively straightforward to configure. MAC address lookup on the WLC, RADIUS server with the appropriate attribute-value pairs, VLAN policies. The harder problem is key lifecycle management. How are keys provisioned? How are they distributed to residents? And critically, how are they revoked when a tenancy ends? The answer to all three questions should be automation. In a build-to-rent development, integration with your property management system means keys are generated when a tenancy is confirmed and revoked automatically on the move-out date. In a student accommodation block, integration with your student information system means keys are provisioned at enrolment and expire at the end of the academic year. Purple's platform provides this orchestration layer, sitting between your identity provider - whether that is Microsoft Entra ID, Okta, or Google Workspace - and your RADIUS infrastructure to automate the full key lifecycle without manual intervention. The second pitfall is RADIUS server resilience. Your iPSK deployment is only as reliable as your RADIUS infrastructure. If the RADIUS server is unavailable, no new devices can authenticate. Design for redundancy - a primary and secondary RADIUS server, with appropriate failover configuration on the WLC. For large developments, consider a cloud-hosted RADIUS service with a guaranteed uptime SLA rather than an on-premises server. Third: test your IoT device fleet before you go live. Most IoT devices work perfectly with iPSK, but some older devices have quirks around how they handle the WPA2 four-way handshake. A pre-deployment compatibility test, particularly for any bespoke or legacy hardware, will save you significant pain during commissioning. Now let me run through the questions I get asked most often. Does iPSK work with WPA3? Yes, with caveats. WPA3-SAE changes the handshake mechanism, which affects how iPSK keys are validated. Most modern controllers support iPSK in WPA2 and WPA3 transition mode, which provides backward compatibility. Cisco Meraki's IPSK without RADIUS feature does not currently support WPA3 encryption - you need the RADIUS-backed version for WPA3 compatibility. How many unique keys can a single SSID support? This is controller-dependent. Cisco Meraki supports up to five thousand iPSKs per SSID on firmware MR 30.1 and newer. In practice, the limiting factor is usually your RADIUS server's database capacity and query performance, not the wireless controller itself. Is iPSK GDPR-compliant? iPSK itself is a network authentication mechanism, not a data collection tool. The GDPR compliance question relates to how you store and process the identity data associated with each key - the resident's name, tenancy details, and device information. That data needs to be handled in line with GDPR Article 5 principles. Purple is ISO 27001 certified, GDPR and CCPA compliant, and B Corp certified, so the platform-level data handling is covered. Can iPSK replace a Captive Portal? In most residential deployments, yes. With iPSK ind, identity is established at the point of key provisioning, before the resident ever connects. The key itself is the credential. You still need a terms-of-service acceptance workflow, but that happens at onboarding, not at every connection. This removes the single biggest friction point in residential WiFi. So, to summarise, iPSK ind gives you individual encryption keys for every resident and device, VLAN-based traffic segmentation, Layer 2 isolation between residents, and automated key lifecycle management - all on a single SSID, on hardware-agnostic infrastructure. It is the right choice when you have a mixed device fleet that includes IoT and headless devices, when you need individual access control without the complexity of 802.1X, and when resident experience is a differentiator for your development. The three things to get right in your deployment: automate key lifecycle management from day one, design for RADIUS redundancy, and address MAC address randomisation in your onboarding flow. If you want to see how Purple deploys iPSK ind across build-to-rent and multi-dwelling developments, the implementation guide on purple.ai has detailed architecture diagrams and vendor-specific configuration references. And if you want a technical review of your specific environment, our network architects are available for a no-obligation consultation. Thanks for listening. This has been the Purple Technical Briefing.