Está observando un Network Policy Server que nadie quiere actualizar, un controlador inalámbrico que apunta a un único servidor RADIUS en una sala de comunicaciones y una cola de soporte técnico llena de restablecimientos de contraseñas. La identidad se ha movido a Microsoft Entra ID u Okta, pero la autenticación WiFi todavía depende de la infraestructura local creada para Active Directory local. Esa discrepancia es el punto de partida en el que las organizaciones empiezan a considerar un servidor radius en la nube, no porque mover un servidor sea emocionante, sino porque el modelo antiguo ya no se adapta a cómo funcionan los usuarios, los dispositivos y las sedes.
Qué es un servidor Cloud RADIUS
Imagine RADIUS como un guardia de seguridad en la entrada de un edificio. Llega una persona, muestra una acreditación y el guardia la comprueba en una lista autorizada antes de abrir la puerta. Si la acreditación es válida, el guardia también decide a qué plantas puede acceder esa persona. Si no lo es, la puerta permanece cerrada.
Un servidor RADIUS en la nube traslada a esa garita de seguridad desde una caseta local hasta un servicio gestionado centralmente. La comprobación sigue realizándose en la entrada, que en términos de WiFi es su punto de acceso o switch. Sin embargo, la decisión procede de un servicio alojado que usted configura mediante directivas en lugar de servidores que tenga que parchear, respaldar y agrupar en clusters usted mismo.
Cómo funciona el flujo de autenticación
Un portátil o teléfono se conecta a un SSID WPA2 o WPA3 Enterprise protegido por 802.1X. El punto de acceso no decide por sí solo; reenvía la solicitud de autenticación al servidor RADIUS en la nube, que valida la credencial, el certificado o la identidad del dispositivo en su directorio o autoridad de certificación.
El servidor devuelve una aceptación o rechazo, a menudo con atributos como una VLAN, un rol o un límite de sesión. El punto de acceso aplica esa decisión de forma local. Esa separación es importante, porque RADIUS es el punto de decisión, no la red completa ni su propio proveedor de identidades.
- Suplicante: El portátil, teléfono o dispositivo que solicita acceso y presenta un credencial o certificado.
- Autenticador: El punto de acceso, controlador o conmutador que reenvía la solicitud y aplica el resultado.
- Fuente de identidad: Microsoft Entra ID, Okta, Google Workspace, Active Directory o una autoridad de certificación que posee el registro autoritativo.
Por qué el modelo híbrido es el punto de partida habitual
Las organizaciones del Reino Unido no migraron todo a la nube en un solo paso. Cloud Industry Forum informó que el 84 % de las organizaciones del Reino Unido había adoptado formalmente al menos un servicio en la nube en su estudio de 2016, frente al 48 % en 2010, lo que ayuda a explicar por qué RADIUS en la nube se implementa habitualmente como parte de una arquitectura híbrida en lugar de como un reemplazo inmediato para cada componente local, tal como se expone en la investigación de adopción de la nube en el Reino Unido de 2016 de Cloud Industry Forum.
En la práctica, sus switches, puntos de acceso, impresoras y sistemas heredados permanecen en las instalaciones. Lo que cambia es dónde se toma la decisión de autenticación y la coherencia con la que puede aplicarla en las distintas sedes. Es una definición más precisa y útil que calificarlo como un mero intercambio de servidores alojados.
Cloud RADIUS frente a RADIUS local
Una comparación honesta no consiste en decir que la nube es buena y lo local es malo. Se trata de quién asume la carga operativa, cuánto control necesita y qué falla cuando algo se rompe. Un par local bien gestionado puede funcionar durante años; uno descuidado se convierte en un punto único de fallo que nadie se atreve a tocar.
Los entornos del Reino Unido también siguen siendo mixtos. Una revisión del gobierno del Reino Unido de 2025 reveló que aproximadamente el 55 % de las organizaciones del gobierno central declaró tener más del 60 % de su entorno tecnológico en la nube, mientras que alrededor del 28 % de los entornos tecnológicos del gobierno central seguían siendo heredados, según la State of Digital Government Review. Esa combinación es exactamente la razón por la que aún necesita conectar la identidad en la nube con los edificios y las redes inalámbricas que permanecen en las instalaciones.
Coste y mantenimiento frente a frente
| Criterio | Cloud RADIUS | RADIUS On-Premises |
|---|---|---|
| Coste de capital | Bajo, basado en suscripción | Mayor inversión inicial en hardware y licencias |
| Mantenimiento | El proveedor aplica parches y opera el servicio | Su equipo aplica parches al sistema operativo, RADIUS y certificados |
| Escalabilidad | Añada sedes mediante configuración | Añada servidores, clústeres y equilibrio de carga |
| Control | Control de políticas, menor control sobre la infraestructura | Control total, responsabilidad total |
| Resiliencia | Endpoints redundantes proporcionados por el proveedor | Usted mismo diseña y prueba la conmutación por error |
FreeRADIUS parece gratuito hasta que se calcula el tiempo de los ingenieros, las renovaciones de certificados, la supervisión y la resolución de problemas fuera de horario. Microsoft NPS parece incluido hasta que necesita una integración nativa con un directorio en la nube para el que no fue diseñado. Cisco ISE ofrece funciones de directivas avanzadas, pero implica licencias y conocimientos especializados que muchos equipos no pueden justificar solo para la red WiFi.
El error de concepto sobre la seguridad
La ubicación del servidor no hace que la autenticación sea segura. La configuración, la integración de identidades, el transporte cifrado y la supervisión sí lo hacen.
La nube desplaza el riesgo en lugar de eliminarlo. Se obtiene un parcheado coherente y directivas para múltiples ubicaciones, pero se pasa a depender de la conectividad a Internet, del plano de control del proveedor y del proveedor de identidades. La infraestructura local mantiene el tráfico en el ámbito interno, pero un único servidor sin parchear con secretos compartidos en todas partes no es más seguro solo por estar ubicado en sus instalaciones.
Elija la nube cuando no disponga del personal adecuado para gestionar un par en alta disponibilidad de forma correcta, opere en múltiples sedes o ya haya migrado la identidad a la nube. Manténgase en la infraestructura local cuando la normativa, la latencia o una sede desconectada requieran verdaderamente decisiones locales. Muchas migraciones de RR. HH. y TI siguen la misma lógica híbrida, motivo por el cual esta guía para equipos de RR. HH. con Microsoft 365 es una lectura paralela muy útil sobre cómo migrar sistemas centrales sin pretender que los entornos heredados desaparezcan de la noche a la mañana.
Integración con Microsoft Entra ID, Okta y certificados
Un servidor RADIUS en la nube demuestra su valor en los puntos de integración. Si no puede comunicarse de forma limpia con su directorio, su autoridad de certificación y sus flujos de invitados, habrá comprado un cuello de botella alojado. Establezca patrones de integración correctos y el acceso a la red comenzará a seguir la misma lógica de altas, cambios y bajas que el resto del departamento de TI.
RADIUS en sí no habla la federación web moderna. Si su equipo está aclarando dónde termina la autenticación de red y dónde empieza el inicio de sesión único de las aplicaciones, esta visión general de autenticación SAML y OIDC ayuda a separar esas capas. RADIUS gestiona la admisión a la red, mientras que SAML y OIDC suelen gestionar el inicio de sesión en aplicaciones después de que el usuario ya esté conectado.
Autenticación respaldada por directorio para el personal
Con Microsoft Entra ID u Okta, el servicio RADIUS verifica al usuario o dispositivo frente a los grupos y atributos del directorio. Un usuario de finanzas puede terminar en un rol diferente al de un contratista de mantenimiento, incluso en el mismo SSID. Cuando el departamento de recursos humanos deshabilita una cuenta, ese cambio debe trasladarse al acceso a la red sin necesidad de enviar una solicitud independiente al equipo de red.
En el caso concreto de Microsoft Entra ID, valide cómo se asignan los grupos, los objetos de dispositivo y las señales condicionales a la directiva RADIUS antes de realizar un despliegue masivo, tal como se explica en esta guía de integración de Microsoft Entra ID RADIUS-as-a-Service. Pruebe una baja de empleado, un cambio de rol y un dispositivo deshabilitado durante la fase piloto. Esos tres casos revelan más que cien inicios de sesión correctos.
Certificados para dispositivos que usted gestiona
EAP-TLS utiliza certificados en ambos extremos, por lo que no hay ninguna contraseña que se pueda cazar mediante phishing, compartir o forzar mediante ataque de fuerza bruta. Es el modelo más sólido para portátiles gestionados, siempre que pueda emitir, renovar y revocar certificados a través de MDM o SCEP sin esfuerzo manual. Si la provisión de certificados falla o es inestable, los usuarios presionarán para volver a las contraseñas y se saldrán con la suya.
- Emitir identidad: envíe un certificado de usuario o dispositivo a través de Intune, Jamf o su MDM con un propietario claro y fecha de caducidad.
- Validar la confianza: configure el servicio RADIUS para que confíe en su CA emisora y verifique el estado de revocación.
- Vincular a la directiva: asocie los campos del certificado y los grupos de directorio a las VLAN o roles en el punto de acceso.
- Revocar rápidamente: elimine el certificado y el acceso al directorio de forma conjunta cuando se pierda un dispositivo o una persona deje la empresa.
Invitados y dispositivos que no pueden realizar 802.1X
Los invitados no deberían necesitar una cuenta corporativa para obtener un acceso seguro. Passpoint y OpenRoaming permiten que un dispositivo se autentique una vez y se reconecte con acceso cifrado en visitas posteriores, lo que resulta idóneo para hoteles, centros de transporte y recintos multisede. Para impresoras, terminales de pago y equipos IoT más antiguos que no pueden presentar certificados, utilice MAC authentication bypass o claves precompartidas individuales con una segmentación estricta, y trate a esos dispositivos como no fiables por defecto.
Consideraciones de seguridad y Zero-Trust
Trate un servidor RADIUS en la nube como un límite de confianza, no como una simple herramienta de utilidad. Decide quién accede a su red, se comunica con su directorio y su consola de administración puede cambiar la directiva de todas las sedes a la vez. Esa concentración de poder es útil, y es exactamente por lo que los controles que la rodean requieren un examen minucioso.
El NCSC recomienda que las interfaces de servicios cloud permitan el acceso únicamente a identidades autenticadas y autorizadas, con autenticación contextual mediante aserciones criptográficas o intercambio seguro de claves, tal como se describe en el Principio 10 del NCSC sobre identidad y autenticación. En el caso de cloud RADIUS, esto significa tratar el servicio y sus interfaces administrativas como límites de confianza independientes, con identidades de servicio únicas, permisos estrictamente acotados y eventos de autenticación auditables, en lugar de utilizar credenciales de administración compartidas.
Deje de confiar en la ubicación de la red
El modelo Zero Trust cambia la pregunta de "¿está este dispositivo en nuestra VLAN?" a "¿quién es este usuario, qué dispositivo es este y a qué debería acceder ahora mismo?". La presencia en una VLAN corporativa o de invitados no es prueba de autorización. El acceso debe seguir siendo condicional a la identidad autenticada y a la directiva para esa sesión, inquilino y ubicación.
Ese principio tiene consecuencias prácticas para el diseño de la red WiFi. El portátil de un contratista y el de un empleado de finanzas pueden compartir un SSID, pero no deberían compartir alcance. Su conjunto general de controles debe alinearse con una guía de seguridad WiFi empresarial para acceso a la red de cero confianza para que las decisiones de autenticación se conecten con la segmentación, la supervisión y el privilegio mínimo, y no solo con conectarse.
Controles que debe exigir a un proveedor
- Transporte cifrado: RadSec o protección equivalente para el tráfico RADIUS, además de TLS moderno para API y acceso de administración.
- Rotación y revocación: Rotación documentada de certificados y secretos, y revocación rápida cuando se desactivan cuentas o dispositivos.
- Administración basada en roles: Roles separados de lector, operador y administrador, sin credenciales compartidas para cambios de directivas.
- Registros que puede utilizar: Eventos de autenticación, cambios de directivas y acciones de administración exportados a su SIEM con una retención clara.
Regla práctica: Si comprometer una ubicación o una cuenta de integración otorga a un atacante autoridad sobre otros clientes o sobre el plano de control, el diseño ha fallado.
Haga preguntas comprometidas desde el principio. Quién puede ver los registros de autenticación, dónde se almacenan y cómo se separa el acceso de gestión del proveedor respecto a su plano de datos. Si un proveedor no puede responder con claridad, eso ya es una respuesta.
Patrones de despliegue para WiFi empresarial y multiinquilino
Un hotel en el proceso de registro, una planta hospitalaria con dispositivos médicos y un centro comercial un sábado no comparten el mismo perfil de riesgo. Pueden compartir un servidor RADIUS en la nube, siempre que cada colectivo tenga su propia directiva y la red aplique la separación tras la autenticación. El error es asumir que un inicio de sesión correcto equivale a una red segmentada.
Los datos de la encuesta gubernamental indican que el 85 % de las grandes empresas del Reino Unido mantenía redes WiFi separadas para el personal y los visitantes, por debajo del 93 % anterior, en el capítulo sobre controles de seguridad de red de la Cyber Security Breaches Survey 2025. La separación no es un problema resuelto, ni siquiera para las grandes organizaciones. Por lo tanto, RADIUS en la nube debe combinarse con VLAN dinámicas o la aplicación de directivas para ofrecer una segmentación real, no solo una autenticación más agradable.
Lo que realmente necesita cada ubicación
En el sector hostelero, los huéspedes se autentican a su llegada, los dispositivos del personal se verifican en el directorio y las terminales de pago se ubican en un segmento restringido que no puede ver a ninguno de los dos. En el sector sanitario, el personal clínico, los celadores, los pacientes y el equipamiento médico coexisten, y parte de ese equipamiento nunca admitirá certificados. La directiva debe reflejar esa realidad en lugar de forzar a cada dispositivo a entrar en un único modelo.
Las cadenas comerciales se enfrentan a un problema de escala más que a un problema de complejidad en cada tienda. La sede central quiere un acceso de personal homogéneo y una separación de invitados consistente en cada sucursal sin tener que enviar servidores a cada ubicación. Los centros de transporte añaden itinerancia, donde un viajero espera que la conexión en la que se inscribió en una estación funcione en la siguiente. Un servicio centralizado se adapta a ambos patrones porque la directiva viaja con la identidad.
Los edificios multiinquilino necesitan aislamiento por diseño
Los residentes en viviendas de alquiler institucional (build-to-rent) o residencias de estudiantes esperan una experiencia WiFi doméstica, pero los dispositivos de cada hogar deben permanecer invisibles para los vecinos. Esto requiere directivas por inquilino, claves individuales para dispositivos heredados y un acceso del personal que no interfiera en las redes de los residentes. Vale la pena revisar una guía de WiFi multi-tenant para redes de residentes aisladas junto con su diseño de RADIUS, ya que la autenticación solo es útil si la separación subyacente entre inquilinos es sólida.
Antes del despliegue, mapee cada clase de dispositivo que tenga, no solo la lista ordenada del registro de activos. El personal, los invitados, los contratistas, el IoT, las cajas registradoras, los escáneres y la antigua impresora de contabilidad necesitan una ruta definida. Los dispositivos que no planifica se convierten en la excepción que debilita la directiva.
Buenas prácticas para la implementación y la operación
La mayoría de los problemas de RADIUS en la nube no son problemas de protocolo. Son sorpresas operativas que nadie ha probado, como una cuenta revocada que sigue funcionando, una sede que pierde el acceso a Internet o un inicio de sesión de emergencia que no deja registro de auditoría. Planifique estos casos antes de que la primera sede entre en funcionamiento, no durante la primera caída del servicio.
El estudio Cyber Security Breaches Survey 2025 del Gobierno del Reino Unido reveló que el 43 % de las empresas notificaron una brecha o ataque en los últimos 12 meses, pero solo el 31 % realizó evaluaciones formales de ciberriesgo, tal como se informa en las conclusiones del Cyber Security Breaches Survey 2025 a 2026. Esa brecha es la razón por la que necesita respuestas explícitas sobre la interrupción del proveedor, la caída del proveedor de identidad y la pérdida de conectividad, además de un acceso de emergencia auditado.
Defina el comportamiento en caso de fallo por SSID
Decida por escrito dónde la autenticación falla en modo cerrado (fail-closed) y dónde es aceptable una alternativa acotada. Los SSID del personal con privilegios y los segmentos confidenciales deben fallar en modo cerrado, ya que permitir el acceso abierto durante una interrupción anula el propósito de 802.1X. Los servicios críticos para las operaciones pueden justificar una alternativa con un alcance muy definido y limitada en el tiempo, pero debe ser objeto de alarmas, registros y revisiones.
- Realice una prueba piloto en una sede y un SSID: Compruebe la autenticación, la asignación de VLAN y el registro con dispositivos reales, incluido el hardware compatible más antiguo.
- Aísle y pruebe fallos a propósito: Desactive una cuenta de prueba, revoque un certificado y simule la pérdida del endpoint primario; a continuación, mida la experiencia de los usuarios.
- Mida la velocidad de revocación: Mida cuánto tiempo tarda una cuenta de Microsoft Entra ID u Okta desactivada en perder el acceso a la red y registre el resultado en el libro de operaciones.
- Pruebe la ruta de salida: Confirme que puede exportar la configuración y los registros, y redirigir los puntos de acceso a otro servicio sin tener que reconstruir las políticas desde cero.
Opérelo como una infraestructura crítica
Supervise las tasas de éxito y error de autenticación, el estado de los puntos finales y los picos inusuales por ubicación. Revise los registros en busca de fallos repetidos desde un único dispositivo, ya que a menudo se trata de una configuración incorrecta, un certificado caducado o un intento de exploración de su red. Acuerde la retención de registros, las necesidades de residencia de datos según el UK GDPR y la respuesta de soporte en el contrato, no en una llamada comercial.
No mida el éxito según si 802.1X está activado. Mida si el aislamiento funciona, si la revocación es rápida y si una sede se degrada de forma predecible cuando cae la conectividad.
Revise el riesgo de los proveedores anualmente, incluidos los subencargados del tratamiento y el lugar de origen del acceso de soporte. Mantenga un procedimiento operativo breve que un ingeniero de guardia pueda seguir por la noche sin el equipo del proyecto. Si ese manual no existe, aún no tiene un modelo operativo.
Puntos clave y siguientes pasos
Un servidor RADIUS en la nube tiene sentido cuando la identidad ya reside en la nube, se gestionan múltiples ubicaciones o su equipo no puede operar un par local resiliente con un nivel de calidad alto. Elimina el mantenimiento de servidores y centraliza las directivas. Sin embargo, no elimina su responsabilidad sobre la segmentación, la revocación, el registro de eventos o la planificación ante interrupciones del servicio.
Tampoco es segmentación por sí sola. La autenticación decide quién dice ser un dispositivo. Las VLAN dinámicas, las directivas basadas en roles y las reglas de mínimo privilegio deciden a qué puede acceder ese dispositivo, y necesita que ambas funcionen de forma conjunta.
Una breve lista de verificación para la evaluación
- Ajuste de identidad: Integración nativa con su directorio y comportamiento probado ante altas, cambios de rol y bajas de usuarios.
- Gestión de certificados: Emisión, renovación y revocación gestionadas que su parque de dispositivos pueda admitir.
- Comportamiento ante fallos: Bloqueo seguro (fail closed) para SSID sensibles, con cualquier alternativa de reserva limitada en alcance, registrada y con límite de tiempo.
- Evidencias: Registros exportables, residencia de datos clara, administración basada en roles y separación entre clientes (multi-tenant).
- Salida: Exportación de configuración y registros, de modo que abandonar el proveedor sea un proyecto estructurado y no una reconstrucción desde cero.
Comience con un piloto en una ubicación o SSID, mida el éxito de la autenticación y la latencia de revocación, y fuerce el fallo de la integración a propósito antes de que los usuarios dependan de ella. Escale solo cuando esos resultados sean rutinarios. La rutina es el aspecto que tiene una buena autenticación en producción.
Purple ofrece RADIUS-as-a-Service para WiFi de invitados, empleados y entornos multi-tenant, integrándose con Entra ID, Google Workspace y Okta para que pueda retirar los servidores RADIUS locales y aplicar un acceso coherente y basado en la identidad en todas sus instalaciones. Si está planificando un piloto o reemplazando una configuración frágil de NPS o FreeRADIUS, visite Purple para ver cómo el RADIUS gestionado en la nube, Passpoint y el aislamiento por inquilino funcionan con su infraestructura existente de Meraki, Aruba, Ruckus, Mist o UniFi.
