Está observando un Network Policy Server que nadie quiere parchear, un controlador inalámbrico que apunta a un solo equipo RADIUS en una sala de comunicaciones y una cola de soporte 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 en las instalaciones. Ese desajuste es el punto en el que las organizaciones comienzan a evaluar 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 los sitios.
Qué es un servidor Cloud RADIUS
Imagine RADIUS como un guardia de seguridad en la entrada de un edificio. Llega una persona, muestra una credencial y el guardia la verifica en una lista de autorizados antes de abrir la puerta. Si la credencial es válida, el guardia también decide a qué pisos puede acceder esa persona. Si no lo es, la puerta permanece cerrada.
Un servidor cloud RADIUS traslada a esa casilla de vigilancia de una caseta local a un servicio administrado de forma centralizada. La verificación aún ocurre en la puerta, que en términos de WiFi es su punto de acceso o switch. La decisión, sin embargo, proviene de un servicio alojado que usted configura mediante políticas en lugar de servidores a los que deba aplicar parches, respaldar y agrupar en clusters usted mismo.
Cómo funciona el flujo de autenticación
Una laptop o teléfono se conecta a un SSID WPA-Enterprise protegido por 802.1X. El punto de acceso no toma la decisión por sí solo, sino que reenvía la solicitud de autenticación al servidor RADIUS en la nube, el cual 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: La laptop, teléfono o dispositivo que solicita acceso y presenta una credencial o certificado.
- Autenticador: El punto de acceso, controlador o switch 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 fidedigno.
Por qué el entorno híbrido es el punto de partida habitual
Las organizaciones del Reino Unido no movieron todo a la nube de un solo paso. El Cloud Industry Forum informó que el 84% de las organizaciones del Reino Unido habían adoptado formalmente al menos un servicio en la nube en su investigación de 2016, frente al 48% en 2010, lo que ayuda a explicar por qué RADIUS en la nube generalmente se implementa como parte de una arquitectura híbrida en lugar de como un reemplazo inmediato para cada componente local, tal como se expone en el estudio Cloud Industry Forum UK cloud adoption research for 2016.
En la práctica, sus switches, puntos de acceso, impresoras y sistemas heredados permanecen en el sitio. Lo que cambia es dónde se toma la decisión de autenticación y qué tan consistentemente puede aplicarla en todas las sedes. Esa es una definición más precisa y útil que llamarla una sustitución de servidor alojado.
Cloud RADIUS vs RADIUS local
La comparación honesta no es "la nube es buena, las instalaciones locales son malas". Se trata de quién lleva la carga operativa, cuánto control necesita y qué falla cuando algo se interrumpe. Un par local bien administrado puede funcionar durante años; uno descuidado se convierte en un punto único de falla que nadie se atreve a tocar.
Las propiedades del Reino Unido también siguen siendo mixtas. Una revisión del gobierno del Reino Unido de 2025 encontró que aproximadamente el 55% de las organizaciones del gobierno central reportaron tener más del 60% de su infraestructura tecnológica en la nube, mientras que alrededor del 28% de la infraestructura tecnológica del gobierno central permaneció en sistemas 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.
Comparativa de costos y mantenimiento
| Criterio | Cloud RADIUS | RADIUS On-Premises |
|---|---|---|
| Costo 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 SO, RADIUS y certificados |
| Escalabilidad | Agregue sitios mediante configuración | Agregue servidores, enrutamiento en clúster y balanceo de carga |
| Control | Control de políticas, menor control de infraestructura | Control total, responsabilidad total |
| Resiliencia | Endpoints redundantes por parte del proveedor | Usted diseña y prueba la conmutación por error por su cuenta |
FreeRADIUS parece gratuito hasta que se contabiliza el tiempo de los ingenieros, las renovaciones de certificados, el monitoreo y la resolución de problemas fuera del horario laboral. 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 políticas profundas, pero implica licencias y habilidades especializadas que muchos equipos no pueden justificar solo para WiFi.
La idea errónea 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 el monitoreo sí lo hacen.
La nube desplaza el riesgo en lugar de eliminarlo. Se obtiene un parcheo constante y políticas para múltiples sitios, pero se depende de la conectividad a internet, del plano de control del proveedor y del proveedor de identidad. La infraestructura local mantiene el tráfico de forma local, pero un solo servidor sin parchar con secretos compartidos por todas partes no es más seguro solo por estar en su edificio.
Elija la nube cuando no cuente con el personal para operar un par de alta disponibilidad adecuadamente, gestione múltiples sitios o ya haya migrado la identidad a la nube. Permanezca de forma local cuando las regulaciones, la latencia o un sitio desconectado requieran genuinamente decisiones locales. Muchas migraciones de RR. HH. y TI siguen la misma lógica híbrida, por lo que esta guía para equipos de RR. HH. en Microsoft 365 es una lectura paralela útil sobre cómo mover sistemas centrales sin pretender que la infraestructura heredada desaparece 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 las integraciones. Si no puede comunicarse limpiamente con su directorio, su autoridad de certificación y sus flujos de invitados, habrá comprado un cuello de botella alojado. Organice bien los patrones de integración y el acceso a la red comenzará a seguir la misma lógica de altas, cambios y bajas de usuarios que el resto de TI.
RADIUS en sí no maneja la federación web moderna. Si su equipo está aclarando dónde termina la autenticación de red y dónde comienza el inicio de sesión único de las aplicaciones, este resumen 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 las 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 contra los grupos y atributos en el directorio. Un usuario de finanzas puede terminar en un rol diferente al de un contratista de instalaciones, incluso en el mismo SSID. Cuando Recursos Humanos inhabilita una cuenta, ese cambio debe reflejarse en el acceso a la red sin necesidad de enviar un ticket por separado al equipo de red.
Específicamente para Microsoft Entra ID, valide cómo los grupos, los objetos de dispositivo y las señales condicionales se asignan a la política de RADIUS antes de realizar un despliegue masivo, como se explica en esta guía de integración de RADIUS-as-a-Service con Microsoft Entra ID. Pruebe un usuario que se da de baja, un cambio de rol y un dispositivo deshabilitado durante la prueba piloto. Esos tres casos revelan más que cien inicios de sesión exitosos.
Certificados para dispositivos que usted administra
EAP-TLS utiliza certificados en ambos lados, por lo que no hay contraseña que se pueda phishear, compartir o forzar por fuerza bruta. Es el esquema más sólido para laptops administradas, siempre que pueda emitir, renovar y revocar certificados a través de MDM o SCEP sin esfuerzo manual. Si el aprovisionamiento de certificados es inestable, los usuarios lo presionarán para volver a las contraseñas, y ganarán.
- Emitir identidad: Despliegue un certificado de usuario o dispositivo a través de Intune, Jamf o su MDM con un propietario claro y fecha de expiración.
- Validar confianza: Configure el servicio RADIUS para que confíe en su CA emisora y verifique el estado de revocación.
- Vincular a políticas: Mapee los campos del certificado y los grupos de directorio a VLANs o roles en el punto de acceso.
- Revocar rápidamente: Elimine el certificado y el acceso al directorio al mismo tiempo cuando se pierda un dispositivo o una persona deje la empresa.
Invitados y dispositivos que no son compatibles con 802.1X
Los invitados no deberían necesitar una cuenta corporativa para obtener acceso seguro. Passpoint y OpenRoaming permiten que un dispositivo se autentique una vez y se reconecte con acceso encriptado en las siguientes visitas, lo cual es perfecto para hoteles, centros de transporte y recintos con múltiples sedes. Para impresoras, terminales de pago y equipos IoT más antiguos que no pueden presentar certificados, utilice la omisión de autenticación MAC o claves precompartidas individuales con una segmentación estricta, y trate a esos dispositivos como no confiables 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 utilidad conveniente. Este determina quién accede a su red, se comunica con su directorio y su consola de administración puede cambiar las políticas de todas las sedes a la vez. Esa concentración de poder es útil, y es exactamente por eso que los controles a su alrededor requieren una supervisión minuciosa.
El NCSC recomienda que las interfaces de servicios en la nube solo permitan el acceso 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 sobre identidad y autenticación del NCSC. Para Cloud RADIUS, esto significa tratar el servicio y sus interfaces administrativas como límites de confianza independientes, con identidades de servicio únicas, permisos estrictamente delimitados y eventos de autenticación auditables, en lugar de 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 en este momento?". 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 política para esa sesión, inquilino y ubicación.
Ese principio tiene consecuencias prácticas para el diseño de WiFi. La laptop de un contratista y la laptop de finanzas pueden compartir un SSID, pero no deberían compartir alcanzabilidad. Su conjunto de controles más amplio 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, el monitoreo y el privilegio mínimo, no solo con el hecho de conectarse.
Controles que debe exigir a un proveedor
- Transporte cifrado: RadSec o protección equivalente para el tráfico RADIUS, más 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 las cuentas o dispositivos se deshabilitan.
- Administración basada en roles: Roles separados de lector, operador y administrador, sin inicios de sesión compartidos para cambios de políticas.
- Registros que realmente pueda usar: Eventos de autenticación, cambios de políticas y acciones administrativas exportadas a su SIEM con retención clara.
Regla práctica: Si comprometer un recinto o una cuenta de integración le da a un atacante autoridad sobre otros arrendatarios o sobre el plano de control, el diseño ha fallado.
Haga preguntas incómodas 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, esa ya es una respuesta.
Patrones de despliegue para WiFi empresarial y multinquilino
Un hotel al hacer check-in, una sala con dispositivos médicos y un centro comercial un sábado no comparten el mismo perfil de riesgo. Sin embargo, pueden compartir un servidor RADIUS en la nube, siempre y cuando cada grupo reciba su propia política y la red aplique la separación después de la autenticación. El error es asumir que un inicio de sesión exitoso equivale a una red segmentada.
Los datos de la encuesta gubernamental indican que el 85% de las grandes empresas del Reino Unido mantuvieron redes WiFi independientes para el personal y los visitantes, por debajo del 93% anterior, en el capítulo sobre controles de seguridad de red del 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 políticas para brindar una segmentación real, no solo una autenticación más agradable.
Lo que realmente necesita cada sitio
En el sector de la hospitalidad, los huéspedes se autentican a su llegada, los dispositivos del personal se verifican contra 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 salud, el personal clínico, los camilleros, los pacientes y el equipo médico coexisten, y parte de ese equipo nunca admitirá certificados. La política debe reflejar esa realidad en lugar de forzar a cada dispositivo a entrar en un solo modelo.
Las cadenas minoristas se enfrentan a un problema de escala más que a un problema de complejidad en cada tienda. La oficina central desea un acceso constante para el personal y una separación para los invitados en cada sucursal sin tener que enviar servidores a cada ubicación. Los centros de transporte añaden roaming, donde un pasajero espera que la conexión que registró en una estación funcione en la siguiente. Un servicio centralizado se adapta a ambos patrones porque la política viaja con la identidad.
Los edificios multinquilino necesitan aislamiento por diseño
Los residentes en desarrollos build-to-rent o residencias estudiantiles esperan un WiFi similar al de su hogar, pero los dispositivos de cada hogar deben permanecer invisibles para los vecinos. Eso requiere políticas por inquilino, claves individuales para dispositivos heredados y un acceso para el personal que no se filtre a las redes de los residentes. Vale la pena revisar una guía de WiFi multi-inquilino para redes de residentes aisladas junto con su diseño de RADIUS, porque la autenticación solo ayuda si la separación subyacente de inquilinos es sólida.
Antes del despliegue, mapee cada clase de dispositivo que tenga, no la lista ordenada del registro de activos. El personal, los invitados, los contratistas, IoT, las cajas registradoras, los escáneres y la antigua impresora de finanzas necesitan una ruta definida. Los dispositivos que no planifique se convierten en la excepción que debilita la política.
Mejores prácticas para la implementación y operación
La mayoría de los problemas de RADIUS en la nube no son fallas de protocolo. Son sorpresas operativas que nadie probó, como una cuenta revocada que sigue funcionando, una sede que pierde acceso a internet o un inicio de sesión de emergencia que no deja registro de auditoría. Planifique para esos casos antes de que la primera sede esté activa, no durante la primera interrupción del servicio.
La Cyber Security Breaches Survey 2025 del Gobierno del Reino Unido reveló que el 43% de las empresas reportaron una vulneración o ataque en los 12 meses anteriores, pero solo el 31% realizó evaluaciones formales de ciberriesgo, según los hallazgos de la Cyber Security Breaches Survey 2025 a 2026. Esa brecha es la razón por la que necesita respuestas explícitas ante interrupciones del proveedor, caídas del proveedor de identidad y pérdida de conectividad, además de un acceso de emergencia auditado.
Defina el comportamiento en caso de falla por SSID
Decida por escrito dónde la autenticación falla en modo cerrado y dónde es aceptable una alternativa acotada. Los SSID del personal con privilegios y los segmentos sensibles deben fallar en modo cerrado, ya que el acceso abierto durante una interrupción anula el propósito de 802.1X. Los servicios críticos para la operación pueden justificar una alternativa estrictamente delimitada y con límite de tiempo, pero debe ser alertada, registrada y revisada.
- Realice una prueba piloto en un sitio y un SSID: Pruebe la autenticación, asignación de VLAN y registro con dispositivos reales, incluyendo su hardware compatible más antiguo.
- Interrumpa el servicio deliberadamente: Deshabilite una cuenta de prueba, revoque un certificado y simule la pérdida del endpoint primario; después, mida la experiencia de los usuarios.
- Mida la velocidad de revocación: Mida cuánto tiempo mantiene el acceso a la red una cuenta deshabilitada de Microsoft Entra ID u Okta, y registre el resultado en el manual de procedimientos.
- 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 reestructurar las políticas desde cero.
Opérelo como infraestructura crítica
Monitoree las tasas de éxito y falla de autenticación, la salud de los puntos finales y los picos inusuales por sitio. Revise los registros para detectar fallas repetidas desde un solo dispositivo, ya que esto suele deberse a una configuración errónea, un certificado caducado o un intento de sondeo en su red. Acuerde la retención de registros, las necesidades de residencia de datos y la respuesta de soporte en el contrato, no en una llamada de ventas.
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 un sitio se degrada de manera predecible cuando se cae la conectividad.
Revise el riesgo del proveedor anualmente, incluidos los subprocesadores y el origen del acceso de soporte. Mantenga un manual 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 cloud RADIUS tiene sentido cuando la identidad ya vive en la nube, administra múltiples sitios o su equipo no puede operar un par en las instalaciones altamente resistente bajo un estándar elevado. Elimina el mantenimiento del servidor y centraliza las políticas. No elimina su responsabilidad sobre la segmentación, la revocación, el registro de eventos o la planificación ante interrupciones.
Tampoco es segmentación por sí sola. La autenticación decide quién dice ser un dispositivo. Las VLANs dinámicas, las políticas basadas en roles y las reglas de privilegio mínimo deciden a qué puede acceder ese dispositivo, y necesita que ambos funcionen en conjunto.
Una breve lista de verificación para evaluación
- Ajuste de identidad: Integración nativa con su directorio, así como un comportamiento probado para altas, cambios y bajas de usuarios.
- Gestión de certificados: Emisión, renovación y revocación administradas que su parque de dispositivos pueda admitir.
- Comportamiento ante fallas: Cierre de acceso ante fallas para SSIDs confidenciales, con cualquier opción de respaldo delimitada, registrada y de duración limitada.
- Evidencia: Registros exportables, residencia de datos clara, administración basada en roles y separación entre inquilinos.
- Salida: Exportación de configuración y registros, de modo que migrar de proveedor sea un proyecto simple y no una reconstrucción total.
Comience con una prueba piloto en un recinto o SSID, mida el éxito de la autenticación y la latencia de revocación, y rompa la integración a propósito antes de que los usuarios dependan de ella. Escale solo cuando esos resultados sean rutinarios. Los resultados rutinarios son el reflejo de una buena autenticación en producción.
Purple ofrece RADIUS-as-a-Service para WiFi de invitados, personal y entornos multi-inquilino, integrándose con Entra ID, Google Workspace y Okta para que pueda retirar los servidores RADIUS locales y aplicar un acceso uniforme basado en identidades en todas sus instalaciones. Si está planeando un piloto o reemplazando una configuración frágil de NPS o FreeRADIUS, visite Purple para ver cómo funcionan el RADIUS administrado en la nube, Passpoint y el aislamiento por inquilino con su infraestructura existente de Meraki, Aruba, Ruckus, Mist o UniFi.
