Server RADIUS: a comprehensive guide for businesses

This guide provides IT managers, network architects, and CTOs with a definitive technical reference on server RADIUS authentication for enterprise WiFi. It covers the AAA framework, 802.1X architecture, EAP method selection, cloud versus on-premises deployment trade-offs, and dynamic VLAN assignment. Venue operators across hospitality, retail, events, and the public sector will find actionable implementation guidance, real-world case studies, and the decision frameworks needed to migrate from insecure pre-shared keys to a secure, identity-driven network access control architecture.

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

Listen to this guide

View podcast transcript

Welcome to the Purple Technical Briefing. I am your host, and over the next ten minutes we are going to cover one of the most important infrastructure decisions for any enterprise IT team: server RADIUS authentication. If you are an IT manager, a network architect, or a CTO responsible for WiFi at a hotel, a retail chain, a stadium, or a conference centre, this briefing is for you. We will cut through the jargon, explain the architecture clearly, and give you the practical insights you need to make informed decisions this quarter.

Let us start with the big picture. Why does any of this matter?

If you are still running your guest or staff WiFi on a single shared password, a Pre-Shared Key, you are operating with a significant and growing security risk. That password gets shared, written on receipts, photographed on whiteboards, and forwarded via messaging apps. Once it is out, you have no visibility into who is on your network, no ability to revoke access for a single user without disrupting everyone, and no audit trail if something goes wrong. For organisations subject to PCI DSS, GDPR, or HIPAA, this is not just a technical problem. It is a compliance liability.

Server RADIUS is the solution that the industry has converged on to address this. So let us understand exactly what it is and how it works.

RADIUS stands for Remote Authentication Dial-In User Service. The name is a historical artefact from the early days of dial-up internet, but the protocol has evolved significantly and remains the backbone of enterprise network access control today. At its core, a server RADIUS is a centralised system that manages network access using a framework called AAA: Authentication, Authorisation, and Accounting. These three pillars are the foundation of everything we will discuss today.

Authentication is the first pillar: verifying who someone is. Authorisation is the second: determining what they are allowed to do. And Accounting is the third: recording what they actually did.

Let us explore each one.

Authentication. When a user tries to connect to a WiFi network secured with WPA2-Enterprise or WPA3-Enterprise, their device, which we call the Supplicant, sends a connection request to the wireless access point. The access point, which we call the Authenticator, does not make the authentication decision itself. It acts as a relay, forwarding the request to the server RADIUS. The server then validates the user's identity against a configured identity source. This could be Microsoft Entra ID, Okta, Google Workspace, or a local user database. The identity source is the single source of truth for who is allowed on your network.

Authorisation. Once the user is authenticated, the server RADIUS does not just say yes and step aside. It also tells the access point exactly what to do with this user. It sends back a set of attributes, instructions essentially, that define the user's network experience. The most important of these is typically the VLAN assignment. The server RADIUS might say: this user is a member of the corporate staff group, assign them to VLAN ten, which has access to internal file servers and printers. Or: this user is a guest, assign them to VLAN twenty, which only has internet access and is completely isolated from the corporate network. This dynamic VLAN assignment is one of the most powerful features of server RADIUS, and it is the mechanism that enables proper network segmentation.

Accounting. The third pillar is often overlooked, but it is critically important for compliance and operations. As a user's session progresses, the server RADIUS logs key information: the time they connected, the time they disconnected, the total session duration, the amount of data they transferred, and the MAC address of their device. This creates a detailed audit trail for every connection on your network. Under PCI DSS version four, this kind of logging is not optional. It is a hard requirement. And in the event of a security incident, these logs are invaluable for forensic investigation.

Now, let us talk about the technical standard that makes all of this work: IEEE 802.1X.

802.1X is the standard that defines port-based network access control. It is the protocol that allows an access point to block all network traffic from a device until the server RADIUS has confirmed that the device is authorised. The communication between the user's device and the access point uses a protocol called EAP, the Extensible Authentication Protocol. EAP is essentially a framework that supports multiple authentication methods.

The three most common EAP methods in enterprise WiFi are: PEAP, which stands for Protected Extensible Authentication Protocol; EAP-TTLS; and EAP-TLS.

PEAP and EAP-TTLS are credential-based methods. They create an encrypted tunnel between the device and the server RADIUS, and then the user's username and password are verified inside that tunnel. They are relatively easy to deploy and work well in environments where you are not yet ready for a full certificate infrastructure.

EAP-TLS is the gold standard. It is certificate-based, meaning both the server and the client device present digital certificates to authenticate each other. There is no password involved at all. This completely eliminates the risk of credential theft, phishing attacks, and man-in-the-middle attacks. For corporate devices, EAP-TLS is the authentication method you should be working towards.

Now let us talk about deployment models. When it comes to server RADIUS, you have two primary options: on-premises and cloud-hosted.

On-premises RADIUS, using platforms like FreeRADIUS or Microsoft Network Policy Server, gives you complete control over the infrastructure. For a single large venue, such as a stadium or a hospital, this can be the right call. Authentication requests travel over the local network, giving you sub-millisecond response times. And if your identity directory is an on-premises Active Directory that cannot be exposed to the internet for compliance reasons, an on-premises server RADIUS is often your only viable option.

However, for multi-site organisations, on-premises RADIUS introduces significant operational overhead. You are managing separate server instances at each location, handling certificate renewals manually, and dealing with the consequences when something goes wrong at two in the morning.

Cloud RADIUS changes this entirely. The infrastructure is hosted globally across multiple availability zones. When a user connects at a branch location, the request is routed to the nearest cloud edge node. High availability is built in by default. And certificate rotation is automated, eliminating the single most common cause of authentication outages in on-premises deployments.

For multi-site organisations with cloud-native identity providers like Microsoft Entra ID, Okta, or Google Workspace, Cloud RADIUS is almost always the operationally superior choice. Purple's Cloud RADIUS integrates directly with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. That means you can deploy across your entire hardware estate without replacing a single access point.

Let me share two real-world scenarios to make this concrete.

The first is a European hotel group with 45 properties across six countries. The IT team was running FreeRADIUS on virtual machines at each property, 45 separate instances to patch, monitor, and maintain. When a certificate expired at one property, it caused a complete guest WiFi outage during a major conference. They migrated to a Cloud RADIUS service, centralising policy management and eliminating per-site maintenance. The three-engineer team reclaimed roughly 40 per cent of their time previously spent on RADIUS maintenance.

The second scenario is a national sports stadium with 68,000 seats. The IT team had strict requirements around data sovereignty. All authentication logs must remain on UK soil. They deployed a dual on-premises RADIUS cluster in active-active configuration, with a secondary cluster in a co-location facility 20 miles away. This gave them local control, sub-millisecond authentication, and the ability to handle burst traffic without relying on internet connectivity.

These two scenarios illustrate the decision framework clearly. Choose Cloud RADIUS when you have a distributed multi-site footprint, cloud-native identity providers, and a small central IT team. Choose on-premises when you have a single large location with stringent data sovereignty requirements or an air-gapped security environment.

Now for some rapid-fire questions we hear most often.

First: what is the difference between a server RADIUS and a captive portal? A captive portal is the login page guests see when they connect. It works with RADIUS. The portal is the user interface; the server RADIUS is the back-end engine.

Second: can I use RADIUS for wired networks? Absolutely. The 802.1X standard applies equally to wired Ethernet and wireless networks.

Third: what happens if my Cloud RADIUS provider has an outage? Reputable providers publish service level agreements of 99.99 per cent uptime, backed by multi-region redundancy. Always configure your access points with a fallback policy, either open access to a restricted VLAN, or locally cached credentials, to handle the scenario gracefully.

Fourth: how does RADIUS interact with guest WiFi? For venues providing WiFi to visitors, integrating your server RADIUS infrastructure with a captive portal solution creates a tiered access model. Staff and corporate devices authenticate silently via 802.1X, while guests are directed to a branded portal for onboarding. Purple's platform then captures first-party data and provides analytics on visitor behaviour, turning your network from a cost centre into a business intelligence asset.

To summarise. Server RADIUS is the centralised protocol that powers enterprise WiFi security. It implements the AAA framework to give you granular control over who can access your network, what they can do, and a complete audit trail of their activity. For venue operators, hoteliers, retailers, and public-sector organisations, deploying server RADIUS is the foundational step in building a secure, compliant, and professionally managed WiFi infrastructure.

Your next step is clear. If you are still running on pre-shared keys, start planning your migration today. Review your current hardware for WPA3-Enterprise support, assess your identity directory integration options, and explore a Cloud RADIUS platform that can scale with your organisation.

For more technical guides and implementation resources, visit us at purple dot ai. Until next time, stay secure.

Key Takeaways

✓Server RADIUS is the industry standard for enterprise network access control, replacing insecure pre-shared keys with identity-based authentication via the AAA framework.
✓Dynamic VLAN assignment is the mechanism that enforces network segmentation - a mandatory control for PCI DSS compliance in retail and hospitality environments.
✓EAP-TLS is the gold standard authentication method, eliminating passwords entirely via mutual certificate validation between client and server.
✓Cloud RADIUS is operationally superior for multi-site venues with small central IT teams, delivering automated certificate rotation, built-in high availability, and centralised policy management.
✓On-premises server RADIUS remains the correct choice for single large venues with data sovereignty requirements, air-gapped environments, or legacy on-premises directories.
✓Certificate expiry is the leading cause of on-premises RADIUS outages - configure monitoring alerts at 60 days, 30 days, and 7 days before expiry.
✓Purple's Cloud RADIUS integrates with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet across 80,000+ live venues with 99.999% uptime.

Executive summary

For IT managers, network architects, and CTOs operating across hospitality , retail , transport , and large public venues, securing wireless access is a core operational requirement - not an optional upgrade. Relying on a pre-shared key (PSK) for WiFi access is a significant security liability. A single compromised credential exposes the entire network, and revoking access requires changing the password for every device on the estate. Implementing 802.1X authentication via a server RADIUS (Remote Authentication Dial-In User Service) architecture eliminates this problem. Each user authenticates individually, access can be revoked instantly, and network segmentation is enforced dynamically.

Server RADIUS implements the AAA framework: Authentication, Authorisation, and Accounting. It validates identities against directories such as Microsoft Entra ID, Okta, or Google Workspace, assigns users to the correct network segment via dynamic VLAN assignment, and maintains a detailed audit trail for every session. For organisations subject to PCI DSS, GDPR, or Cyber Essentials, this audit trail is not optional. It is a hard compliance requirement. Purple's Cloud RADIUS server secures staff and corporate devices via certificate-based 802.1X authentication, integrating with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet across 80,000+ live venues.

Technical deep-dive: server RADIUS architecture

The IEEE 802.1X standard defines port-based network access control (PNAC). In a wireless context, it involves three primary roles working in concert to secure the network edge.

Role	Component	Responsibility
Supplicant	Client device (laptop, smartphone)	Presents credentials to request network access
Authenticator	WiFi access point or controller	Enforces access control; relays EAP messages
Authentication server	Server RADIUS	Validates credentials; returns accept or reject and policy attributes

When a supplicant associates with an access point, the AP blocks all data traffic except Extensible Authentication Protocol (EAP) messages. The AP encapsulates these EAP messages in RADIUS packets and forwards them to the server RADIUS over UDP port 1812. The server verifies the credentials against a backend directory and returns an Access-Accept or Access-Reject message. If accepted, the AP unblocks the port and client traffic flows freely.

The AAA framework in practice

Authentication is the first pillar: verifying who someone is. When a device connects to a WPA3-Enterprise SSID, the server RADIUS checks the presented credentials or certificate against the configured identity source. Microsoft Entra ID, Okta, and Google Workspace are the canonical cloud identity providers that integrate directly with modern Cloud RADIUS platforms.

Authorisation is the second pillar: determining what the authenticated user can do. The server RADIUS returns RADIUS attributes to the access point, most critically the VLAN ID. A staff member in the finance team lands on VLAN 10 with access to internal systems. A contractor lands on VLAN 20 with internet-only access. A guest lands on VLAN 30, isolated from all corporate resources. This dynamic VLAN assignment is the mechanism that enables proper network segmentation - a mandatory control for PCI DSS compliance in retail environments.

Accounting is the third pillar: recording what actually happened. The server RADIUS logs session start and stop times, session duration, data transferred, and the MAC address of each device. Under PCI DSS v4.0, this logging is a hard requirement. In the event of a security incident, these logs are the foundation of any forensic investigation.

EAP method selection

The security of your server RADIUS deployment depends heavily on the EAP method selected. The three most common methods in enterprise WiFi are PEAP, EAP-TTLS, and EAP-TLS.

PEAP-MSCHAPv2 is the most widely deployed method. It creates an encrypted TLS tunnel using a server-side certificate, inside which the user authenticates with a username and password. It is relatively straightforward to deploy because you only need to manage one certificate - the server's. However, if client devices are not explicitly configured to validate the server certificate, they are vulnerable to rogue access point attacks. An attacker can present a fraudulent certificate and capture credentials. This is a documented real-world threat, not a theoretical one. Enforce strict certificate validation via Group Policy Objects or MDM profiles without exception.

EAP-TLS is the gold standard. It requires digital certificates on both the server RADIUS and every client device, eliminating passwords entirely. Even if an attacker captures the full authentication exchange, there are no credentials to extract. The trade-off is administrative overhead: deploying and managing client certificates requires a Public Key Infrastructure (PKI) and an MDM platform such as Microsoft Intune or Jamf. For corporate devices, EAP-TLS is the authentication method you should be working towards. Purple's Cloud RADIUS supports EAP-TLS natively, with automated certificate lifecycle management.

Implementation guide: cloud vs on-premises

When deploying a server RADIUS architecture, IT teams must choose between cloud-hosted and on-premises deployment. This is the most consequential architectural decision in the project.

On-premises RADIUS, using platforms like FreeRADIUS or Microsoft Network Policy Server (NPS), gives you complete control over the infrastructure. For a single large venue - a stadium, a hospital, or a government facility - this can be the right call. Authentication requests travel over the local LAN, delivering sub-millisecond response times. If your identity directory is an on-premises Active Directory that cannot be exposed to the internet for data sovereignty reasons, an on-premises server RADIUS is often your only viable option.

However, for multi-site organisations, on-premises RADIUS introduces significant operational overhead. You are managing separate server instances at each location, handling certificate renewals manually, and responding to outages at two in the morning when a certificate expires. For a retail chain with 50 locations, that means 50 separate RADIUS instances to patch, monitor, and maintain.

Cloud RADIUS changes this entirely. The infrastructure is hosted globally across multiple availability zones. When a user connects at a branch location, the request routes to the nearest cloud edge node. High availability is built in by default. Certificate rotation is automated, eliminating the single most common cause of authentication outages in on-premises deployments. For multi-site organisations with cloud-native identity providers like Microsoft Entra ID, Okta, or Google Workspace, Cloud RADIUS is almost always the operationally superior choice.

Purple's Cloud RADIUS integrates directly with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. You deploy across your entire hardware estate without replacing a single access point.

Step-by-step deployment

Step 1: Choose your deployment model. Audit three factors: your current identity provider and whether it is cloud-native; your WAN resilience at each site; and your team's capacity to manage ongoing maintenance. These three factors determine whether cloud or on-premises is the right path.

Step 2: Integrate your identity source. Connect your server RADIUS to your organisation's identity directory. Most Cloud RADIUS platforms support direct integration with Microsoft Entra ID, Okta, and Google Workspace via LDAP or SAML. For on-premises Active Directory, use LDAP over a secure connector.

Step 3: Configure your network hardware. Create a new SSID configured for WPA2-Enterprise or WPA3-Enterprise and point it at your server RADIUS. Configure the shared secret - the password that encrypts communication between the access point and the server RADIUS. This shared secret must match exactly on both sides. A mismatch is one of the most common causes of authentication failures during initial deployment.

Step 4: Define authorisation policies. Map user groups from your identity directory to network policies. Staff get full access on VLAN 10. Guests get internet-only access on VLAN 20. IoT devices get a restricted VLAN with firewall rules blocking lateral movement.

Step 5: Onboard your users. For corporate staff, deploy WiFi profiles via your MDM platform. For guests, use a captive portal. Purple's Guest WiFi platform automates the guest onboarding flow, supporting social login, registration forms, and voucher codes. Staff and corporate devices authenticate silently via 802.1X while guests are directed to a branded portal - a tiered access model that delivers both security and WiFi Analytics .

For a deeper look at SSID architecture across guest, staff, and IoT networks, see Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi .

Best practices

Enforce strict certificate validation on every client device. Use Group Policy Objects for Windows devices and MDM profiles for macOS and mobile devices. The profile must specify exactly which Certificate Authority to trust and what the expected server name is. Do not leave this to the user to configure manually. Failure to enforce this is the primary attack vector for credential theft on PEAP deployments.

Deploy at least two server RADIUS instances. Configure all access points to fail over to the secondary if the primary becomes unreachable. For Cloud RADIUS, this redundancy is built in and managed by the provider. For on-premises, deploy an active-active cluster across two geographically separated locations.

Use MAC Authentication Bypass (MAB) for headless IoT devices. Printers, sensors, and digital signage cannot present 802.1X credentials. MAB allows authentication based on MAC address. Because MAC addresses are easily spoofed, always pair MAB-authenticated devices with a restrictive VLAN and firewall rules blocking access to corporate resources.

Rotate shared secrets regularly. The shared secret between your access points and your server RADIUS must be long, random, and rotated periodically. A weak or default shared secret undermines the entire authentication chain.

Validate segmentation with penetration testing. Configuration alone is not evidence. Commission a penetration test that explicitly includes the wireless environment and validation of VLAN segmentation. A tester should actively attempt to access corporate resources from the guest VLAN and document that every attempt is blocked. This is the evidence your PCI DSS Qualified Security Assessor needs.

Troubleshooting and risk mitigation

The most common failure modes in server RADIUS deployments fall into four categories.

Shared secret mismatch. If the shared secret configured on the access point does not match the secret on the server RADIUS, every authentication attempt will fail silently. Always copy-paste shared secrets rather than typing them manually. Verify the configuration on both sides before testing.

Certificate expiry. On on-premises deployments, if the server certificate expires, every client device will reject the connection. This causes a complete authentication outage with no graceful degradation. Cloud RADIUS providers automate certificate rotation, eliminating this risk. For on-premises deployments, configure monitoring alerts at 60 days, 30 days, and seven days before expiry.

Client certificate validation not enforced. If PEAP clients are not configured to validate the server certificate, they will connect to any RADIUS server that responds - including rogue access points. Enforce certificate validation via GPO or MDM profiles on every managed device.

WAN dependency for Cloud RADIUS. Cloud RADIUS relies entirely on the WAN link at each venue. If the internet connection drops, authentication fails. Implement a local survivability strategy: configure access points to cache credentials for critical staff, or use SD-WAN to ensure high availability of the internet link. Always configure a fallback policy - either open access to a restricted VLAN, or locally cached credentials.

ROI and business impact

Deploying a server RADIUS architecture transforms the wireless network from a vulnerability into a managed, secure asset with measurable operational benefits.

For a European hotel group with 45 properties, migrating from 45 on-premises FreeRADIUS instances to Cloud RADIUS reclaimed roughly 40% of the central IT team's maintenance time (Purple internal data). That is engineering capacity redirected from keeping the lights on to strategic initiatives.

For a retail chain preparing for a PCI DSS audit, proper network segmentation via dynamic VLAN assignment removes the guest WiFi network from the Cardholder Data Environment scope entirely. Platforms like Purple's Guest WiFi operate on the guest-facing VLAN, completely isolated from payment traffic. The analytics platform is out of PCI scope, and the business retains the freedom to deploy revenue-generating tools - guest analytics, loyalty programmes, customer engagement - safely and confidently.

For organisations with more than 10 sites and fewer than five network engineers, the predictable operational expenditure of Cloud RADIUS typically delivers a positive return on investment within 18 months compared to maintaining on-premises infrastructure (Purple internal data). Hardware procurement, power, cooling, and engineering time for on-premises deployments at scale consistently exceed the subscription cost of a managed Cloud RADIUS service.

Purple operates across 80,000+ live venues with 99.999% uptime, ISO 27001 certification, GDPR and CCPA compliance, and Cyber Essentials certification. For IT teams that need to demonstrate due diligence to their board or auditors, these certifications provide the third-party validation that a self-managed on-premises deployment cannot.

For a detailed comparison of Purple's Cloud RADIUS against alternative platforms, see the Aruba ClearPass vs. Purple WiFi feature and co-deployment comparison .

Key Definitions

Server RADIUS

Remote Authentication Dial-In User Service. A networking protocol server that provides centralised Authentication, Authorisation, and Accounting (AAA) management for network access. Defined in RFC 2865 and extended by subsequent RFCs.

The core engine that validates user credentials against a directory and dictates network access policies. Every enterprise WiFi deployment using 802.1X requires a server RADIUS.

802.1X

An IEEE standard for port-based network access control that provides an authentication mechanism for devices wishing to attach to a LAN or WLAN. It defines the roles of Supplicant, Authenticator, and Authentication Server.

The standard that access points use to communicate with the server RADIUS. Without 802.1X, there is no mechanism to block unauthenticated devices at the network edge.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. An authentication method requiring digital certificates on both the client device and the server RADIUS. Provides mutual authentication with no password involved.

The gold standard for authenticating corporate devices. Eliminates credential theft and phishing attacks. Requires a PKI and MDM platform to deploy client certificates at scale.

PEAP-MSCHAPv2

Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2. Uses a server-side TLS certificate to create an encrypted tunnel, inside which the user authenticates with a username and password.

The most common enterprise WiFi authentication method. Secure only when clients are explicitly configured to validate the server certificate via GPO or MDM profiles.

Dynamic VLAN assignment

The process by which a server RADIUS instructs an access point to place an authenticated user onto a specific Virtual Local Area Network (VLAN) based on their identity and group membership in the directory.

The mechanism that enforces network segmentation. Essential for PCI DSS compliance in retail and hospitality. Allows a single SSID to serve staff, contractors, guests, and IoT devices on separate network segments.

AAA framework

Authentication, Authorisation, and Accounting. The three-pillar framework implemented by server RADIUS for managing network access. Authentication verifies identity, Authorisation determines access level, Accounting logs session activity.

The conceptual foundation of all server RADIUS deployments. PCI DSS v4.0 requires all three pillars to be implemented for networks handling payment data.

Supplicant

The client device (laptop, smartphone, IoT sensor) that requests access to the network by presenting credentials or a certificate to the Authenticator.

The endpoint that must satisfy the server RADIUS authentication challenge. Understanding which component is failing is the foundation of effective troubleshooting.

Captive portal

A web page that users must interact with before being granted access to a public WiFi network. Handles the user-facing onboarding experience while the server RADIUS manages back-end authentication and session policy enforcement.

Used for guest onboarding in hospitality, retail, and venue environments. Works in conjunction with the server RADIUS - the portal is the user interface, the server RADIUS is the back-end engine.

MAC Authentication Bypass (MAB)

A mechanism that allows devices without 802.1X capabilities (printers, IoT sensors, digital signage) to be authenticated based on their MAC address rather than credentials or certificates.

Required for headless devices that cannot run an 802.1X supplicant. Because MAC addresses are easily spoofed, MAB-authenticated devices must always be placed on a highly restricted VLAN.

Shared secret

A password that encrypts the communication between an access point (RADIUS client) and the server RADIUS. Must be configured identically on both sides and rotated periodically.

A shared secret mismatch is one of the most common causes of authentication failures during initial deployment. Always copy-paste rather than type manually.

Worked Examples

A 200-room hotel needs to secure staff devices via 802.1X while providing isolated guest WiFi access. The property management system runs on staff devices and must not be accessible from the guest network. The hotel is part of a 45-property group managed by a three-person central IT team.

Deploy Purple's Cloud RADIUS integrated with Microsoft Entra ID. Configure a staff SSID using WPA3-Enterprise with EAP-TLS, deploying client certificates to all staff devices via Microsoft Intune. Configure the server RADIUS to dynamically assign staff devices to VLAN 10, which has access to the property management system and internal printers. Deploy a separate guest SSID using WPA2-Personal with a captive portal for onboarding, assigned to VLAN 20 with internet-only access and strict firewall rules blocking all traffic to VLAN 10. The Cloud RADIUS handles all 45 properties from a single management dashboard, with automated certificate rotation eliminating the per-site maintenance overhead that previously consumed 40% of the team's time.

Examiner's Commentary: This scenario illustrates the core value of Cloud RADIUS for multi-site hospitality. The server RADIUS handles staff authentication via EAP-TLS, providing the strongest available security for devices that access sensitive operational systems. The captive portal manages guest onboarding separately, with VLAN isolation ensuring the guest network remains out of PCI DSS scope. The cloud deployment model is the decisive factor for a three-person team managing 45 properties - on-premises would require 45 separate instances to maintain.

A retail chain with 50 stores is experiencing frequent authentication outages caused by expired certificates on their local FreeRADIUS servers. POS tablets authenticate via 802.1X, and each outage prevents staff from processing payments until the certificate is manually renewed. The IT director wants to eliminate this failure mode before the next peak trading period.

Migrate from the 50 on-premises FreeRADIUS instances to a centralised Cloud RADIUS platform. Integrate the Cloud RADIUS with the corporate Okta directory. Update the access point configurations at all 50 locations to point to the new Cloud RADIUS endpoints. Configure dynamic VLAN assignment to place POS tablets on VLAN 10 (payment network) and staff devices on VLAN 20 (corporate network). The cloud provider handles all server certificate rotation automatically. Validate VLAN segmentation between the payment network and the guest WiFi network with a penetration test before the next audit cycle.

Examiner's Commentary: The root cause of the outages is manual certificate management on 50 separate on-premises instances - a classic operational risk for distributed retail IT estates. Cloud RADIUS eliminates this by automating certificate lifecycle management. The migration also centralises policy management, meaning a policy change deploys to all 50 locations simultaneously rather than requiring manual updates at each site. The penetration test recommendation addresses the PCI DSS requirement to validate segmentation, not just configure it.

Practice Questions

Q1. A retail venue is preparing for a PCI DSS v4.0 audit. They currently run a single SSID with a pre-shared key for both staff POS tablets and guest access. The Qualified Security Assessor has flagged this as a critical finding. What is the immediate architectural change required, and which server RADIUS feature is central to the remediation?

Hint: Focus on network segmentation and the specific RADIUS feature that enforces it dynamically.

View model answer

The venue must deploy a server RADIUS to implement 802.1X authentication and replace the shared PSK. The central feature is dynamic VLAN assignment: the server RADIUS must be configured to place POS tablets on a payment VLAN and guests on an isolated internet-only VLAN, with strict firewall rules preventing any traffic crossing between them. The guest SSID should use a captive portal for onboarding. The segmentation must be validated with a penetration test, not just configuration review, to satisfy PCI DSS Requirement 11.

Q2. An enterprise with 30 branch offices is deciding between Cloud RADIUS and on-premises server RADIUS. They have a small central IT team of four engineers, use Okta for identity management, and have no data sovereignty requirements. Which deployment model is recommended, and what is the primary operational justification?

Hint: Evaluate the maintenance overhead of managing 30 separate instances versus a centralised cloud service.

View model answer

Cloud RADIUS is strongly recommended. With 30 sites and four engineers, deploying and maintaining 30 on-premises server RADIUS instances would consume a disproportionate share of the team's capacity. Cloud RADIUS integrates natively with Okta, automates certificate rotation, and provides built-in high availability without requiring the team to manage the underlying infrastructure. The absence of data sovereignty requirements removes the primary justification for on-premises. The team should configure access points with a fallback policy to handle the WAN dependency gracefully.

Q3. During a PEAP-MSCHAPv2 deployment, users report security certificate warnings on their devices when connecting to the corporate WiFi SSID. Some users are dismissing the warnings and connecting anyway. What is the security risk, and what configuration step was missed?

Hint: Consider what happens when a client does not validate the server certificate, and how an attacker could exploit this.

View model answer

The security risk is a rogue access point attack. Without enforced certificate validation, a client device will connect to any server RADIUS that responds - including one operated by an attacker. The attacker presents a fraudulent certificate, the user dismisses the warning, and the attacker captures the username and password inside the PEAP tunnel. The missed configuration step is deploying MDM profiles (for macOS and mobile) and Group Policy Objects (for Windows) that explicitly specify the trusted Certificate Authority and expected server name. Users must never be left to make certificate trust decisions manually.

Q4. A stadium with 68,000 seats needs to authenticate staff devices during a major event where 40,000 devices may attempt to connect within a 30-minute window. The IT team has strict data sovereignty requirements: all authentication logs must remain on UK soil. Which deployment model is recommended, and what specific architecture addresses the burst traffic requirement?

Hint: Consider the latency and throughput advantages of local authentication versus cloud-routed requests under burst conditions.

View model answer

On-premises server RADIUS is recommended due to the data sovereignty requirement and the extreme burst authentication load. The recommended architecture is a dual on-premises RADIUS cluster in active-active configuration, with a secondary cluster in a co-location facility within the UK. Local authentication delivers sub-millisecond response times and removes the WAN dependency that would create a bottleneck during burst events. The active-active cluster provides redundancy without relying on internet connectivity. Authentication logs remain on UK soil, satisfying the data sovereignty requirement.

Continue reading in this series

Aruba ClearPass vs. Purple WiFi: Comparing Features and Co-deployment

A comprehensive technical guide detailing the co-deployment architecture of Aruba ClearPass and Purple WiFi. It covers RADIUS proxy configuration, dynamic VLAN assignment, and best practices for delivering secure, analytics-driven guest networks alongside enterprise NAC.

Aruba ClearPass vs. Purple WiFi: Comparing Features and Co-deployment

Cisco ISE vs. Purple WiFi: How They Compare and Work Together

This guide explains how Cisco ISE and Purple WiFi serve distinct but complementary roles in enterprise networks. It details how to use Cisco ISE for secure 802.1X corporate access while leveraging Purple for GDPR-compliant guest WiFi, marketing analytics, and CRM integration.