The Enterprise Guide to Setting Up Guest WiFi: Security, Segmentation, and Speed

Speak in British English with a confident, authoritative, and conversational tone - like a senior network consultant briefing a CTO before a board meeting. Measured pace, clear diction, occasional dry wit. Professional but not stiff: Welcome to the Purple Technical Brief. I'm your host, and today we're covering something that sits right at the intersection of IT headache and genuine business opportunity: setting up guest WiFi properly. Not the "plug in a router and hope for the best" version. The enterprise version. The one that keeps your auditors happy, your guests connected, and your corporate network intact. [short pause] Let's start with the context. Guest WiFi is no longer a nice-to-have. It's infrastructure. Purple's platform runs across more than 80,000 live venues - from Premier Inn hotels to Manchester Airports Group, from Harrods to McDonald's. And the one thing every single one of those deployments has in common? The moment guest WiFi goes down, or gets breached, or fails a compliance audit, it becomes the most visible IT failure in the building. So let's make sure yours doesn't. [short pause] Section one: the architecture. What are we actually building? A properly designed guest WiFi deployment has three distinct network zones, sometimes four. Zone one is your guest network - internet access only, completely isolated from your corporate infrastructure. Zone two is your staff network - authenticated, encrypted, with access to internal resources. Zone three is your IoT network - building management systems, printers, sensors, all isolated from both guests and staff. And if you're in retail or hospitality, zone four is your corporate LAN, which contains your point-of-sale systems and anything touching cardholder data. The critical word here is isolated. Not separated by a password. Not on a different SSID that happens to share the same subnet. Genuinely isolated, at the network layer, using VLANs - Virtual Local Area Networks - with stateful firewall rules between each zone. [short pause] Why does this matter so much? Two words: PCI-DSS. PCI-DSS - the Payment Card Industry Data Security Standard - requires that any network carrying cardholder data is completely segregated from any network that guests can access. If your guest WiFi and your point-of-sale terminals share the same network segment, your entire estate falls into PCI scope. That means quarterly external vulnerability scans, annual penetration tests, and a compliance burden that costs far more than the VLAN configuration you skipped. The fix is straightforward. VLAN 10 for guests. VLAN 20 for staff. VLAN 30 for IoT. VLAN 1 for your corporate LAN. Firewall rules that explicitly deny any traffic from VLAN 10 to VLANs 20 and 1. Done. Your PCI scope shrinks dramatically. [short pause] Now let's talk about encryption. The standard you should be deploying today is WPA3 - the WiFi Protected Access 3 standard, ratified by the Wi-Fi Alliance. WPA3 replaces WPA2 and addresses two critical vulnerabilities: it eliminates the KRACK attack vector, and it introduces Simultaneous Authentication of Equals - SAE - which prevents offline dictionary attacks against captured handshakes. For guest networks specifically, WPA3 in Enhanced Open mode, also called OWE - Opportunistic Wireless Encryption - is worth understanding. OWE encrypts traffic between each device and the access point without requiring a password. Guests connect seamlessly, but their traffic is encrypted in transit. No more passive sniffing on open networks. For your staff network, you want WPA3 Enterprise with 802.1X authentication. 802.1X is the IEEE standard for port-based network access control. It uses a RADIUS server - Remote Authentication Dial-In User Service - to authenticate each device individually before granting network access. The device presents credentials, the RADIUS server validates them against your identity provider - Microsoft Entra ID, Okta, or Google Workspace are the canonical choices - and only then does the access point open the port. [short pause] This brings us to authentication methods. Within 802.1X, you have several EAP - Extensible Authentication Protocol - variants. EAP-TLS uses mutual certificate-based authentication. Both the server and the client present certificates. It's the most secure option and the one recommended for any environment where you're deploying managed devices. EAP-TTLS and PEAP - Protected EAP - use a server-side certificate with username and password credentials from the client. They're easier to deploy but slightly less secure. For guest networks, you're not using 802.1X. You're using a Captive Portal - a web page that intercepts the guest's browser session and requires them to authenticate before granting internet access. The Captive Portal is where GDPR comes in. [short pause] GDPR - the General Data Protection Regulation - requires that any personal data you collect at the Captive Portal has a lawful basis. For guest WiFi, that basis is almost always consent. And consent under GDPR must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count. Bundling marketing consent with network access doesn't count. What does count is what Purple calls conscious-choice opt-ins. The guest sees a clear, honest choice: connect to WiFi, and optionally, tick this box if you'd like to receive marketing communications. The network access and the marketing consent are separate decisions. That's GDPR-compliant. That's also, incidentally, why the data you collect is higher quality - because the people who opted in actually wanted to. Purple holds ISO 27001, GDPR, CCPA, and Cyber Essentials certifications. That means when you deploy Purple as your captive portal layer, the compliance framework is already built in. You're not starting from scratch. [short pause] Section two: the technical deep dive. Let's get specific about hardware and deployment. Purple is hardware-agnostic. It deploys as a cloud overlay onto your existing access points. The canonical hardware list covers Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. If you're running any of those, you configure your guest SSID to point at Purple's RADIUS or captive portal endpoint, and the platform handles authentication, data capture, and analytics from there. The deployment sequence for a typical hotel or conference centre looks like this. First, you configure your VLANs on the core switch. Second, you create your SSIDs on the wireless controller - one for guests, one for staff, one for IoT. Third, you map each SSID to its corresponding VLAN. Fourth, you configure your firewall rules to enforce zone isolation. Fifth, you point your guest SSID at Purple's captive portal. Sixth, you configure your staff SSID to authenticate against your RADIUS server, which in turn queries your identity provider. That's the skeleton. The flesh is in the details. [short pause] On bandwidth management: guest networks need QoS - Quality of Service - policies to prevent any single device from saturating your uplink. A sensible starting point is 10 megabits per second download and 5 megabits per second upload per device, with a hard cap at the SSID level. For venues with high-density deployments - stadiums, conference centres - you'll want to look at band steering to push capable devices onto the 5 gigahertz band, and potentially 6 gigahertz if your access points support WiFi 6E. On DNS: your guest VLAN should use a DNS resolver that filters malicious domains. This is not optional if you're in healthcare or education - it's a safeguard against your network being used to access harmful content. Purple's Shield add-on provides this at the platform level. [short pause] Section three: implementation pitfalls and how to avoid them. Pitfall one: flat networks. I still see this in retail environments. One SSID, one subnet, guests and point-of-sale terminals on the same broadcast domain. This fails PCI-DSS requirement 1.3, which mandates network segmentation between untrusted networks and the cardholder data environment. Fix it with VLANs before your next QSA visit. Pitfall two: self-signed certificates on captive portals. When a guest connects to your network and their browser shows a certificate warning, they either click through - training them to ignore security warnings - or they leave. Use a valid TLS certificate from a recognised certificate authority on your captive portal. Let's Encrypt is free. There's no excuse. Pitfall three: no session timeout. Guest sessions should expire. A 24-hour session timeout is reasonable for hospitality. A 4-hour timeout is appropriate for retail. Without a timeout, a device connected six months ago still has an active session - and potentially still appears in your analytics as a "visitor." Pitfall four: missing access logs. GDPR and most national telecommunications regulations require you to retain connection logs - IP address, MAC address, timestamp, session duration - for a defined period. Purple retains these automatically and exports them in formats compatible with law enforcement requests. If you're running a DIY captive portal, make sure your logging is configured and your retention policy is documented. [short pause] Section four: rapid-fire questions. Do I need a separate SSID for IoT devices? Yes. IoT devices are the most common vector for lateral movement attacks. Isolate them. Can I use a single access point for guest and staff? Yes, if it supports multiple SSIDs mapped to different VLANs. Most enterprise access points do. Just make sure the trunk port on the switch is configured correctly. Does WPA3 break older devices? Some older devices don't support WPA3. Configure your SSID in WPA2/WPA3 transition mode to maintain backward compatibility while offering WPA3 to capable devices. What's the difference between Passpoint and a captive portal? Passpoint - also known as Hotspot 2.0 - allows devices to connect automatically using a pre-provisioned credential, with no captive portal interaction. It's ideal for frequent visitors or loyalty programme members. Purple supports Passpoint and OpenRoaming, which extends automatic connection across a federated network of participating venues. [short pause] Section five: summary and next steps. Here's what you should take away from this briefing. One: segment your network. Guest, staff, IoT, and corporate LAN on separate VLANs with explicit firewall rules between them. This is the single most impactful thing you can do for security and compliance. Two: deploy WPA3 where your hardware supports it. WPA3 Enterprise for staff. WPA3 Enhanced Open or a captive portal for guests. Three: make your captive portal GDPR-compliant. Separate network access from marketing consent. Use conscious-choice opt-ins. Retain connection logs. Four: use a hardware-agnostic cloud overlay like Purple. It gives you a consistent guest experience across your estate, regardless of which access point vendor you're running. And it turns your guest WiFi from a cost centre into a source of first-party data. Five: measure it. Purple's analytics platform gives you footfall data, dwell time, return visit rates, and demographic insights - all derived from WiFi connection data. That's the kind of intelligence that justifies the infrastructure investment to a board that doesn't care about VLANs but does care about revenue. [short pause] If you want to go deeper on any of these topics, the full written guide is available on the Purple website. It covers VLAN configuration, RADIUS setup, GDPR data mapping, and worked examples from hospitality, retail, and stadium deployments. Thanks for listening to the Purple Technical Brief. We'll see you on the next one.