How to Set Up Guest WiFi: The Enterprise Network Segmentation Guide

Speak in a confident, authoritative British English accent with a senior consultant briefing tone - measured, clear, and conversational. Not a lecture, but a direct expert briefing. Pace is steady with natural pauses between sections: Welcome to the Purple technical briefing series. I'm going to walk you through exactly how to set up a guest WiFi network that is properly segmented, secure, and commercially useful. This isn't a beginner's tutorial. You're an IT manager, a network architect, or a CTO, and you need to make a decision this quarter. So let's get straight to it. [medium pause] The problem most venues have isn't that they lack WiFi. It's that they've got one flat network where guests, staff, and IoT devices all share the same broadcast domain. That's a compliance risk, a security risk, and frankly, a missed commercial opportunity. A hotel with 200 rooms, a retail chain with 50 stores, a stadium hosting 40,000 fans - all of them need the same fundamental thing: proper network segmentation. [medium pause] Let's talk about what segmentation actually means in practice. At its core, you're creating logically separate networks on the same physical infrastructure using VLANs - Virtual Local Area Networks. A VLAN, defined under IEEE 802.1Q, tags Ethernet frames so that traffic from different network segments stays isolated at the data link layer, even when it traverses the same physical switch or access point. You assign each segment a VLAN ID - say, VLAN 10 for staff, VLAN 20 for IoT devices, VLAN 30 for guests - and you configure your managed switches and access points to enforce that separation. [medium pause] Now, the critical question: how many SSIDs do you actually need? The answer for most enterprise venues is three. One for guests, one for staff, one for IoT. Each SSID maps to its own VLAN. Guests get internet access only, with no route to your corporate network. Staff authenticate via 802.1X against a RADIUS server - we'll come back to that - and get access to internal resources. IoT devices, your CCTV cameras, your HVAC sensors, your smart displays, sit on their own isolated segment with tightly controlled egress rules. If you want to go deeper on the three-SSID model, Purple has a detailed guide on exactly this architecture. [medium pause] Let's talk authentication, because this is where most deployments get it wrong. For guest WiFi specifically, you have four realistic options. First, open network with a captive portal - the most common approach, and the right one for venues that need to capture consent and first-party data under GDPR. The guest connects, lands on a branded splash page, authenticates via social login, email, or SMS, and you capture a verified identity. Second, WPA2-PSK - a shared passphrase. Simple, but it gives you no individual identity, no consent mechanism, and you can't revoke access for a specific device without changing the password for everyone. Third, WPA3-SAE, which is the modern successor to WPA2 and eliminates the offline dictionary attack vulnerability. Fourth, 802.1X with RADIUS - the gold standard for staff networks, where each user authenticates individually against a directory like Microsoft Entra ID or Okta, and gets a unique session credential. For guest WiFi, the captive portal approach with WPA3 encryption on the underlying SSID is the right combination: you get identity capture, consent, and modern encryption. [medium pause] Now, RADIUS. IEEE 802.1X is the port-based access control standard. It defines a three-party model: the supplicant - that's the device trying to connect - the authenticator, which is your access point or switch, and the authentication server, which is your RADIUS server. When a staff member connects, their device sends credentials via EAP - the Extensible Authentication Protocol. EAP-TLS uses mutual certificate-based authentication, the most secure option. PEAP wraps EAP in a TLS tunnel and lets you use username and password credentials against Active Directory or Entra ID. For most enterprise deployments, PEAP-MSCHAPv2 against Microsoft Entra ID or Okta is the practical choice. It's well-supported across all major hardware - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi - and integrates cleanly with your existing identity provider. [medium pause] Let me walk you through a concrete implementation. Take a 200-room hotel. You've got Cisco Meraki access points deployed across guest rooms, corridors, conference facilities, and back-of-house. You configure three SSIDs on the Meraki dashboard. The guest SSID - let's call it the hotel name - is open, tagged to VLAN 30, with a captive portal redirect to Purple's splash page. Guests authenticate via email or social login. Purple captures their consent, stores the profile, and triggers a welcome email automatically. The staff SSID is WPA2-Enterprise, tagged to VLAN 10, authenticating against the hotel's Microsoft Entra ID tenant via RADIUS. The IoT SSID is a hidden network, WPA2-PSK with a strong random passphrase, tagged to VLAN 20, with firewall rules that permit only the specific outbound ports each device type needs. On the Meraki firewall, you add a layer 3 rule that explicitly blocks inter-VLAN traffic. Guests cannot reach the staff network. Staff cannot reach the IoT segment unless you explicitly permit it. And critically, a compromised IoT device - say, a smart TV with an unpatched vulnerability - cannot pivot to your PMS or your payment systems. [medium pause] That last point matters enormously for PCI-DSS compliance. If your payment card processing systems sit on the same network as guest WiFi, you're in scope for PCI-DSS across your entire WiFi infrastructure. Proper VLAN segmentation, combined with documented firewall rules and access controls, is the primary mechanism for reducing your PCI-DSS scope. The PCI Security Standards Council is explicit on this: network segmentation is not a PCI-DSS requirement, but it reduces the number of system components in scope. Get it right and you can dramatically simplify your annual assessment. [medium pause] Let's talk about a second scenario: a retail chain with 50 stores. Each store has a mix of guest shoppers, staff on handheld devices for inventory and POS, and IoT endpoints including digital signage and environmental sensors. The challenge here is scale and consistency. You cannot manually configure each store's network. You need a cloud-managed platform that lets you push a consistent configuration template across all 50 sites from a single dashboard. HPE Aruba Central, Cisco Meraki Dashboard, and Juniper Mist all support this model. You define your VLAN structure and SSID configuration once, push it as a template, and each site inherits the correct segmentation automatically. Purple integrates with all of these platforms as a cloud overlay - meaning you don't replace your existing hardware, you add Purple's captive portal and analytics layer on top. Across those 50 stores, you get unified guest data, consistent branding, and centralised consent management. Purple operates across 80,000 live venues and has processed 440 million logins in 2024 alone, so the platform is built for exactly this kind of multi-site scale. [medium pause] Now let me cover the implementation pitfalls I see most often. First: forgetting to enable client isolation on the guest SSID. Client isolation prevents one guest device from communicating directly with another device on the same SSID. Without it, a guest with malicious intent can scan and attack other guests' devices. Enable it. Every major platform supports it. Second: misconfiguring the DHCP scope. Each VLAN needs its own DHCP scope with the correct gateway and DNS settings. A common error is pointing guest VLAN DHCP at the corporate DNS server, which leaks internal hostnames. Use a public DNS resolver - or better, a filtered DNS service - for guest traffic. Third: not testing inter-VLAN routing after deployment. Configure your VLANs, then actually test from a guest device that you cannot reach the staff network. Use a tool like nmap or simply try to browse to an internal IP. Document the test result. Fourth: neglecting bandwidth management. Guest WiFi on a flat network can saturate your uplink and degrade staff and operational traffic. Apply per-client and per-SSID bandwidth limits. On Cisco Meraki, this is a single setting per SSID. On HPE Aruba, you use application-aware traffic shaping policies. [medium pause] On GDPR: if you're operating in the UK or EU, your captive portal must present a clear, affirmative consent mechanism before you collect any personal data. Pre-ticked boxes are not valid consent under UK GDPR. The consent must be granular - separate opt-ins for marketing communications versus network access logging. Purple's Conscious-Choice opt-ins are designed specifically for this: the guest makes an explicit, informed choice, and Purple stores the consent record with a timestamp and the specific consent text version they agreed to. That audit trail is what you need if the ICO comes knocking. [medium pause] Right, let's do a rapid-fire Q&A on the questions I get asked most often. [short pause] Do I need a separate physical access point for each SSID? No. Modern enterprise access points support multiple SSIDs on a single radio. The practical limit is around three to four SSIDs per radio before you start degrading airtime efficiency due to management frame overhead. Three SSIDs - guest, staff, IoT - is the right number. [short pause] Can I use a consumer-grade router for guest WiFi? Not in an enterprise venue. Consumer routers don't support VLAN tagging, 802.1X, or cloud management. You need managed hardware. Ubiquiti UniFi is the entry point for small venues; Cisco Meraki, HPE Aruba, or Ruckus for anything with more than 20 access points. [short pause] How do I handle Passpoint and OpenRoaming? Passpoint - also known as Hotspot 2.0, defined under IEEE 802.11u - allows devices to automatically connect to a WiFi network using credentials already on the device, without a captive portal. OpenRoaming is the global federation built on Passpoint. Purple supports OpenRoaming under the Connect plan, acting as the identity provider. For venues like airports and transport hubs, this is increasingly the right answer for seamless passenger connectivity. [short pause] What about DNS filtering for guest networks? Mandatory. A filtered DNS resolver blocks malware command-and-control domains, phishing sites, and inappropriate content. It also gives you a log of DNS queries for security monitoring. Purple's Shield add-on includes DNS filtering as part of the guest network security stack. [medium pause] To summarise: set up your guest WiFi network with three VLANs - guest on VLAN 30, staff on VLAN 10, IoT on VLAN 20. Use a captive portal with explicit GDPR consent for guests. Authenticate staff via 802.1X against your identity provider. Isolate IoT devices with strict egress rules. Enable client isolation on the guest SSID. Apply bandwidth limits. Test inter-VLAN routing after every configuration change. And use a cloud-managed platform so you can enforce consistent configuration across every site from one place. [medium pause] If you want to go further, Purple's guest WiFi platform sits on top of your existing hardware - whether that's Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi - and adds the captive portal, consent management, analytics, and marketing automation layer that turns your WiFi infrastructure into a first-party data asset. We're at purple.ai. The full written guide with architecture diagrams, worked examples, and configuration checklists is linked in the show notes. Thanks for listening.