The Security Benefits of RADIUS as a Service for Hybrid Workforces

Esta guía de referencia técnica explica cómo RADIUS as a Service protege el acceso a la red para plantillas híbridas en sedes distribuidas. Cubre la arquitectura, los beneficios de seguridad y los pasos de implementación para reemplazar la infraestructura RADIUS local por un servicio de autenticación gestionado en la nube. Para los responsables de TI y arquitectos de red de hoteles, cadenas de retail, estadios y organizaciones del sector público, esta guía proporciona las pruebas necesarias para evaluar y llevar a cabo una migración a RADIUS en la nube este trimestre.

📖 9 min de lectura📝 2,171 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del podcast

Welcome to this technical briefing from Purple. I am your host, and today we are examining a critical shift in enterprise network architecture: moving from on-premise RADIUS servers to RADIUS as a Service. If you manage IT for a hotel group, a retail chain, a stadium, or any large public venue, you know that securing network access for a hybrid workforce is no longer a peripheral concern. It is central to your operational security, your compliance posture, and frankly, your ability to sleep at night.

Today we will cover five areas. First, the context: why traditional on-premise RADIUS infrastructure is struggling to keep pace with hybrid work. Second, the technical architecture of RADIUS as a Service and how it actually works. Third, the specific security benefits you gain. Fourth, practical implementation guidance and the pitfalls to avoid. And fifth, a rapid-fire question and answer section covering the questions we hear most often from IT managers and network architects.

Let us start with the context. For two decades, 802.1X authentication relied on physical servers running FreeRADIUS on Linux, Microsoft Network Policy Server on Windows, or Cisco Identity Services Engine on dedicated hardware. These systems worked. They still work. But they require constant attention. You had to patch operating systems, manage certificate chains, configure high availability manually, and build redundancy across multiple servers. In a world where workers move constantly between the office, remote locations, hotel rooms, and client sites, that static, on-premise infrastructure becomes a genuine liability.

The problem is compounded by the shift to cloud identity providers. Microsoft NPS, for example, is tightly coupled to Active Directory. It has no native support for Microsoft Entra ID, Google Workspace, or Okta. If your organisation has migrated to any of these cloud directories, you face a painful choice: maintain a parallel Active Directory just to support your RADIUS server, or invest significant engineering effort in custom integrations. Neither option is attractive.

RADIUS as a Service changes the equation entirely. It moves the authentication engine to the cloud. You no longer manage the infrastructure; you manage the policies. The provider handles the servers, the patching, the high availability, and the integrations. You define who gets access to what, and the service enforces it.

Now let us get into the technical architecture. RADIUS, which stands for Remote Authentication Dial-In User Service, is the protocol defined in RFC 2865. It provides centralised Authentication, Authorisation, and Accounting, what we call AAA, for network access. When a device connects to your WiFi network, the access point acts as a RADIUS client. It forwards the authentication request to the RADIUS server. The server validates the credentials against your identity store and returns either an Access-Accept or an Access-Reject.

In a cloud RADIUS deployment, the server is hosted by the provider across multiple geographically distributed data centres. Your access points, whether they are Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, or Ubiquiti UniFi, point to the cloud RADIUS endpoints via secure, encrypted tunnels. The authentication flow is identical to on-premise RADIUS from the access point's perspective. The difference is that the server itself is managed, patched, and scaled by the provider.

The most important security enhancement in modern cloud RADIUS deployments is the move to EAP-TLS, which stands for Extensible Authentication Protocol with Transport Layer Security. EAP-TLS is defined in RFC 5216 and provides mutual authentication using digital certificates. Both the client device and the RADIUS server present certificates to each other. This eliminates passwords entirely from the authentication process. A certificate is cryptographically tied to the device and cannot be phished, guessed, or stolen in the way a password can.

The second major security capability is dynamic VLAN assignment. When the RADIUS server authenticates a user, it does not just grant or deny access. It also tells the access point which Virtual LAN to place the device in, based on the user's identity and role. A hotel receptionist authenticates and is placed in the front-of-house VLAN with access to the property management system. A housekeeping staff member is placed in a restricted VLAN with internet access only. A guest device is placed in the guest VLAN, completely isolated from all corporate resources. An IoT device, like a security camera, is placed in a dedicated IoT VLAN.

This identity-based network segmentation is fundamental to a Zero Trust security model. You are no longer trusting a device because it connected to a particular SSID. You are granting access based on verified identity, and you are limiting that access to only what that identity requires. This is the principle of least privilege applied to network access.

Let us also address the compliance angle. PCI DSS version 4.0 requires strong access controls for any network that touches cardholder data. Requirement 8 mandates unique authentication for all users. Requirement 1 requires network segmentation. Cloud RADIUS, with EAP-TLS and dynamic VLAN assignment, satisfies both requirements directly. For GDPR, the centralised audit logging provided by cloud RADIUS gives you a complete record of who accessed the network, when, and from which device. That audit trail is essential for demonstrating compliance and for investigating any potential data breach.

Now let me walk you through two concrete implementation scenarios that illustrate how this works in practice.

The first scenario is a hotel group. Consider a two-hundred room hotel property. They currently use a shared pre-shared key for their staff WiFi. Every member of staff, from the general manager to the seasonal housekeeping team, uses the same password. When a seasonal employee leaves at the end of summer, the password is rarely changed because changing it means updating every device on the property. This is a textbook security vulnerability.

The solution is to deploy RADIUS as a Service integrated with Microsoft Entra ID. The hotel configures its Cisco Meraki access points to use WPA3-Enterprise with 802.1X. Each staff member authenticates using their Entra ID credentials. The RADIUS server reads their role from the directory and assigns them to the appropriate VLAN dynamically. Housekeeping staff are placed in VLAN 10 with access to the housekeeping task management system only. Reception staff are placed in VLAN 20 with access to the property management system. Management are placed in VLAN 30 with broader access. When a seasonal employee's contract ends, their Entra ID account is disabled, and their WiFi access is revoked instantly, across every access point on the property. No password changes required.

The second scenario is a national retail chain. Consider a chain with four hundred stores. They currently manage four hundred separate FreeRADIUS instances on local store servers. Each server requires individual patching, monitoring, and maintenance. When a critical vulnerability is disclosed, the security team must patch four hundred servers, often over a period of weeks, leaving the estate exposed during that window.

The solution is to migrate to a single RADIUS as a Service instance. All four hundred stores point their HPE Aruba access points to the same cloud RADIUS endpoints. Point-of-sale terminals are authenticated using EAP-TLS with machine certificates pushed via the MDM platform. The RADIUS server places them in a PCI-compliant VLAN, isolated from all other network traffic. Store staff use a separate SSID authenticated via Okta, placing them in a general staff VLAN. The security team now manages one set of policies from a single dashboard. When a vulnerability is disclosed, the provider patches the infrastructure. The retail chain's security team focuses on policy, not plumbing.

Now let us cover implementation recommendations and the pitfalls to avoid.

Step one is to connect the cloud RADIUS service to your identity provider. For Microsoft Entra ID or Google Workspace, this typically involves authorising an enterprise application. Map your directory groups to specific network policies. Think carefully about your role taxonomy before you start. Getting this right at the beginning saves significant rework later.

Step two is to set up certificate deployment for corporate devices. Configure your MDM platform to push client certificates to managed devices. This enables EAP-TLS authentication and removes passwords from the equation entirely. For devices you do not manage, you can use PEAP with a user credential as a fallback, but EAP-TLS should be the target for all corporate-owned devices.

Step three is to configure your network hardware. Add the cloud RADIUS IP addresses and shared secrets to your wireless controllers or access points. Always configure both the primary and secondary endpoints to use the provider's built-in redundancy.

Step four is to define your VLAN policies. When the RADIUS server authenticates a user, it returns the correct VLAN ID to the access point. Map this out before you deploy. Know which VLAN each user role should land in, and test it thoroughly before rolling out to production.

Now, the pitfalls. The most common mistake is a misconfigured firewall blocking UDP ports 1812 and 1813, which are the RADIUS authentication and accounting ports. Always verify connectivity between your access points and the cloud RADIUS endpoints before go-live. The second pitfall is a broken certificate trust chain. If your client devices do not trust the Root Certificate Authority that issued the RADIUS server's certificate, they will silently reject the connection. This can look like a network outage when it is actually a PKI configuration issue.

Let us move to the rapid-fire questions.

Question one: What happens if our internet connection goes down? If the site loses internet, it cannot reach the cloud RADIUS. However, if the site has no internet, users cannot access cloud applications anyway. For mission-critical local resources, some access points offer local survivability modes. But the primary dependency is your WAN link, and that is true of almost every cloud service your organisation uses.

Question two: Is cloud RADIUS compliant with GDPR and PCI DSS? Yes. Centralised authentication with encrypted transport supports strong compliance postures. The audit logs satisfy PCI DSS requirements, and the strict access controls support GDPR principles of data minimisation and access limitation.

Question three: Does this work with our existing hardware? Yes. RADIUS is a standard protocol defined in RFC 2865. If your hardware supports 802.1X, and all enterprise gear from Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet does, it will work with any standards-compliant RADIUS as a Service.

To summarise the key takeaways. First, RADIUS as a Service replaces on-premise servers with a managed cloud platform, reducing capital expenditure and maintenance overhead. Second, cloud RADIUS integrates natively with Microsoft Entra ID, Okta, and Google Workspace, eliminating the need for complex middleware. Third, it enables dynamic VLAN assignment, ensuring users and devices land in the correct network segment based on their verified identity. Fourth, transitioning to EAP-TLS eliminates the risk of password theft and phishing attacks on your network. Fifth, centralised cloud management ensures consistent security policies across hundreds of distributed venue locations. Sixth, providers handle security patching and high availability. And seventh, cloud RADIUS supports compliance with PCI DSS and GDPR by enforcing strict, identity-based access controls with full audit logging.

Your next step is to evaluate your current RADIUS infrastructure. Calculate the true cost of ownership, including licensing, hardware refresh cycles, and the engineering time spent on maintenance. Then, run a proof of concept with a cloud RADIUS provider. You will likely find that the deployment takes hours, not weeks. Thank you for listening. Secure your networks, segment your traffic, and stop managing servers you do not need to own.

Conclusiones clave

✓RADIUS as a Service replaces on-premise servers with a managed cloud platform, eliminating hardware CapEx and maintenance overhead.
✓Cloud RADIUS integrates natively with Microsoft Entra ID, Okta, and Google Workspace, removing the need for complex middleware or parallel Active Directory deployments.
✓Dynamic VLAN assignment ensures users and devices are automatically placed in the correct network segment based on their verified identity, not the SSID they connected to.
✓Transitioning to EAP-TLS (certificate-based authentication) eliminates the risk of password theft and phishing attacks on your network.
✓Centralised cloud management enforces consistent security policies across hundreds of distributed venue locations from a single dashboard.
✓Providers handle security patching and multi-region high availability, ensuring authentication services remain available even during infrastructure updates.
✓Cloud RADIUS supports compliance with PCI DSS v4.0 and GDPR by enforcing strict, identity-based access controls with full centralised audit logging.

Resumen ejecutivo

El cambio hacia las plantillas híbridas ha dejado al descubierto una debilidad fundamental en la seguridad de red tradicional: los servidores RADIUS locales se diseñaron para un mundo en el que el personal se sentaba en un solo edificio y se conectaba a una única red. Ese mundo ya no existe. Hoy en día, sus empleados se autentican desde habitaciones de hotel, tiendas de retail, oficinas remotas y recintos de eventos. Sus proveedores de identidad residen en la nube. Sus puntos de acceso se extienden por cientos de ubicaciones. Sin embargo, muchas organizaciones siguen dependiendo de servidores RADIUS físicos que requieren parches manuales, no pueden integrarse de forma nativa con Microsoft Entra ID o Google Workspace y fallan silenciosamente cuando el hardware falla.

RADIUS as a Service reemplaza esa infraestructura con un motor de autenticación nativo de la nube. Solo tiene que apuntar sus puntos de acceso a los endpoints de la nube. El proveedor gestiona los servidores, los parches y la alta disponibilidad. Usted gestiona las políticas. Para los equipos de TI de grupos de Hostelería , cadenas de Retail y recintos públicos, este cambio elimina los costes indirectos de hardware, aplica la segmentación de red basada en la identidad y ofrece el registro de auditoría que exigen PCI DSS y GDPR.

Análisis técnico detallado

Por qué el RADIUS local tiene dificultades

RADIUS, definido en RFC 2865, proporciona autenticación, autorización y contabilidad (AAA) centralizadas para el acceso a la red. Todas las empresas que ejecutan WiFi WPA2-Enterprise o WPA3-Enterprise dependen de él. El protocolo en sí es sólido. El problema es el modelo de infraestructura que creció a su alrededor.

FreeRADIUS en Linux requiere una experiencia significativa para su implementación, securización y mantenimiento. Microsoft Network Policy Server (NPS) está estrechamente vinculado a Active Directory y no tiene soporte nativo para Microsoft Entra ID, Okta o Google Workspace. Cisco Identity Services Engine (ISE) ofrece funciones de política de nivel empresarial, pero exige hardware dedicado, licencias complejas y un equipo de especialistas para operarlo. Los tres requieren que cree y mantenga la alta disponibilidad de forma manual, normalmente ejecutando dos servidores con replicación de bases de datos y un equilibrador de carga frente a ellos.

Para una organización con una sola sede y un Active Directory estable, este modelo es manejable. Para un grupo hotelero con 50 propiedades, una cadena de retail con 400 tiendas o una universidad con un campus distribuido, se vuelve inviable. O bien centraliza los servidores RADIUS y acepta la latencia de autenticación de los sitios remotos, o bien implementa servidores en cada ubicación y los gestiona individualmente. Ninguna de las dos opciones es escalable.

La arquitectura de RADIUS as a Service

RADIUS as a Service es un modelo de entrega basado en la nube para el protocolo RADIUS. El protocolo en sí permanece sin cambios, siguiendo la norma RFC 2865 y sus extensiones. Lo que cambia es quién mantiene la infraestructura.

Cuando un dispositivo conecta a su red WiFi, el punto de acceso (el cliente RADIUS) reenvía la solicitud de autenticación a los endpoints de RADIUS en la nube a través de un túnel seguro y cifrado. El servicio en la nube valida las credenciales con su proveedor de identidad y devuelve un mensaje de Access-Accept o Access-Reject, junto con atributos de política como asignaciones dinámicas de VLAN. Desde la perspectiva del punto de acceso, el flujo de autenticación es idéntico al de RADIUS local.

El proveedor de la nube opera los servidores RADIUS en múltiples centros de datos distribuidos geográficamente. La conmutación por error es automática. Si un endpoint deja de estar disponible, el tráfico se enruta al siguiente que esté activo sin ninguna intervención de su equipo. Para organizaciones con ubicaciones en múltiples regiones, la autenticación se realiza en el endpoint de la nube más cercano, manteniendo la latencia baja independientemente de la geografía.

Métodos IEEE 802.1X y EAP

IEEE 802.1X es el estándar para el control de acceso a la red (NAC) basado en puertos. Obliga a un dispositivo a autenticarse antes de que se le asigne una dirección IP y se le permita transmitir tráfico. RADIUS es el servidor de autenticación en una implementación 802.1X.

El Protocolo de Autenticación Extensible (EAP) define cómo se intercambian las credenciales. Cloud RADIUS admite toda la gama de métodos EAP:

Método EAP	Tipo de autenticación	Nivel de seguridad	Uso recomendado
EAP-TLS	Basada en certificados mutuos	El más alto	Dispositivos corporativos con certificados gestionados por MDM
PEAP-MSCHAPv2	Usuario y contraseña	Moderado	Dispositivos heredados o BYOD sin MDM
EAP-TTLS	Credenciales tunelizadas	Moderado	Entornos mixtos
MAC Authentication Bypass	Dirección MAC del dispositivo	Bajo	Dispositivos IoT que no admiten 802.1X

EAP-TLS, definido en RFC 5216, es el estándar de oro. Tanto el dispositivo cliente como el servidor RADIUS se presentan certificados digitales mutuamente. Esta autenticación mutua elimina por completo las contraseñas del proceso de acceso a la red. Un certificado está vinculado criptográficamente al dispositivo y no puede ser objeto de phishing, adivinación o robo de la forma en que puede serlo una contraseña. Para las organizaciones que han sufrido brechas basadas en credenciales, esta es la mitigación técnica más directa disponible.

Asignación dinámica de VLAN

Más allá de la autenticación, el servidor RADIUS aplica la autorización. Cuando acepta una conexión, devuelve atributos de política al punto de acceso, incluido el ID de VLAN que se debe asignar al dispositivo. Esta asignación dinámica de VLAN es el mecanismo que permite las redes basadas en la identidad.

Un recepcionista de hotel se autentica y se le ubica en la VLAN de recepción con acceso al sistema de gestión de la propiedad. Un miembro del personal de limpieza se ubica en una VLAN restringida con acceso únicamente a Internet. El dispositivo de un huésped se ubica en la VLAN de WiFi para invitados, completamente aislado de todos los recursos corporativos. Un dispositivo IoT, como una cámara de seguridad, se ubica en una dedicada VLAN de IoT. Todo esto ocurre de forma automática, basándose en la identidad verificada por el servidor RADIUS, sin necesidad de realizar ninguna configuración manual de VLAN por dispositivo.

Este es el principio de mínimo privilegio aplicado al acceso a la red. No se confía en un dispositivo solo porque se haya conectado a un SSID concreto. Se concede acceso en función de una identidad verificada y se limita dicho acceso únicamente a lo que esa identidad requiere. Para analizar más a fondo cómo encaja esto en una estrategia de control de acceso a la red más amplia, consulte nuestra guía sobre sistemas de control de acceso a la red .

Integración nativa de identidad en la nube

La ventaja operativa más importante de cloud RADIUS es su integración nativa con los proveedores de identidad modernos. Cloud RADIUS se conecta directamente a Microsoft Entra ID, Okta y Google Workspace a través de protocolos estándar que incluyen OIDC, SAML y LDAP. Al dar de alta a un nuevo empleado en su proveedor de identidad, este puede autenticarse en la red WiFi de inmediato. Al dar de baja a un empleado, se deshabilita su cuenta en el directorio y su acceso a la WiFi se revoca al instante, en todos los puntos de acceso de cada ubicación.

Esta sincronización en tiempo real elimina una de las brechas de seguridad más persistentes en la WiFi empresarial: el exempleado que aún conserva la PSK compartida o cuya cuenta de RADIUS no se eliminó manualmente al marcharse. Con cloud RADIUS y un proveedor de identidad en la nube, la baja es una acción única con un efecto inmediato en toda la red.

Guía de implementación

Paso 1: Conectar su proveedor de identidad

Conecte el servicio cloud RADIUS a su proveedor de identidad. En el caso de Microsoft Entra ID o Google Workspace, esto suele implicar la autorización de una aplicación empresarial a través de OAuth o la configuración de un conector LDAP. Vincule sus grupos de directorio con políticas de red específicas. Defina su taxonomía de roles antes de empezar: qué grupos se asocian a qué VLAN y qué derechos de acceso conlleva cada VLAN. Hacerlo bien desde el principio evita tener que repetir un trabajo considerable más adelante.

Paso 2: Implementar certificados para dispositivos corporativos

Para los dispositivos propiedad de la empresa, configure su plataforma de gestión de dispositivos móviles (MDM), como Microsoft Intune o Jamf, para enviar certificados de cliente a los dispositivos. Esto permite la autenticación EAP-TLS. Asegúrese de que todos los dispositivos cliente confíen en la autoridad de certificación raíz (CA) que emitió el certificado del servidor RADIUS. Una cadena de confianza rota es la causa más común de fallos de autenticación silenciosos.

Paso 3: Configurar el hardware de red

Añada las direcciones IP de cloud RADIUS y los secretos compartidos a sus controladores inalámbricos o puntos de acceso. Configure siempre tanto el endpoint principal como el secundario para utilizar la redundancia integrada del proveedor. Asegúrese de que los puertos UDP 1812 (autenticación) y 1813 (contabilidad) estén abiertos de salida desde sus puntos de acceso hacia los endpoints de cloud RADIUS. Verifique esto antes de la puesta en marcha. Las reglas de firewall mal configuradas son la segunda causa más común de fallos de implementación.

Cloud RADIUS funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Los pasos de configuración varían según el proveedor, pero el protocolo RADIUS está estandarizado, por lo que los parámetros principales (IP del servidor, secreto compartido, puerto de autenticación) son consistentes.

Paso 4: Definir políticas de VLAN

Configure la asignación dinámica de VLAN en su motor de políticas RADIUS. Asocie cada rol de usuario o tipo de dispositivo a un ID de VLAN específico. Pruebe cada política antes de implementarla en producción. Una matriz de prueba sencilla (un dispositivo por rol, una VLAN por rol, verificar la asignación) detecta la mayoría de los errores de configuración antes de que afecten a los usuarios.

Buenas prácticas

Exija EAP-TLS para todos los dispositivos corporativos. Abandone PEAP-MSCHAPv2 tan rápido como lo permita la implementación de su MDM. PEAP se basa en contraseñas, que pueden verse comprometidas. EAP-TLS se basa en certificados, que no pueden verse comprometidos.

Segmente todo. Nunca coloque al personal, a los invitados y a los dispositivos IoT en la misma subred. Utilice RADIUS para imponer límites estrictos de VLAN. Esto es fundamental para entornos de Retail que gestionan datos de tarjetas de pago bajo la normativa PCI DSS, y para entornos de Healthcare que protegen datos de pacientes.

Alinéese con WPA3-Enterprise. WPA3-Enterprise, el estándar actual de seguridad WiFi, requiere autenticación 802.1X. Asegúrese de que sus puntos de acceso admitan WPA3-Enterprise y configúrelo como el estándar de seguridad mínimo para las redes del personal.

Audite sus registros de RADIUS con regularidad. Cloud RADIUS proporciona registros de auditoría centralizados. Revise los fallos de autenticación semanalmente. Un aumento repentino de los fallos desde un dispositivo o ubicación específicos es un indicador temprano de una configuración incorrecta o de un posible ataque.

Pruebe la conmutación por error. Al menos una vez al trimestre, simule un fallo en el endpoint principal de RADIUS y verifique que la autenticación continúa a través del endpoint secundario. Documente el resultado. Esta es una prueba sencilla que la mayoría de los equipos nunca realizan hasta que la necesitan.

Para los establecimientos que implementan WiFi en entornos complejos, incluidas ubicaciones marítimas o remotas, consulte nuestra guía sobre cómo configurar un Captive Portal en Starlink para conocer las consideraciones sobre la dependencia de la red WAN.

Resolución de problemas y mitigación de riesgos

Tiempos de espera de autenticación

Si los dispositivos no se autentican, compruebe primero la conectividad entre sus puntos de acceso y los endpoints de cloud RADIUS. Verifique que los puertos UDP 1812 y 1813 estén abiertos de salida. La inspección profunda de paquetes en los firewalls modernos puede retrasar o descartar los paquetes RADIUS. Si observa tiempos de espera, compruebe si en su política de firewall hay reglas que puedan estar inspeccionando o limitando el tráfico UDP hacia los endpoints de RADIUS.

Fallos en la cadena de confianza del certificado

Si utiliza EAP-TLS, asegúrese de que los dispositivos cliente confíen en la CA raíz que emitió el certificado del servidor RADIUS. Si la cadena de confianza está rota, el dispositivo rechazará silenciosamente la conexión para evitar un ataque de intermediario (man-in-the-middle). Esto se manifiesta como un fallo de conexión sin un mensaje de error evidente. Compruebe los registros del servidor RADIUS para Fallos en el protocolo de enlace EAP-TLS. Implemente el certificado de CA raíz en todos los dispositivos gestionados a través de MDM.

Dependencia de la WAN

Cloud RADIUS requiere una conexión activa a internet. Si el enlace WAN falla, las solicitudes de autenticación no pueden llegar al servidor. Para recursos locales de misión crítica, evalúe puntos de acceso que admitan la supervivencia local o el almacenamiento en caché de autenticación. Para la mayoría de las implementaciones, la dependencia de la WAN es aceptable porque, de todos modos, un sitio sin internet no puede acceder a las aplicaciones en la nube.

Discrepancias en el secreto compartido

Cada punto de acceso o controlador inalámbrico debe configurarse como un cliente RADIUS con el secreto compartido correcto. Una discrepancia provoca que todas las solicitudes de autenticación de ese dispositivo se descarten silenciosamente. Si un punto de acceso específico falla mientras otros funcionan correctamente, verifique la configuración del secreto compartido en ese dispositivo.

ROI e impacto empresarial

El caso de negocio para RADIUS como servicio se basa en tres pilares: reducción de los gastos de capital, menor sobrecarga operativa y una mejor postura de seguridad.

En cuanto a los gastos de capital, se elimina el coste de adquisición, licencia y renovación de servidores físicos. Una implementación mínima viable de RADIUS local requiere dos servidores para alta disponibilidad, licencias de sistema operativo y renovación de hardware cada tres o cinco años. Para un grupo hotelero de 50 propiedades, esto representa una inversión significativa en hardware en todo su patrimonio.

En cuanto a la sobrecarga operativa, su equipo de ingeniería ya no dedicará tiempo a parchear Windows Server, solucionar problemas de configuración de FreeRADIUS o gestionar renovaciones de certificados en la infraestructura física. Ese tiempo se redirige a tareas de políticas de seguridad que mejoran directamente su postura.

En cuanto a la postura de seguridad, la transición a EAP-TLS y la asignación dinámica de VLAN reduce significativamente la superficie de ataque. El robo de credenciales es la principal causa de brechas de red. Eliminar las contraseñas del proceso de autenticación de red aborda directamente ese riesgo. El registro de auditoría centralizado facilita el cumplimiento de PCI DSS v4.0 y GDPR, reduciendo el coste y la complejidad de las auditorías de cumplimiento.

Para las organizaciones que gestionan centros de transporte o espacios de gran afluencia, la capacidad de aplicar políticas de seguridad coherentes en todas las ubicaciones desde un único panel de control es una mejora operativa medible. Purple opera en más de 80.000 espacios activos y ha procesado 440 millones de inicios de sesión en 2024 (datos internos de Purple, 2024). La infraestructura que soporta esa escala es nativa de la nube por diseño.

Para obtener una visión más amplia de cómo el análisis de WiFi y la inteligencia de red se conectan con los resultados comerciales, consulte nuestra plataforma de WiFi Analytics .

Referencias

[1] IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control. IEEE Std 802.1X-2020. [2] IETF. Remote Authentication Dial In User Service (RADIUS). RFC 2865. 1997. [3] IETF. The EAP-TLS Authentication Protocol. RFC 5216. 2008. [4] IronWiFi. Benefits of a Cloud RADIUS Server: Why Enterprises Are Moving Authentication Online. Febrero de 2026. [5] SecureW2. Cloud vs. On-Site RADIUS: Which is Better? Mayo de 2026. [6] Portnox. RADIUS as a Service. 2026. [7] PCI Security Standards Council. PCI DSS v4.0. Marzo de 2022. [8] Purple. Datos internos de la plataforma: 440 millones de inicios de sesión, más de 80.000 espacios. 2024.

Definiciones clave

RADIUS

Remote Authentication Dial-In User Service. A networking protocol defined in RFC 2865 that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network service.

IT teams use RADIUS as the central decision engine to verify whether a device or user is allowed onto the corporate WiFi network. It sits between the access point and the identity provider.

802.1X

An IEEE Standard for port-based Network Access Control. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN, forcing them to authenticate before receiving an IP address.

This is the standard that underpins enterprise WiFi security. Without 802.1X, any device that connects to the SSID gets network access. With 802.1X, every device must prove its identity first.

EAP-TLS

Extensible Authentication Protocol - Transport Layer Security. An authentication method defined in RFC 5216 that requires both the client device and the RADIUS server to present digital certificates, providing mutual authentication without passwords.

Considered the gold standard for enterprise WiFi security. Certificates are deployed to corporate devices via MDM. EAP-TLS eliminates the risk of password theft and phishing attacks on the network.

PEAP

Protected Extensible Authentication Protocol. An EAP method that tunnels a username and password exchange inside a TLS session. Less secure than EAP-TLS because it relies on passwords.

PEAP-MSCHAPv2 is widely deployed in legacy environments. IT teams should plan a migration to EAP-TLS for corporate devices, using PEAP only as a fallback for unmanaged or BYOD devices.

Dynamic VLAN assignment

A process where the RADIUS server instructs the access point which Virtual LAN to place a device in, based on the user's verified identity and role, rather than the SSID they connected to.

Essential for network segmentation in multi-role environments. A single 'Staff' SSID can securely separate housekeeping, reception, and management traffic into different VLANs with different access rights.

AAA

Authentication, Authorisation, and Accounting. The three functions performed by a RADIUS server: verifying identity (authentication), determining what access is permitted (authorisation), and recording session data for audit purposes (accounting).

IT teams and auditors use AAA as a framework for evaluating network access control. Cloud RADIUS delivers all three functions from a managed service.

WPA3-Enterprise

The current WiFi security standard for enterprise networks, requiring 802.1X authentication via a RADIUS server. It offers improved cryptographic strength over WPA2-Enterprise, including 192-bit security mode for high-security environments.

IT managers should configure WPA3-Enterprise as the minimum security standard for staff networks. Guest networks can use WPA2 or open authentication with a captive portal.

Network Access Control (NAC)

A security approach that enforces policy on devices seeking to access network resources, combining endpoint security assessment, identity authentication, and network enforcement.

RADIUS is a foundational component of NAC. Cloud RADIUS extends NAC to distributed, multi-site environments without requiring on-premise infrastructure at each location.

Captive portal

A web page that a user of a public-access network must interact with before being granted internet access. Typically used for Guest WiFi to collect consent or display terms of use.

Captive portals handle unauthenticated guest access, while 802.1X handles authenticated staff access. The two mechanisms operate on separate SSIDs and VLANs.

Ejemplos prácticos

A 200-room hotel needs to secure its staff network across housekeeping, reception, and management, while keeping Guest WiFi entirely separate. They currently use a shared PSK for the staff network, which has not been changed in two years.

Deploy RADIUS as a Service integrated with Microsoft Entra ID. Configure the Cisco Meraki access points to use WPA3-Enterprise with 802.1X. Housekeeping staff authenticate using their Entra ID credentials; the RADIUS server reads their directory group and dynamically assigns them to VLAN 10 (housekeeping task system access only). Reception staff are assigned to VLAN 20 (property management system access). Management are assigned to VLAN 30 (broader access). Guest WiFi remains on a separate SSID with a captive portal, isolated on VLAN 40. When a seasonal staff member leaves, their Entra ID account is disabled, instantly revoking WiFi access across all access points on the property.

Comentario del examinador: This approach eliminates the shared PSK vulnerability and the risk of former employees retaining access. Dynamic VLAN assignment ensures a compromised housekeeping device cannot reach the property management system. Using cloud RADIUS removes the need for a physical server in the hotel's limited IT closet. The integration with Entra ID means offboarding is a single action with immediate network-wide effect.

A national retail chain with 400 stores needs to ensure PCI DSS compliance for its point-of-sale terminals. They currently manage 400 separate FreeRADIUS instances on local store servers, each requiring individual patching.

Migrate to a single RADIUS as a Service instance. Configure HPE Aruba access points at all 400 stores to authenticate POS devices using EAP-TLS with machine certificates pushed via Microsoft Intune. The cloud RADIUS server authenticates the certificates and places POS devices into a PCI-compliant VLAN (VLAN 30), isolated from all other network traffic. Store staff use a separate SSID authenticated via Okta, placing them in a general staff VLAN (VLAN 20). Shoppers on the guest network are isolated on VLAN 40. The security team manages all policies from a single dashboard.

Comentario del examinador: Centralising the RADIUS infrastructure eliminates the maintenance burden of patching 400 local servers. Using EAP-TLS for POS devices removes passwords entirely, preventing credential theft. This architecture satisfies PCI DSS v4.0 Requirement 8 (unique authentication) and Requirement 1 (network segmentation). When a vulnerability is disclosed, the provider patches the cloud infrastructure rather than the retail chain's security team patching 400 servers over several weeks.

Preguntas de práctica

Q1. Your university campus currently uses Microsoft NPS on Windows Server to authenticate students via PEAP-MSCHAPv2. The institution is migrating to Google Workspace and wants to decommission all on-premise servers within 12 months. What is the most secure and operationally efficient architectural change for the WiFi authentication infrastructure?

Sugerencia: Microsoft NPS does not natively support Google Workspace. Consider what replaces both the server and the authentication method.

Ver respuesta modelo

Migrate to RADIUS as a Service with native Google Workspace integration. The cloud RADIUS service connects directly to Google Workspace via LDAP or OIDC, eliminating the need for Active Directory or NPS. Simultaneously, transition managed student and staff devices from PEAP-MSCHAPv2 to EAP-TLS by deploying client certificates via the institution's MDM platform. This removes passwords from the authentication process and ensures that only managed, trusted devices can access the staff and student networks. The migration can be phased: deploy cloud RADIUS alongside NPS, migrate one SSID at a time, then decommission NPS once all devices are using the new service.

Q2. A stadium with 80,000 capacity requires secure WiFi for corporate staff, ticketing terminals, media press members, and event-day contractors. How should the network be configured using cloud RADIUS to enforce appropriate access for each group?

Sugerencia: Consider how RADIUS handles authorisation, not just authentication. Each group needs different access rights.

Ver respuesta modelo

Deploy a single 802.1X SSID for all authenticated groups. Configure the cloud RADIUS service to use dynamic VLAN assignment based on the user's role in the identity provider. Corporate staff are assigned to VLAN 10 with access to internal systems. Ticketing terminals, authenticated via machine certificates (EAP-TLS), are placed in a restricted VLAN 20 with access only to the ticketing platform. Media press members are assigned to VLAN 30 with high-bandwidth internet access but no access to internal systems. Event-day contractors are assigned to VLAN 40 with limited internet access only. A separate open SSID with a captive portal handles fan and attendee guest access on VLAN 50, isolated from all other traffic.

Q3. During a security audit, it is discovered that your organisation's FreeRADIUS server has not received a security patch for eight months. The team has been reluctant to patch it because the last update caused a two-hour authentication outage. How does migrating to RADIUS as a Service resolve both the security risk and the operational risk?

Sugerencia: Consider the division of responsibility in a managed service model and how providers handle patching without downtime.

Ver respuesta modelo

RADIUS as a Service shifts the responsibility for OS patching and vulnerability management to the provider. The provider operates highly available, multi-region clusters, allowing them to patch individual endpoints and roll updates progressively without causing authentication downtime. Your team no longer needs to schedule maintenance windows or accept the risk of a patch-induced outage. The security risk is eliminated because the provider patches the infrastructure as vulnerabilities are disclosed, often before the CVE is widely publicised. The operational risk is eliminated because the provider's SLA guarantees uptime regardless of patching activity. Your team's role changes from infrastructure maintenance to policy management.

Continúe leyendo esta serie

Integración de RADIUS as a Service con directorios en la nube (Azure AD y Google Workspace)

Esta guía de referencia técnica detalla cómo integrar RADIUS as a Service con directorios en la nube (Microsoft Entra ID y Google Workspace) para la autenticación WiFi empresarial. Cubre la transición arquitectónica de NPS local a RADIUS nativo de la nube, el despliegue de la autenticación EAP-TLS basada en certificados y las mejores prácticas operativas para proteger el acceso inalámbrico en entornos de hostelería, comercio minorista y sector público. Para los responsables de TI y arquitectos de redes que ya han invertido en identidad en la nube, esta guía cierra la brecha entre la gestión de directorios y la seguridad de la red física.

How to Implement 802.1X Authentication with Cloud RADIUS

Esta guía de referencia técnica proporciona un marco integral para implementar la autenticación 802.1X con Cloud RADIUS en entornos empresariales distribuidos. Detalla la arquitectura, la selección del método EAP, la secuencia de implementación y las estrategias de mitigación de riesgos necesarias para asegurar el acceso a la red, eliminando al mismo tiempo la sobrecarga operativa de la infraestructura local.

What is Cloud RADIUS? A Comprehensive Guide to RADIUS as a Service

Esta guía completa explora Cloud RADIUS (RADIUS como servicio), detallando su arquitectura, métodos EAP y estrategias de implementación. Proporciona a los líderes de TI información práctica sobre la migración de servidores locales a un modelo de autenticación basado en la nube escalable, seguro y conforme.