Designing WiFi Networks for Multi-Tenant Office Buildings

This guide provides IT managers, network architects, and CTOs with a vendor-neutral blueprint for designing scalable, secure, and isolated WiFi networks across multi-tenant office buildings. It covers VLAN segmentation under IEEE 802.1Q, Dynamic VLAN Assignment via 802.1X and RADIUS, RF planning for high-density environments, and compliance considerations under GDPR and PCI DSS. Venue operators and building managers will find actionable architecture guidance, real-world case studies, and configuration pitfalls to avoid before deployment.

📖 9 min read📝 2,022 words🔧 2 worked examples❓ 4 practice questions📚 10 key definitions

Listen to this guide

View podcast transcript

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.

Key Takeaways

✓A flat network in a multi-tenant building is a critical security and compliance liability. Segment every traffic class into its own VLAN from day one.
✓IEEE 802.1Q VLAN tagging provides Layer 2 isolation. A Default-Deny firewall policy between VLANs provides Layer 3 security. You need both.
✓Dynamic VLAN Assignment via 802.1X and RADIUS eliminates SSID proliferation, reducing airtime overhead from 20-30% to under 8% and increasing client throughput by over 40%.
✓Isolating POS terminals on a dedicated VLAN reduces PCI DSS audit scope by approximately 70%, directly lowering compliance costs.
✓Never use VLAN 1 as the native VLAN on trunk ports. Change it to an unused, non-routable VLAN ID to prevent VLAN hopping attacks.
✓Commission an active RF site survey before deployment. Vendor coverage maps are optimistic. Co-channel interference is the primary cause of poor performance in dense environments.
✓Centralised cloud management from vendors like Cisco Meraki, HPE Aruba, or Juniper Mist reduces OpEx and enables consistent policy enforcement across distributed AP estates.

Executive summary

For CTOs and network architects managing multi-tenant office buildings, the challenge is clear: deliver reliable, secure, isolated connectivity to multiple independent organisations over a single shared physical network. A flat network architecture in a multi-tenant environment is a critical liability. It expands your compliance scope under GDPR and PCI DSS, exposes tenants to lateral security threats, and creates an operational burden that scales badly with tenant count.

This guide provides a vendor-neutral blueprint for designing a Multi-Tenant WiFi architecture. By implementing IEEE 802.1Q VLAN segmentation, Dynamic VLAN Assignment via 802.1X, and rigorous RF planning, you can eliminate SSID proliferation, reduce airtime overhead by up to 20 percentage points, and ensure strict Layer 2 isolation between tenants. We detail the technical standards, hardware considerations across vendors including Cisco Meraki, HPE Aruba, Ruckus, and Juniper Mist, and the routing policies required to secure your infrastructure. Done correctly, this architecture reduces support overhead, simplifies compliance audits, and enables you to monetise connectivity as a service.

Technical deep-dive

The case against flat networks

A flat network places every device, regardless of tenant, traffic type, or security classification, into a single broadcast domain. Every device receives every broadcast packet. A compromised guest device can scan and reach POS terminals, building management systems, and corporate workstations. Your entire network is in scope for PCI DSS. This is not a theoretical risk. It is the default state of many multi-tenant buildings that were wired before wireless density became a design constraint.

The solution is logical segmentation. You do not need separate physical infrastructure per tenant. You need a correctly designed VLAN architecture, a properly configured firewall, and a centralised management platform.

IEEE 802.1Q and VLAN tagging

Virtual Local Area Networks, standardised under IEEE 802.1Q, allow you to carve a single physical switch fabric into multiple isolated logical networks. When a client connects to a WiFi access point, the AP tags that client's data frames with a 12-bit VLAN Identifier (VID). Switches read this tag and ensure traffic from one VLAN is never forwarded to ports on another VLAN unless explicitly routed by a firewall.

A standard multi-tenant office building requires at minimum four VLANs:

VLAN	Traffic class	Routing policy
VLAN 10	Corporate Tenant A	Internet + tenant-specific resources only
VLAN 20	Corporate Tenant B	Internet + tenant-specific resources only
VLAN 30	Guest WiFi (captive portal)	Internet only, zero access to any tenant VLAN
VLAN 40	IoT and BMS	Egress to designated management platforms only

For buildings with more tenants, you extend this model. Each additional tenant receives a dedicated VLAN and a corresponding firewall policy. The physical infrastructure remains shared.

Dynamic VLAN Assignment via 802.1X and RADIUS

Historically, network engineers created a separate SSID for each tenant. This approach degrades performance. Every SSID broadcasts management frames (beacons) at the lowest basic mandatory data rate to ensure legacy devices can connect. Broadcasting six or seven SSIDs on a single access point can consume 20% to 30% of available wireless airtime before any user data is transmitted. In a dense multi-tenant building, this is unacceptable.

The modern standard is Dynamic VLAN Assignment. You broadcast a single secure SSID using IEEE 802.1X authentication. When a user connects, their device (the supplicant) exchanges credentials with a RADIUS server via the access point (the authenticator). The RADIUS server validates the credentials against an identity provider - Microsoft Entra ID, Okta, or Google Workspace - and sends an Access-Accept message back to the access point. This message includes three IETF standard RADIUS attributes:

Tunnel-Type (attribute 64): set to VLAN
Tunnel-Medium-Type (attribute 65): set to 802
Tunnel-Private-Group-ID (attribute 81): the specific VLAN ID for that user's organisation

The access point receives these attributes and dynamically places the user's traffic into their dedicated VLAN. A Tenant A employee and a Tenant B employee connect to the same SSID. Their traffic is completely isolated at Layer 2. The switch handles them as if they were plugged into entirely separate physical networks.

For guest segments, route traffic through a dedicated guest VLAN to a captive portal. Purple's Guest WiFi platform handles GDPR-compliant consent management, secure onboarding, and WiFi Analytics on an isolated segment with zero routing access to corporate networks. For a broader overview of access control architecture, see our guide to network access control systems .

WPA3-Enterprise and encryption standards

WPA3-Enterprise is the recommended encryption standard for multi-tenant deployments. It provides 192-bit security mode, eliminates the vulnerabilities in WPA2's four-way handshake, and mandates Protected Management Frames (PMF) under IEEE 802.11w. For environments handling payment card data or sensitive corporate information, WPA3-Enterprise with EAP-TLS (certificate-based mutual authentication) eliminates credential theft vectors entirely.

For guest segments where certificate deployment is impractical, WPA3-SAE (Simultaneous Authentication of Equals) provides forward secrecy, ensuring that a compromised session key does not expose historical traffic.

RF planning in high-density environments

Co-channel interference (CCI) is the primary cause of poor WiFi performance in multi-tenant office buildings. When adjacent access points broadcast on the same frequency channel, devices must wait for clear airtime before transmitting. In a building with multiple tenants and high device density, unplanned channel allocation creates a congested RF environment that no amount of bandwidth can fix.

An active, on-site RF site survey is mandatory before deployment. Vendor coverage maps are optimistic. You need actual signal measurements in the physical space, accounting for wall materials, floor construction, and the RF environment from neighbouring buildings.

The 2.4 GHz band provides three non-overlapping channels (1, 6, and 11) in most regulatory domains. The 5 GHz band offers significantly more capacity. WiFi 6E extends into the 6 GHz band, providing clean spectrum largely free from legacy device interference. For new multi-tenant deployments, specifying WiFi 6E capable access points from Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi provides the spectrum headroom required for dense environments.

IoT isolation

Modern office buildings contain building management systems, HVAC controllers, smart lighting, access control, and CCTV. These devices are notoriously difficult to patch and represent a significant attack surface. They must be isolated on a dedicated VLAN with strict egress filtering, permitting outbound communication only to their designated management platforms. Zero routing access to any tenant VLAN. Zero routing access to the guest VLAN. This is non-negotiable from both a security and GDPR perspective.

Implementation guide

Step 1: Design your logical architecture before touching hardware. Map your tenant count, traffic classes (corporate, guest, IoT, payment, management), and assign VLANs. Document your IP addressing scheme. Define your inter-VLAN routing policy: what can communicate with what, and what is absolutely prohibited.

Step 2: Commission an active RF site survey. Do not rely on vendor coverage maps. You need actual signal measurements in the physical space to inform AP placement and channel allocation.

Step 3: Configure your core firewall with a Default-Deny policy. Block all inter-VLAN routing by default. Add only explicit, port-specific exceptions. Every inter-VLAN path must be justified and documented.

Step 4: Disable VLAN 1 on all trunk ports. Change the native VLAN on trunk ports to an unused, non-routable VLAN ID. This prevents VLAN hopping attacks that exploit the default native VLAN.

Step 5: Validate trunk port configurations. Explicitly permit all required VLAN IDs on every trunk link in the path from access point to distribution layer. Missing VLAN tags cause silent traffic drops that are time-consuming to diagnose.

Step 6: Deploy centralised cloud management. Platforms from Cisco Meraki, HPE Aruba, Juniper Mist, and Ruckus provide per-SSID bandwidth policies, per-tenant reporting, and integration with your RADIUS infrastructure. The operational overhead of managing a distributed AP estate without a controller is unsustainable at scale.

Step 7: Set DHCP lease times per segment. Corporate VLANs: 8 to 24 hours. Guest WiFi VLAN: 1 to 2 hours. Short lease times on guest segments prevent IP address exhaustion in high-turnover environments.

Step 8: Isolate the management plane. Your management VLAN must be completely isolated from all tenant and guest VLANs. Apply strict ACLs to management traffic. If a tenant can reach your management plane, you have a critical security vulnerability.

Best practices

The following table summarises the key configuration standards for a compliant multi-tenant WiFi deployment.

Control	Standard	Rationale
VLAN segmentation	IEEE 802.1Q	Layer 2 isolation between tenants
Authentication	IEEE 802.1X with WPA3-Enterprise	Eliminates credential theft vectors
Dynamic VLAN Assignment	RADIUS with Tunnel attributes	Reduces SSID count, preserves airtime
Guest onboarding	Captive portal with GDPR consent	Compliance and data collection
IoT isolation	Dedicated VLAN with egress ACLs	Limits attack surface from unpatched devices
RF planning	Active site survey	Mitigates co-channel interference
Roaming	802.11r Fast BSS Transition	Seamless handoff across APs
Native VLAN	Non-routable, unused VLAN ID	Prevents VLAN hopping attacks

For hospitality deployments, guest VLAN isolation is critical. For retail environments, POS terminal isolation on a dedicated VLAN directly reduces PCI DSS audit scope. For transport hubs and healthcare facilities, the same segmentation principles apply, with additional attention to the volume of concurrent connections and the diversity of device types.

For venues considering satellite-based WAN uplinks, Purple's guide on how to set up a captive portal on Starlink covers the specific considerations for remote and maritime environments.

Troubleshooting and risk mitigation

Silent traffic drops. The most common failure mode in multi-tenant deployments. Caused by missing VLAN tags on trunk ports. A user authenticates successfully via 802.1X, the RADIUS server assigns them to VLAN 40, but VLAN 40 is not permitted on the trunk port. The traffic drops. The user receives no IP address. Document trunk configurations meticulously and validate them during commissioning.

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 SSID count to no more than four per radio. Use Dynamic VLAN Assignment via RADIUS attributes rather than separate SSIDs to serve multiple tenants.

Management plane exposure. If your management VLAN is not isolated, a tenant who gains access to it can modify AP configurations, disrupt service, or intercept management traffic. Use out-of-band management where possible. Apply strict ACLs to all management interfaces.

IoT device proliferation. Building operators frequently add IoT devices without informing the network team. Implement network access control (NAC) policies that require explicit authorisation before any new device receives an IP address on the IoT VLAN.

DHCP exhaustion on guest VLANs. In high-turnover environments, devices hold DHCP leases after disconnecting. A /24 subnet provides 254 addresses. In a busy conference centre or coworking space, this exhausts quickly. Set lease times to 1 to 2 hours and size your guest VLAN subnet to accommodate peak concurrent device counts.

ROI and business impact

A properly segmented multi-tenant WiFi architecture delivers measurable outcomes across three dimensions.

Compliance cost reduction. Isolating POS and payment terminals on a dedicated VLAN with strict firewall controls reduces PCI DSS audit scope by approximately 70%, based on Purple's own deployment data. This directly reduces annual audit costs and the IT team time required for compliance documentation.

Operational efficiency. Centralised cloud management reduces the OpEx associated with managing a distributed AP estate. Zero-touch provisioning, global policy enforcement, and per-tenant reporting eliminate the need for on-site configuration changes. New tenant onboarding reduces from days to hours.

Revenue generation. A secure, high-performance network allows building operators to monetise connectivity as a service. Tiered bandwidth packages, per-tenant SLAs, and analytics-driven insights transform WiFi from a cost centre into a revenue line. Purple operates across 80,000+ live venues and has processed 440 million logins in 2024 (Purple internal data, 2024), providing the analytics infrastructure to support this model at scale.

For further reading on how WiFi connectivity supports broader digital inclusion goals, see our piece on World WiFi Day 2026 . For a primer on WAN architecture considerations relevant to multi-site deployments, see our WAN computer definition guide .

Key Definitions

IEEE 802.1Q

The networking standard that defines VLAN tagging for Ethernet frames. It adds a 4-byte tag to each frame containing a 12-bit VLAN Identifier (VID), allowing switches to maintain multiple isolated broadcast domains over shared physical infrastructure.

The foundational protocol for multi-tenant network segmentation. Every enterprise switch and access point supports 802.1Q. Without it, logical isolation between tenants is impossible.

Dynamic VLAN Assignment

A method where a RADIUS server assigns a specific VLAN to a user or device upon successful 802.1X authentication, using IETF RADIUS attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) to instruct the access point which VLAN to place the user into.

The standard approach for serving multiple tenants from a single SSID. Eliminates SSID proliferation and preserves wireless airtime while maintaining full Layer 2 isolation between tenants.

IEEE 802.1X

The IEEE standard for port-based Network Access Control (PNAC). It defines a three-party authentication model: the supplicant (client device), the authenticator (access point or switch), and the authentication server (RADIUS). The authenticator blocks all traffic until the supplicant is authenticated.

The authentication framework used to enforce Dynamic VLAN Assignment. Required for WPA3-Enterprise deployments. Integrates with identity providers including Microsoft Entra ID, Okta, and Google Workspace.

RADIUS

Remote Authentication Dial-In User Service. A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management. In WiFi deployments, the RADIUS server validates user credentials and returns VLAN assignment attributes to the access point.

The server infrastructure that enforces Dynamic VLAN Assignment. Can be deployed on-premises or as a cloud service. Integrates with identity providers via LDAP, SAML, or SCIM.

Co-channel interference (CCI)

Interference caused when two or more access points broadcast on the same frequency channel within range of each other. Devices must wait for clear airtime before transmitting, reducing effective throughput for all users on that channel.

The primary cause of poor WiFi performance in dense multi-tenant buildings. Mitigated through active RF site surveys and careful channel allocation across the 2.4 GHz, 5 GHz, and 6 GHz bands.

Native VLAN

The VLAN on an 802.1Q trunk port that carries untagged traffic. By default, most switches use VLAN 1 as the native VLAN, creating a well-known attack vector for VLAN hopping.

A security risk that must be addressed in every multi-tenant deployment. Change the native VLAN on all trunk ports to an unused, non-routable VLAN ID to prevent VLAN hopping attacks.

Captive portal

A web page that a user must interact with before being granted network access. In WiFi deployments, the user connects to an open or WPA2-Personal SSID, is redirected to a splash page for authentication or terms acceptance, and is then granted internet-only access on an isolated VLAN.

The standard onboarding mechanism for Guest WiFi segments. Enables GDPR-compliant consent collection, identity verification, and analytics. Must be deployed on a VLAN with zero routing access to corporate or tenant networks.

WPA3-Enterprise

The latest WiFi security protocol for enterprise networks, standardised by the Wi-Fi Alliance. Provides 192-bit cryptographic strength (CNSA suite), requires 802.1X authentication, mandates Protected Management Frames (PMF) under IEEE 802.11w, and eliminates the vulnerabilities in WPA2's four-way handshake.

The recommended encryption standard for multi-tenant corporate WiFi segments. Required for environments handling payment card data or sensitive corporate information. Supported by all major enterprise AP vendors.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. A certificate-based 802.1X authentication method that requires both the client and the RADIUS server to present X.509 digital certificates, providing mutual authentication and eliminating password-based credential theft.

The most secure 802.1X authentication method. Used in high-security multi-tenant environments where credential theft is a primary concern. Requires a Public Key Infrastructure (PKI) to issue and manage client certificates.

MAC Authentication Bypass (MAB)

A fallback authentication method that uses a device's MAC address as its identity when the device does not support 802.1X. The RADIUS server looks up the MAC address and assigns the device to a predefined VLAN.

Used for IoT devices, printers, and other equipment that cannot perform 802.1X authentication. Because MAC addresses can be spoofed, MAB must always be combined with strict firewall rules on the assigned VLAN.

Worked Examples

A 350-room hotel group with 12 properties needs to secure its network. Currently, guest smartphones, staff laptops, POS terminals, and building management systems all share a single flat network. The IT team spends 40 hours monthly on PCI DSS compliance documentation because the entire network is in scope. The CTO wants to reduce compliance overhead and improve security posture before the next audit.

Deploy a four-VLAN architecture using IEEE 802.1Q across all 12 properties via a centralised cloud management platform. Assign VLANs as follows: VLAN 10 for Staff Corporate (802.1X authenticated, routed to internal resources and internet), VLAN 20 for Guest WiFi (captive portal, internet only), VLAN 30 for POS Terminals (802.1X authenticated, routed only to payment processor endpoints), and VLAN 40 for IoT and BMS (MAC Authentication Bypass, egress to BMS management platform only). Configure a Default-Deny firewall policy between all VLANs. Integrate Purple's Guest WiFi platform on VLAN 20 for GDPR-compliant consent management and analytics. Validate trunk port configurations on every switch in the path during commissioning.

Examiner's Commentary: This approach reduces PCI DSS audit scope by approximately 70% by isolating the POS segment. The strict firewall policy prevents lateral movement from a compromised guest device to payment infrastructure. The IT team recovers the 40 hours monthly previously spent on compliance documentation. The centralised cloud management platform enables consistent policy enforcement across all 12 properties without on-site visits.

A coworking operator manages a 15-floor office building with 40 independent member companies. Each company needs its own isolated WiFi network. The current architecture broadcasts a separate SSID per company, resulting in 40 SSIDs per floor. WiFi performance is poor across the building despite a 10 Gbps fibre uplink. The network team wants to resolve performance issues without replacing hardware.

Consolidate to a single secure SSID using WPA3-Enterprise and IEEE 802.1X authentication. Deploy a RADIUS server integrated with the building's identity provider (Microsoft Entra ID or Okta). Configure the RADIUS server to return Dynamic VLAN Assignment attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) for each authenticated user, placing them into their company's dedicated VLAN. Retain a separate Guest WiFi SSID with a captive portal for visitor access. This reduces the SSID count from 40 to two per radio. Conduct an active RF site survey to validate channel allocation and AP placement following the SSID consolidation.

Examiner's Commentary: Reducing the SSID count from 40 to two per radio eliminates the beacon management overhead that was consuming 20% to 30% of available airtime. Average client throughput increases significantly. The Dynamic VLAN Assignment approach maintains full Layer 2 isolation between all 40 member companies without any change to the physical infrastructure. The RF site survey ensures channel allocation is optimised following the configuration change.

Practice Questions

Q1. You are deploying WiFi for a new mixed-use building with 20 independent retail tenants on the ground floor and 10 office tenants on floors 1 to 5. The building owner wants each tenant to have their own secure WiFi network, plus a shared Guest WiFi network for visitors. What is the most efficient architectural approach, and what is the maximum number of SSIDs you should broadcast per access point?

Hint: Consider the impact of broadcasting 30 separate SSIDs on wireless airtime. Think about how Dynamic VLAN Assignment can serve multiple tenants from a single SSID.

View model answer

Deploy a single secure SSID using WPA3-Enterprise and IEEE 802.1X authentication for all corporate tenants. Use a RADIUS server integrated with the building's identity provider to perform Dynamic VLAN Assignment, placing each tenant's devices into their own isolated VLAN upon authentication. Deploy a second SSID for Guest WiFi with a captive portal. This results in two SSIDs per radio, well within the four-SSID maximum. Each of the 30 tenants receives a dedicated VLAN with a corresponding Default-Deny firewall policy. The Guest WiFi VLAN has zero routing access to any tenant VLAN.

Q2. During a post-deployment audit of a multi-tenant office building, you discover that traffic from the Guest WiFi VLAN (VLAN 30) can successfully ping devices on the IoT VLAN (VLAN 40). Both are on separate VLANs. What is the most likely cause, and what is the immediate remediation step?

Hint: VLANs separate broadcast domains at Layer 2. What handles traffic routing between different subnets at Layer 3?

View model answer

The core router or firewall is missing a Default-Deny inter-VLAN routing policy. By default, routers pass traffic between all connected subnets. The immediate remediation is to configure an explicit Deny rule on the firewall blocking all traffic from VLAN 30 to VLAN 40. Audit all other inter-VLAN routing policies at the same time to confirm no other unintended paths exist. The long-term fix is to implement a Default-Deny policy across all VLANs with only explicit, documented exceptions permitted.

Q3. A tenant in a multi-tenant office building reports that their devices can authenticate to the WiFi network successfully, but they never receive an IP address and cannot access the internet. Other tenants on the same access points are working normally. The RADIUS server logs show successful authentication and a VLAN 50 assignment for the affected tenant. What is the first configuration you should check?

Hint: Think about the physical path that VLAN-tagged traffic takes from the access point to the core switch. What must be configured on that path for VLAN 50 traffic to pass?

View model answer

Check the 802.1Q trunk port configuration on the switch port connected to the access point. Verify that VLAN 50 is explicitly listed as an allowed VLAN on the trunk. If VLAN 50 is not permitted on the trunk, the switch drops all VLAN 50 tagged frames, and the client never receives a DHCP response. Add VLAN 50 to the trunk's allowed VLAN list and verify the client receives an IP address. Also confirm that a DHCP scope exists for the VLAN 50 subnet.

Q4. A building operator wants to add 50 new IoT sensors to monitor energy consumption across a multi-tenant office building. The sensors do not support 802.1X authentication. How should you onboard these devices securely, and what firewall policy should apply to their VLAN?

Hint: Consider the authentication method available for devices that cannot perform 802.1X, and the security implications of that method.

View model answer

Use MAC Authentication Bypass (MAB) to onboard the IoT sensors. Register each sensor's MAC address in the RADIUS server and configure the server to assign authenticated MAC addresses to the dedicated IoT VLAN (e.g., VLAN 40). Because MAC addresses can be spoofed, apply strict egress firewall rules to VLAN 40: permit outbound traffic only to the designated energy management platform IP addresses, and block all other outbound and all inbound traffic. Apply strict ACLs to prevent any device on VLAN 40 from initiating connections to any tenant VLAN or the management VLAN.

Continue reading in this series

Mean time to innocence: how to prove it's not the WiFi

Mean time to innocence (MTTI) is the critical metric defining how long IT teams spend proving a network issue is not their fault. This guide details a five-step observability methodology to eliminate the blame game in multi-tenant environments, replacing finger-pointing with shared evidence to drive down mean time to resolution (MTTR).

Mean time to innocence: how to prove it's not the WiFi

Legal and Compliance Requirements for Shared WiFi Infrastructure

This authoritative technical reference guide outlines the critical legal, regulatory, and architectural requirements for deploying and managing shared WiFi infrastructure. It provides IT managers, network architects, and venue operators with actionable frameworks for ensuring robust data protection, strict payment security compliance, and high-performance tenant isolation using enterprise standards.