Designing a Multi-Tenant WiFi Architecture for MDU

Designing a Multi-Tenant WiFi Architecture for MDU — A Purple Technical Briefing. Welcome to the Purple Technical Briefing series. Today we're getting into the architecture that underpins some of the most complex WiFi deployments you'll encounter in enterprise environments — multi-tenant WiFi for multi-dwelling and multi-use buildings. Whether you're responsible for a 300-room hotel where guests, staff, and building management systems all share the same physical infrastructure, a mixed-use retail and office complex, or a student accommodation block with hundreds of independent tenants, the challenge is fundamentally the same: how do you deliver reliable, secure, isolated connectivity to multiple independent parties over a single shared physical network? This isn't a theoretical exercise. The decisions you make at the architecture stage will directly determine your security posture, your compliance exposure under GDPR and PCI DSS, and frankly, whether your support desk gets flooded with complaints six months after go-live. So let's get into it. The foundation of any multi-tenant WiFi architecture is network segmentation — and the primary mechanism for achieving that segmentation is VLAN tagging, defined 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 routing or firewall policy. That logical isolation is your first line of defence. But 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. Now, let's talk about the physical layer. In an MDU environment, you typically have a shared physical infrastructure — cabling, switch fabric, and access points — serving multiple tenants. The access points themselves broadcast multiple SSIDs, each mapped to a different VLAN. So Tenant A connects to their SSID, their traffic is tagged with VLAN 10 at the AP, 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. This is where your choice of access point platform matters enormously. You need APs that support multiple SSID-to-VLAN mappings, that can handle the radio frequency management across potentially dozens of units in close proximity, and that integrate with a centralised controller or cloud management platform. The controller is critical — it's what gives you the ability to push policy changes, monitor per-tenant throughput, and respond to incidents without touching individual APs. On the authentication side, the current standard for enterprise-grade multi-tenant deployments is IEEE 802.1X with RADIUS authentication. Each tenant authenticates against their own RADIUS server, or against a shared RADIUS infrastructure with per-tenant policy enforcement. WPA3-Enterprise is now the recommended encryption standard — it provides 192-bit security mode for high-sensitivity environments and eliminates the vulnerabilities associated with WPA2's four-way handshake. For guest WiFi segments — and in an MDU context, you'll almost always have at least one — you're typically looking at a Captive Portal model. The guest connects to an open or WPA2-Personal SSID, gets redirected to a splash page for authentication or terms acceptance, and is then granted internet-only access on an isolated VLAN. Critically, that guest VLAN must have no route to any tenant VLAN. Zero. That's non-negotiable from both a security and a GDPR perspective. Let's talk about the radio frequency environment for a moment, because this is where MDU deployments get genuinely complex. When you have multiple tenants in adjacent units — think a hotel corridor with rooms on both sides, or a shopping centre with shops sharing walls — you have a high-density RF environment. Co-channel interference is your enemy. You need a proper RF planning exercise before deployment: a 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, which is why modern deployments push clients to 5 GHz wherever possible. Wi-Fi 6 and Wi-Fi 6E extend this further into the 6 GHz band, giving you a clean spectrum largely free from legacy device interference. For new MDU deployments in 2025 and beyond, specifying Wi-Fi 6E capable APs is the right call — the additional spectrum headroom pays dividends in dense environments. One architecture pattern that's gaining significant traction in large MDU deployments is the use of a Software-Defined Networking overlay — specifically SD-WAN or SD-LAN approaches where tenant policies are defined centrally and pushed to the edge. This decouples the policy layer from the physical infrastructure, which means you can onboard a new tenant, modify their bandwidth allocation, or revoke their access without touching a single switch command line. For venue operators managing dozens or hundreds of tenants, that operational efficiency is transformative. IoT is the other dimension you cannot ignore. In a modern MDU — whether that's a hotel, a retail complex, or a residential block — you have building management systems, HVAC controllers, smart lighting, access control, CCTV, and a growing range of other connected devices. 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 so they can only communicate with their designated management platforms. Right, let's get practical. Here's how I'd approach a greenfield MDU deployment. Start with your logical design before you touch a single piece of hardware. Map out your tenant count, your traffic classes — management, corporate, guest, IoT, payment — and assign VLANs accordingly. Document your IP addressing scheme. Define your inter-VLAN routing policy: what can talk to what, and what is absolutely prohibited. Then do your RF planning. Commission a proper site survey. Don't rely on vendor coverage maps — they're optimistic at best. You need actual signal measurements in the physical space, accounting for wall materials, floor construction, and the RF environment from neighbouring buildings. When you're specifying hardware, prioritise platforms that support centralised cloud management. The operational overhead of managing a distributed AP estate without a controller is unsustainable at scale. Look for platforms that give you per-SSID bandwidth policies, per-tenant reporting, and integration with your RADIUS infrastructure. On the pitfalls: the most common failure mode I see 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. Every SSID you broadcast consumes airtime for beacon frames. In a dense environment, broadcasting eight or ten SSIDs per AP degrades performance for everyone. Keep your SSID count to the minimum necessary — typically no more than four per radio. Use dynamic VLAN assignment via RADIUS attributes rather than separate SSIDs to serve multiple tenants from a single SSID. The third pitfall is neglecting the management plane. Your management VLAN — the one your APs, 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. Use out-of-band management where possible, and apply strict ACLs to management traffic. Now let me run through a few questions that come up consistently in these deployments. How many tenants can a single AP support? Practically speaking, most enterprise APs can handle 20 to 30 concurrent active clients per radio before performance degrades. In a dense MDU, plan for one AP per 15 to 20 active devices, not per physical unit. Do I need a separate AP per tenant? No — that's the whole point of VLAN-based multi-tenancy. Multiple tenants share the same AP, with traffic isolation enforced at the network layer. What's the right bandwidth allocation per tenant? There's no universal answer, but a common starting point is 10 to 25 megabits per second guaranteed with burst capability up to the available uplink capacity. Use QoS policies to enforce this and prevent any single tenant from saturating the shared uplink. How do I handle a tenant who needs their own firewall? Provide them with a dedicated VLAN and a routed handoff point. They connect their own CPE or firewall to that handoff, and everything behind it is their responsibility. To bring this together: a well-designed multi-tenant WiFi architecture for an MDU 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 an MDU 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, the resources linked in the guide are a good starting point. Thanks for listening. Until next time.