How to Securely Segment Staff and Guest WiFi Networks: Best Practices for Enterprise LANs

Speak in a confident, conversational British English tone - like a senior consultant briefing a client. Measured pace, authoritative but approachable. No filler words. --- INTRODUCTION AND CONTEXT (approximately 1 minute) --- Right, let's get into it. If you're responsible for a venue's network - whether that's a hotel, a retail chain, a stadium, or a local authority building - there's one question that comes up more than almost any other: how do you give guests decent WiFi without putting your corporate network at risk? The short answer is segmentation. But the longer answer - the one that actually gets you to a secure, compliant, manageable network - involves 802.1X authentication, VLAN isolation, cloud RADIUS, and a credential lifecycle that doesn't rely on someone remembering to change a shared password when a member of staff leaves. In the next ten minutes, I'm going to walk you through exactly how to architect and deploy a properly segmented network. We'll cover the technical foundations, the vendor-specific configuration steps for Cisco Meraki and Juniper Mist, two real-world implementation scenarios, and the pitfalls that catch most teams out. Let's go. --- TECHNICAL DEEP-DIVE (approximately 5 minutes) --- Let's start with the fundamentals. Network segmentation means keeping your staff traffic and your guest traffic on physically or logically separate networks, so that a guest device - or a compromised guest device - cannot reach your point-of-sale systems, your ERP, your CCTV infrastructure, or anything else on your corporate LAN. The standard way to do this at Layer 2 is with VLANs - Virtual Local Area Networks. You assign your staff SSID to one VLAN, say VLAN 10, and your guest SSID to another, say VLAN 20. Your managed switches and access points enforce that separation at the hardware level. A guest on VLAN 20 gets routed to the internet and nothing else. A staff member on VLAN 10 gets routed to the corporate LAN and the internet, based on whatever firewall rules you've defined. That's the basic model. But here's where most venues fall down: they use a shared passphrase - a PSK - for the staff network. Everyone knows it. It gets written on a Post-it note. It never changes. When someone leaves, the credential stays live. That is not segmentation. That is a false sense of security. The right approach for staff is 802.1X - pronounced "eight oh two dot one X" - which is the IEEE standard for port-based network access control. Instead of a shared passphrase, each staff member authenticates with their own identity credential - typically their corporate directory account from Microsoft Entra ID, Okta, or Google Workspace. The access point sends that authentication request to a RADIUS server, which validates it against your identity provider and either grants or denies access. No shared secret. No credential that survives a leaver. The authentication method that works best in most enterprise deployments is EAP-TTLS - Extensible Authentication Protocol Tunnelled Transport Layer Security. It creates an encrypted tunnel between the device and the RADIUS server, then authenticates inside that tunnel using PAP. This means credentials are never exposed over the air. Now, the RADIUS server itself is a critical component. Traditionally, you'd run your own on-premises RADIUS server - a Cisco ISE, a FreeRADIUS box, something like that. But increasingly, organisations are moving to cloud-native RADIUS, which removes the on-premises dependency, improves resilience, and simplifies management. Purple's SecurePass product does exactly this - it provides a cloud RADIUS service that your access points authenticate against over RadSec, which is RADIUS over TLS on port 2083. That gives you encrypted RADIUS traffic, not the traditional UDP-based RADIUS which sends attributes in the clear. For the guest side, the model is different. Guests don't have corporate directory accounts. They connect to a separate SSID - typically secured with a captive portal that collects a consent-based login, or via Passpoint, which is the Wi-Fi Alliance's Hotspot 2.0 standard that enables automatic, seamless authentication without a splash page. Purple's platform supports both. The guest SSID sits on its own VLAN, routes only to the internet, and is completely isolated from the staff network and the corporate LAN. Let me talk about Passpoint for a moment, because it's increasingly important. Passpoint - also known as Hotspot 2.0 or OpenRoaming - allows a device to automatically connect to a trusted network using a credential it already holds, such as a mobile carrier credential or an identity from the Purple app. The device and the network negotiate authentication using EAP-TTLS or EAP-TLS without the user having to interact with a splash page. For venues with high footfall - airports, stadiums, shopping centres - this dramatically improves the connection experience while maintaining security. Now let's talk about two specific hardware platforms: Cisco Meraki and Juniper Mist, because these are the two most common enterprise platforms we see in venues. On Cisco Meraki, you configure your staff SSID under Wireless, Access Control. You set security to Enterprise with my RADIUS server, WPA2 only, no splash page. You then add your RADIUS servers - in Purple's case, rad1-secure.purple.ai and rad2-secure.purple.ai, both on port 2083, with RadSec enabled. You also configure Hotspot 2.0 under Wireless, Hotspot 2.0 - enabling it, setting the operator name, domain list, and NAI realm with EAP-TTLS as the method. Full step-by-step details are in Purple's support documentation, which I'll reference at the end. On Juniper Mist, you go to Network, WLANs, add a new WLAN, set security type to WPA2 Enterprise 802.1X, enable Passpoint, and configure your authentication servers as RadSec pointing to Purple's infrastructure. You also need to install the RadSec certificate in Organisation Settings. Again, the exact configuration values and steps are in Purple's support article - I'd always recommend following the live documentation rather than hardcoding values from a podcast. The credential lifecycle piece is where Identity-Based Networks really earn their keep. When a staff member joins, their account in Microsoft Entra ID or Okta is provisioned, and they get WiFi access automatically. When they move roles, their access profile updates. When they leave - and this is the critical one - their account is deprovisioned, and Purple revokes their WiFi access in real time. No shared password to change. No manual process. No window of exposure. That's what Purple calls the joiners, movers, leavers workflow, or JML, and it's the difference between a network that's genuinely secure and one that just looks secure. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS (approximately 2 minutes) --- Right, let's talk about what goes wrong in practice, because there are a few failure modes I see repeatedly. The first is VLAN misconfiguration. You set up the SSIDs correctly, but the trunk ports on your switches aren't carrying both VLANs, or your inter-VLAN routing rules are too permissive. A guest on VLAN 20 ends up being able to ping devices on VLAN 10. Always test with a guest device after deployment - try to reach an internal IP address. If you can, your firewall rules need tightening. The second is RADIUS failover. If you only configure one RADIUS server and it becomes unreachable, staff can't authenticate. Always configure both rad1-secure and rad2-secure as primary and secondary. Purple's cloud RADIUS infrastructure is designed for high availability, but your access point needs to know about both endpoints. The third - and this is the one that causes the most operational pain - is not integrating with your identity provider from day one. Teams often start with local RADIUS accounts, intending to migrate to Entra ID or Okta later. That migration is painful. Do it right at the start. The JML automation alone justifies the effort. The fourth pitfall is treating the guest network as an afterthought. Your guest SSID needs GDPR-compliant consent collection, bandwidth management to prevent a single guest from saturating the link, and client isolation so guests can't see each other's devices. Purple's platform handles the consent and analytics side. Your access point handles client isolation - make sure it's enabled. On the compliance side: if you process card payments anywhere on the same physical network infrastructure, PCI DSS scope is a real concern. Proper VLAN segmentation, combined with a firewall that enforces no cross-VLAN traffic between the guest and payment networks, is the baseline. Your QSA will want to see evidence of that segmentation. Document your VLAN assignments, your firewall rules, and your access point configuration. --- RAPID-FIRE Q AND A (approximately 1 minute) --- A few questions I get asked regularly. Can I run staff and guest on the same access point? Yes - modern enterprise access points from Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, and others support multiple SSIDs with VLAN tagging on a single radio. You don't need separate hardware. Do I need WPA3? WPA3 is preferable for new deployments, particularly for the guest network, because it provides forward secrecy and protects against offline dictionary attacks. But WPA2 Enterprise with 802.1X is still strong for staff, and most enterprise hardware supports it. If your hardware supports WPA3, enable it. What about BYOD - staff using personal devices? This is where certificate-based authentication, or EAP-TLS, becomes valuable. You can issue device certificates via your MDM to managed devices, and restrict staff WiFi to certificate-authenticated devices only. Unmanaged personal devices get directed to a separate BYOD SSID with more restricted access. How does Purple's analytics platform work alongside segmentation? Purple collects first-party data from guest WiFi logins - with consent - and surfaces it through the WiFi Analytics platform. Staff traffic is separate and not subject to the same analytics collection. The two networks are architecturally distinct, which is exactly as it should be. --- SUMMARY AND NEXT STEPS (approximately 1 minute) --- To summarise. Secure staff and guest WiFi segmentation comes down to five things. One: separate VLANs for staff and guest traffic, enforced at the switch and access point level. Two: 802.1X with EAP-TTLS for staff authentication - no shared passphrases. Three: cloud RADIUS with RadSec for encrypted, resilient authentication infrastructure. Four: Passpoint or captive portal for guests, with GDPR-compliant consent collection. Five: identity provider integration for automated JML - so leavers lose access the moment their account is deprovisioned. If you're deploying on Cisco Meraki or Juniper Mist, Purple's support documentation has the exact configuration steps. If you're evaluating the broader platform - including SecurePass for staff identity, WiFi Analytics for guest insight, and the Purple app for seamless Passpoint connectivity - the place to start is purple.ai. That's it for today. If you found this useful, share it with your network architect or your venue operations director. And if you have a specific deployment scenario you'd like us to cover, get in touch.