Managed WiFi service: a comprehensive guide for businesses

Welcome to the Purple Technical Briefing. I'm going to spend the next ten minutes giving you a clear, practical picture of managed WiFi services - what they are, how they work, and why the architecture decisions you make today will determine whether your network becomes an operational asset or an ongoing headache. [medium pause] Let's start with context. The term "managed WiFi service" gets used loosely. At its most basic, it means outsourcing the design, deployment, monitoring, and ongoing management of your wireless network to a third party. But that definition misses the more important shift that's happened over the last five years. The real change is architectural. Managed WiFi has moved from a hardware-and-support contract to a cloud overlay model - where the intelligence, the authentication, the analytics, and the compliance layer all sit in software, running on top of whatever access points you already own. [short pause] For property developers, BTR operators, and landlords managing multi-dwelling units, that shift matters enormously. You're no longer buying a network. You're buying a service that runs on your network. And the distinction changes everything about how you procure it, how you price it to residents, and how you extract value from it over time. [medium pause] Right. Let's get into the technical architecture, because this is where most procurement conversations go wrong. [short pause] A managed WiFi service has four distinct layers. First, the access layer - the physical access points mounted in corridors, common areas, and individual units. Second, the switching and cabling infrastructure - the PoE switches and structured cabling that power and connect those APs. Third, the controller or cloud management platform - the software that configures, monitors, and updates every AP from a single pane of glass. And fourth, the services layer - authentication, guest access, resident onboarding, analytics, and compliance. This is where the value actually lives. [short pause] The critical insight is that layers one and two are largely commoditised. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium - they all make excellent access points. The hardware decision matters, but it's not where you win or lose. You win or lose on layers three and four. [medium pause] Now, for a BTR or MDU deployment, the services layer has a specific requirement that standard enterprise WiFi doesn't address: per-resident isolation. This is the fundamental challenge. You have one shared physical network serving hundreds of separate households. Each resident expects their devices to behave exactly as they would on a home network - their phone finds their Chromecast, their smart speaker pairs with their bulbs, their games console gets a clean NAT type for online multiplayer. But resident A's devices must be completely invisible to resident B. [short pause] The technology that solves this is iPSK - Identity Pre-Shared Key. Sometimes called PPSK by Aruba, or Personal Private Network by Cisco Meraki. The concept is the same regardless of vendor terminology. Each resident is issued a unique WiFi credential during onboarding. All their devices use that credential. The network uses it to identify which resident a device belongs to, and places it in a per-resident private segment - what we call a WiFi bubble. Devices on the same credential discover each other. Devices on different credentials are invisible to each other. When a resident moves out, you revoke their credential. No other resident is affected. [medium pause] That's the core of it. But there's a compliance dimension that's equally important, particularly in the UK and EU. Under GDPR, you have an obligation to ensure that one resident cannot access another resident's data or devices. iPSK is the technical mechanism that satisfies that obligation at the network layer. Layer it with WPA3 encryption - that's the current standard, replacing WPA2 - and you have a defensible architecture from a data protection standpoint. [short pause] For the authentication side, IEEE 802.1X with a RADIUS back-end is the standard for staff networks. It provides certificate-based or credential-based authentication before a device is admitted, and it integrates with Microsoft Entra ID, Okta, or Google Workspace for policy enforcement. For resident networks using iPSK, the RADIUS server handles the per-credential lookup and VLAN assignment automatically. [medium pause] Let me talk about network segmentation, because it's the other architectural pillar you need to get right. In a BTR development, you're running at minimum three distinct network populations: residents, staff, and visitors in common areas. Each needs its own VLAN - a Virtual Local Area Network, defined in the IEEE 802.1Q standard - with its own firewall policy. Residents on VLAN 30, staff on VLAN 20, guest WiFi in the lobby and gym on VLAN 10, IoT and building management systems on VLAN 40. [short pause] The firewall policy between those VLANs is as important as the VLAN architecture itself. Default-deny, explicit-permit. Your guest VLAN should have outbound internet access and nothing else. No route to the resident network, no route to the staff network, no route to building management systems. This is not optional if you're serious about security and compliance. Right. Implementation. Let me give you the five phases of a managed WiFi deployment, because this is where projects typically stall or fail. [short pause] Phase one is the RF site survey. Before you specify a single access point, you need a predictive radio frequency design. Tools like Ekahau model signal propagation through your building's specific materials - concrete, glass, plasterboard - and tell you exactly where to mount APs and at what power levels to achieve your coverage targets. Skipping this and going with a rough AP-per-square-metre estimate is the single most common cause of poor performance post-deployment. [short pause] Phase two is traffic classification and VLAN design. Document every device type and user population in your environment. Residents, staff, visitors, IoT devices, CCTV, building management systems. Each gets a VLAN, a subnet, and a firewall policy before you touch a controller. [short pause] Phase three is controller configuration and SSID mapping. Keep your SSID count low - no more than four per radio band. Three is ideal: resident, staff, guest. Every additional SSID you broadcast consumes airtime for beacon frames, even when no clients are connected. In a dense building with hundreds of APs, SSID proliferation meaningfully degrades throughput. [short pause] Phase four is the services layer integration. This is where a platform like Purple's Multi-Tenant WiFi connects to your controller via RADIUS and API, handles resident onboarding, manages per-resident iPSK credentials, and delivers the analytics and compliance layer. Purple runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet - so you're not locked into a specific hardware vendor. [short pause] Phase five is validation and monitoring. Run a post-deployment RF validation walk. Test your VLAN segmentation from a guest device - confirm you cannot reach the resident or staff subnets. Set up your monitoring dashboards and define your SLA thresholds. Purple's platform gives you 99.999% uptime SLA and real-time network health visibility across your entire estate. [medium pause] Now let me flag the three pitfalls I see most often. [short pause] First: under-specifying the site survey. I've seen deployments where the developer saved money by skipping the predictive RF design and ended up with coverage holes in exactly the units they were trying to differentiate on WiFi quality. The survey cost is a fraction of the remediation cost. [short pause] Second: treating resident WiFi as an afterthought. In BTR, WiFi quality is a top-five amenity factor in booking research. Operators who lead on WiFi quality consistently outperform sector averages on resident satisfaction scores. The network is a commercial asset, not just infrastructure. [short pause] Third: bundling WiFi with a third-party broadband contract. The software-overlay model - where you own the hardware and run a managed service on top - consistently delivers better economics than a bundled ISP contract. The rent premium of twenty to forty pounds per unit per month that WiFi-as-amenity generates should flow to the operator, not to a third-party ISP. [medium pause] Quick-fire questions. Three of the ones I hear most often. [short pause] "Do I need to replace my existing access points?" In most cases, no. If you have Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi already installed, Purple's cloud overlay runs on top of your existing hardware via standard RADIUS and VLAN integration. You're adding a services layer, not replacing the physical infrastructure. [short pause] "How does a resident get online on move-in day?" With iPSK, the resident receives their unique WiFi credential as part of the move-in process - via the Purple app or a welcome email. They connect their first device, and every subsequent device they add uses the same credential. No waiting for a broadband engineer. No separate ISP contract. Online from day one. [short pause] "What about smart home devices and IoT?" This is the question that catches a lot of operators out. Standard guest WiFi isolates every device from every other device - which means Chromecast won't work, smart speakers won't pair, and you'll get a flood of support tickets. iPSK solves this by keeping all of a resident's devices in the same logical network segment while isolating them from other residents. Fifteen to twenty-five devices per household is the realistic figure for a modern BTR unit. Your network architecture needs to handle that density from day one. [medium pause] To wrap up. A managed WiFi service for BTR and MDU is not just a connectivity play. It's a resident experience platform, a compliance mechanism, and a commercial asset. The architecture decisions - iPSK for per-resident isolation, WPA3 for encryption, VLAN segmentation for security, cloud overlay for management - are well-established and vendor-neutral. The hardware is commoditised. The value is in the services layer. [short pause] Purple has been running managed WiFi across 80,000 venues since 2012. We're 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're at the design stage of a BTR development, or reviewing an existing network that isn't performing, the right next step is a conversation with one of our network architects. We'll review your floor plans, your device density assumptions, and your commercial model, and give you a clear picture of what the architecture should look like and what it will cost. [short pause] You'll find the full written guide, the architecture diagrams, and the ROI calculator at purple dot ai. Thanks for listening.