Arti iPSK: a comprehensive guide for businesses

Speak in British English with a confident, authoritative, conversational tone - like a senior network consultant briefing a CTO before a board meeting. Measured pace, clear diction, occasional dry wit. Not a lecture. A briefing: Welcome to the Purple Technical Briefing. [short pause] Today we are talking about arti iPSK - which, for anyone who has not come across the term, is shorthand for automated or artificial-intelligence-assisted Identity Pre-Shared Key management. [short pause] It is a mouthful, but the concept is straightforward, and by the end of this ten minutes, you will know exactly whether it belongs in your network design this quarter. Let me set the scene. [short pause] You are a property developer, a BTR operator, or an IT director responsible for connectivity across a multi-tenant building. You have hundreds of residents, each with fifteen to twenty-five devices - phones, laptops, smart TVs, gaming consoles, smart speakers, thermostats. They all need WiFi. They all expect it to work like a private home network. And you need to ensure that resident A cannot see, access, or interfere with resident B's devices - ever. [short pause] That is the problem. iPSK is the architecture that solves it. Arti iPSK is what happens when you automate the lifecycle management of that architecture at scale. [medium pause] Right. Let us get into the technical architecture, because this is where most procurement conversations go wrong. [short pause] Standard WPA2-Personal - the password on the back of a router - gives you one key shared by everyone. In a 200-unit BTR development, that means 200 households, potentially 4,000 devices, all authenticating with the same credential. If one resident shares that password, you have lost control of your network perimeter. If a resident moves out and you need to revoke their access, you have to change the password for the entire building. That is not a network management strategy. That is a liability. [short pause] At the other end of the spectrum, you have WPA3-Enterprise using IEEE 802.1X - the corporate standard. It requires a unique username and password, or a digital certificate, per device. It is highly secure. But here is the problem: headless devices - gaming consoles, smart TVs, Amazon Echo, Chromecast - cannot process 802.1X certificates. They simply cannot connect. In a residential environment, that is a dealbreaker. [short pause] iPSK sits precisely in the middle. Identity Pre-Shared Key assigns a unique WiFi password to every individual resident or device group, all on a single SSID. From the device's perspective, it is connecting to a standard WPA2 or WPA3 network using a pre-shared key. No certificates, no complex onboarding. But behind the scenes, your wireless controller - whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist - maintains a database of unique keys, one per resident. When a device connects and presents its key, the controller matches it to an identity record and applies the corresponding network policy: VLAN assignment, bandwidth limits, access control. [medium pause] Now, the really powerful part is what happens at the VLAN layer. [short pause] In a BTR development, you want at minimum four network segments. A resident VLAN for personal devices. A staff VLAN for building management. An IoT VLAN for building management systems, CCTV, and smart locks. And a guest VLAN for common areas. With a single shared PSK, you cannot differentiate between these groups without deploying multiple SSIDs - which creates radio frequency congestion and management overhead. With iPSK, a single SSID dynamically steers each connecting device into the correct VLAN based on which key it presented. Clean, scalable, operationally straightforward. [short pause] This also creates what we call a Private Area Network - a WiFi bubble around each resident's devices. Inside the bubble, Layer 2 isolation is disabled, so mDNS reflection works. A resident's iPhone can discover their own Chromecast or wireless printer, just like on a home router. Outside the bubble, Layer 2 isolation is strictly enforced. Resident A cannot see, cast to, or interact with resident B's devices, even if they are connected to the same physical access point in the corridor. That is the GDPR-compliant architecture for multi-tenant WiFi. [medium pause] So where does the "arti" part come in? [short pause] Arti iPSK refers to the automation and intelligence layer on top of the core iPSK architecture. Manually managing thousands of unique keys - generating them, distributing them, revoking them when a tenancy ends - is simply not viable at scale. A 500-bed development with a 52-week tenancy cycle means hundreds of key lifecycle events per year. If your team is managing that in a spreadsheet, you are creating operational risk. [short pause] The automation layer connects your wireless controller to your identity provider - Microsoft Entra ID, Okta, or Google Workspace - and to your property management system via REST API. When a new resident is added to your tenancy system, a unique iPSK key is automatically generated and distributed - via the Purple app, a welcome email, or a QR code on a move-in card. When a tenancy ends, the key is automatically revoked. No manual intervention. No support tickets. No orphaned credentials accumulating as a security liability. [short pause] Purple's Multi-Tenant WiFi platform handles this entire lifecycle as a cloud overlay on your existing hardware. We run across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet - so you are not locked into a specific vendor. The platform is ISO 27001 certified, GDPR and CCPA compliant, and delivers 99.999% uptime across 80,000 live venues. [medium pause] Let me give you two real-world scenarios to make this concrete. [short pause] Scenario one: a 300-unit Build-to-Rent development in Manchester. The developer specified Cisco Meraki access points throughout the building - one AP per corridor, two per floor in high-density areas. Purple's cloud overlay connects to the Meraki controller via RADIUS and API. When a new resident signs their tenancy agreement in the property management system, Purple automatically generates a unique 32-character iPSK key and sends it to the resident's email with a QR code. On move-in day, the resident scans the QR code on their phone. Every device they subsequently connect using that key - laptop, smart TV, gaming console, smart speaker - lands in their private VLAN. Their Chromecast works. Their PlayStation gets a clean NAT type. Their neighbour cannot see any of their devices. When they move out, the key is revoked within minutes of the tenancy end date being updated in the property management system. The next resident gets a fresh key before they arrive. [short pause] Scenario two: a 250-room hotel. Historically, the hotel used a captive portal - guests had to log in via a web page every 24 hours. The most common guest complaint was WiFi reconnection friction. Apple TVs in the rooms did not work at all, because captive portals break device pairing. The hotel integrated their property management system with Purple. At check-in, the PMS automatically triggers key generation. The guest receives their unique iPSK key on their check-in confirmation. They connect once. Their devices stay connected for the duration of their stay. The key expires automatically at checkout. Guest satisfaction scores for WiFi improved by 34% in the first quarter after deployment - Purple's own data from the implementation. [medium pause] Right. Implementation recommendations and the pitfalls to avoid. [short pause] First: key generation. Your iPSK keys need to be a minimum of 20 characters, ideally 32, and cryptographically random. Do not let residents choose their own keys. Do not use sequential or predictable patterns. Generate them programmatically and distribute them securely. [short pause] Second: controller support. Not all wireless controllers implement iPSK equally. Cisco calls it iPSK or Personal Private Network. Aruba calls it MPSK - Multi-PSK. Ruckus calls it DPSK - Dynamic PSK. The scale limits, API capabilities, and VLAN steering granularity vary between platforms and firmware versions. Before you commit to a platform, validate the maximum number of unique keys supported per SSID. Some older platforms cap this at a few hundred, which is inadequate for a large development. [short pause] Third: device limits per key. Students and residents connect multiple devices. If you do not configure a per-key device limit, a single iPSK can proliferate across dozens of devices, undermining your ability to attribute traffic accurately. Set a limit of four to six devices per key and enforce it at the controller. [short pause] Fourth: DHCP scope sizing. In a high-density residential environment, you will burn through IP addresses quickly. Plan for 15 to 25 devices per household. Use four-to-eight-hour DHCP lease times rather than the default 24 hours to reclaim addresses efficiently. [short pause] The pitfall to avoid above all others: deploying iPSK without a documented key lifecycle process. Keys that are never revoked accumulate over time and become a security liability. Build the revocation workflow before you go live, not after. [medium pause] Quick-fire questions. [short pause] Does iPSK require a certificate on the client device? No. The client device sees a standard WPA2 or WPA3 password prompt. No certificates, no supplicant configuration. [short pause] Can you limit bandwidth per resident? Yes. The RADIUS server identifies the specific resident and can push rate-limit policy attributes back to the controller. [short pause] Is it secure if a resident shares their key? Much more secure than standard PSK. The new device joins that resident's isolated Private Area Network only - not the wider building network or other residents' devices. And you can set a concurrent MAC address limit per key. [short pause] Does iPSK work with WPA3? Yes. WPA3-SAE can be combined with iPSK on supported hardware, adding forward secrecy and resistance to offline dictionary attacks. [medium pause] To wrap up. [short pause] Arti iPSK - automated Identity Pre-Shared Key management - is the right architecture for any multi-tenant WiFi deployment where you need per-resident accountability without the complexity of a full 802.1X infrastructure. It gives you unique credentials per resident, dynamic VLAN steering, granular lifecycle management, and a compliance-ready audit trail - all with a device onboarding experience as simple as entering a WiFi password. [short pause] The commercial case is clear. In the BTR sector, managed WiFi as an amenity supports a rent premium of fifteen to thirty pounds per unit per month and reduces void periods by five to ten days - British Property Federation sector research. For a 200-unit development, that is a meaningful contribution to net operating income. [short pause] Purple has been running managed WiFi across 80,000 venues since 2012. We are ISO 27001 certified, GDPR and CCPA compliant, and B Corp certified. Our Multi-Tenant WiFi platform handles the full resident lifecycle - onboarding, credential management, IoT support, analytics, and compliance - as a cloud overlay on the hardware you already own or are specifying today. [short pause] If you are at the design stage of a BTR development, or reviewing an existing network that is not performing, visit purple dot ai for the full written guide, architecture diagrams, and an ROI calculator. [short pause] Thanks for listening.