Designing WiFi Networks for Multi-Tenant Office Buildings

PURPLE TECHNICAL BRIEFING Designing WiFi Networks for Multi-Tenant Office Buildings Full Transcript [SECTION 1: INTRODUCTION AND CONTEXT - 1 MINUTE] Welcome to the Purple Technical Briefing. I'm a Senior Solutions Architect at Purple, and today we're getting into one of the most technically demanding deployment scenarios in enterprise networking: designing WiFi networks for multi-tenant office buildings. Whether you're responsible for a grade-A commercial tower with fifteen independent tenants, a mixed-use development combining retail and office space, or a flexible coworking campus, the challenge is fundamentally the same. You need to deliver reliable, secure, isolated connectivity to multiple independent organisations over a single shared physical network. And you need to do it in a way that satisfies compliance requirements, keeps your support desk quiet, and doesn't require a full-time engineer to maintain. Let's get into the technical architecture. [SECTION 2: TECHNICAL DEEP-DIVE - 5 MINUTES] The foundation of any multi-tenant WiFi design is network segmentation. The primary mechanism for achieving that is VLAN tagging, standardised under IEEE 802.1Q. The concept is straightforward: you assign each tenant, or each traffic class, to a distinct virtual LAN. Traffic on VLAN 10 cannot reach traffic on VLAN 20 unless you explicitly permit it through a firewall policy. That logical isolation is your first line of defence. Now, here's where architects often make their first mistake. They conflate VLAN segmentation with security. VLANs provide isolation, not security. You still need firewall policies between VLANs. You still need access control lists. And you still need to think carefully about what inter-VLAN routing you permit. A misconfigured trunk port can collapse your entire segmentation model in seconds. In a multi-tenant office building, you typically have a shared physical infrastructure: cabling, switch fabric, and access points serving multiple tenants. The access points broadcast multiple SSIDs, each mapped to a different VLAN. Tenant A connects to their SSID, their traffic is tagged with VLAN 10 at the access point, traverses the shared switch fabric on a trunk port, and arrives at the distribution layer where it's routed into Tenant A's isolated subnet. Tenant B's traffic follows the same physical path but is completely isolated at Layer 2. Now, historically, network engineers segmented environments by creating a unique SSID for every tenant. But SSID proliferation is a performance killer. Every SSID you broadcast must transmit management frames, called beacons, at the lowest basic mandatory data rate. If you're broadcasting six or seven SSIDs on an access point, you can easily consume twenty to thirty percent of your available wireless airtime just on management overhead. That's before a single byte of actual user data is transmitted. The modern enterprise standard is Dynamic VLAN Assignment. Instead of multiple SSIDs, you broadcast one secure SSID using IEEE 802.1X authentication. When a user connects, their device exchanges credentials with a RADIUS server. The RADIUS server authenticates the user and sends an Access-Accept message back to the access point. Critically, this message includes specific IETF standard attributes: the Tunnel-Type, the Tunnel-Medium-Type, and the Tunnel-Private-Group-ID, which contains the specific VLAN ID for that user's organisation. The access point receives these attributes and dynamically drops that user's traffic directly into their dedicated VLAN. A corporate executive and an IoT device can connect to the exact same SSID, but their traffic is completely isolated at Layer 2. For authentication, WPA3-Enterprise is now the recommended encryption standard. It provides 192-bit security mode and eliminates the vulnerabilities associated with WPA2's four-way handshake. Identity providers like Microsoft Entra ID, Okta, or Google Workspace integrate with your RADIUS infrastructure to manage credentials centrally. Now let's talk about RF planning, because this is where multi-tenant office deployments get genuinely complex. When you have multiple tenants in adjacent spaces, you have a high-density RF environment. Co-channel interference is your enemy. You need a proper RF planning exercise before deployment: an active site survey that maps signal propagation, identifies interference sources, and informs your channel allocation strategy. The 2.4 GHz band gives you three non-overlapping channels in most regulatory domains: channels 1, 6, and 11. The 5 GHz band gives you significantly more capacity. WiFi 6E extends this into the 6 GHz band, giving you clean spectrum largely free from legacy device interference. For new multi-tenant deployments, specifying WiFi 6E capable access points from vendors like Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist is the right call. The additional spectrum headroom pays dividends in dense environments. IoT is the other dimension you cannot ignore. In a modern multi-tenant building, you have building management systems, HVAC controllers, smart lighting, access control, and CCTV. These must be on their own isolated VLAN, completely separated from both tenant traffic and guest traffic. IoT devices are notoriously difficult to patch and represent a significant attack surface. Segment them, monitor them, and apply strict egress filtering. [SECTION 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - 2 MINUTES] Let me share the three most common pitfalls I see in multi-tenant deployments. The first is insufficient trunk port configuration. Architects design a beautiful VLAN scheme and then forget to explicitly permit the relevant VLANs on every trunk link in the path. Traffic silently drops, tenants complain, and the support team spends days tracing the issue. Document your trunk configurations meticulously and validate them during commissioning. The second pitfall is SSID proliferation. Keep your SSID count to no more than four per radio. Use Dynamic VLAN Assignment via RADIUS attributes rather than separate SSIDs to serve multiple tenants. The third pitfall is neglecting the management plane. Your management VLAN, the one your access points, switches, and controllers communicate on, must be completely isolated from all tenant and guest VLANs. If a tenant can reach your management plane, you have a critical security vulnerability. I'd also add a fourth: neglecting DHCP lease time management on guest VLANs. In high-turnover environments, devices hold leases after disconnecting. Set guest VLAN lease times to one to two hours to prevent IP address exhaustion. [SECTION 4: RAPID-FIRE Q AND A - 1 MINUTE] Let me run through a few questions that come up consistently in these deployments. Do you need separate physical access points per tenant? No. That's the whole point of VLAN-based multi-tenancy. Multiple tenants share the same access point, with traffic isolation enforced at the network layer. How do you handle legacy IoT devices that don't support 802.1X? Use MAC Authentication Bypass combined with WPA3-SAE. The RADIUS server identifies the device by its MAC address and assigns it to an isolated IoT VLAN. Apply strict firewall rules to this segment. Does Dynamic VLAN Assignment affect roaming? Not if you configure it correctly. Enable 802.11r for Fast BSS Transition and Opportunistic Key Caching. Authentication state is cached across your access points, and users roam seamlessly without re-authentication delays. [SECTION 5: SUMMARY AND NEXT STEPS - 1 MINUTE] To bring this together: a well-designed multi-tenant WiFi architecture for an office building is built on four pillars. First, rigorous VLAN segmentation with enforced firewall policies between segments. Second, centralised controller-based management that gives you operational visibility and policy control at scale. Third, a proper RF planning exercise that accounts for the physical environment and the density of the deployment. And fourth, a security model that addresses authentication, encryption, IoT isolation, and compliance requirements from day one. The organisations that get this right see measurable outcomes: reduced support overhead, faster tenant onboarding, demonstrable compliance posture for audits, and the ability to monetise connectivity as a service rather than treating it as a cost centre. If you're planning a multi-tenant deployment and want to explore how Purple's platform can provide the analytics, Guest WiFi management, and tenant-level reporting layer on top of your network infrastructure, visit purple dot ai. The resources linked in the guide are a good starting point. Thanks for listening. Until next time.