Resolución de problemas de fallas de autenticación 802.1X (RADIUS/EAP)
Guía de diagnóstico paso a paso para resolver errores de autenticación 802.1X, EAP-TLS, PEAP y RADIUS en redes WiFi empresariales.
Video overview
Escucha esta guía
Ver transcripción del podcast
Parte de nuestra serie principal: Guía de seguridad de WiFi empresarial →
Resumen Ejecutivo
Para los líderes de TI que gestionan WiFi empresarial en hoteles, cadenas de retail, estadios y espacios del sector público, la autenticación 802.1X es la columna vertebral del control de acceso a la red - y cuando falla, el impacto es inmediato y operativamente grave. Un solo perfil de suplicante mal configurado, un certificado RADIUS caducado o un secreto compartido que no coincide pueden bloquear a cientos de usuarios simultáneamente, lo que desencadena escaladas de soporte, pérdida de ingresos y posibles infracciones de cumplimiento.
IEEE 802.1X define el control de acceso a la red basado en puertos, que opera en la Capa 2 del modelo OSI. Funciona en conjunto con el Protocolo de Autenticación Extensible (EAP) y un servidor RADIUS para autenticar cada dispositivo antes de otorgar acceso a la red. El protocolo admite múltiples métodos EAP - EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS y EAP-FAST - cada uno con perfiles de seguridad, requisitos de certificado y complejidad operativa distintos.
Esta guía proporciona un marco de diagnóstico estructurado para resolver fallas de 802.1X en la cadena de autenticación de tres componentes: el Suplicante (dispositivo final), el Autenticador (punto de acceso o switch) y el Servidor de Autenticación (RADIUS). Incluye casos de estudio del mundo real, un árbol de decisión de triaje rápido, mejores prácticas de implementación alineadas con los estándares PCI-DSS v4.0 y WPA3-Enterprise, y una biblioteca de ejemplos prácticos extraídos de implementaciones en hotelería y retail.
Para las organizaciones que implementan Guest WiFi junto con las redes del personal, comprender dónde se rompe 802.1X - y cómo solucionarlo rápidamente - es una prioridad operativa y comercial directa.
Inmersión Técnica Profunda
La Arquitectura de Autenticación 802.1X
El estándar IEEE 802.1X define un modelo de tres componentes que rige cada intercambio de autenticación WiFi empresarial. Comprender el papel de cada componente es el requisito previo para una resolución de problemas eficaz.
El Suplicante es el dispositivo del usuario final - una laptop, smartphone, tablet o terminal de punto de venta. Ejecuta un componente de software (el cliente suplicante, integrado en el sistema operativo en Windows, macOS, iOS y Android) que inicia el intercambio EAP y presenta las credenciales a la red. La configuración del suplicante - específicamente el método EAP, la configuración de confianza del certificado y la fuente de las credenciales - es una de las fuentes más comunes de fallas de autenticación.
El Autenticador es el punto de acceso inalámbrico o el switch administrado. Es fundamental destacar que el Autenticador no toma decisiones de autenticación. Actúa como un relevo sin estado, bloqueando todo el tráfico de datos en el puerto controlado hasta que el servidor RADIUS emite una decisión de autorización. Se comunica con el Suplicante utilizando tramas EAPOL (EAP sobre LAN) a través del medio inalámbrico o cableado, y con el servidor RADIUS utilizando paquetes RADIUS Access-Request y Access-Accept/Reject a través de los puertos UDP 1812 (autenticación) y 1813 (contabilidad).
El Servidor de Autenticación es el servidor RADIUS. Aquí es donde ocurre la validación real de las credenciales. El servidor RADIUS negocia el método EAP con el Suplicante, valida las credenciales contra un directorio de identidad (Active Directory, Azure AD, Okta o LDAP) y devuelve un Access-Accept con atributos opcionales de asignación de VLAN, o un Access-Reject con un código de motivo. En las implementaciones modernas, este es cada vez más un servicio alojado en la nube - consulte Cómo implementar la autenticación 802.1X con Cloud RADIUS para obtener una guía de implementación completa.
Comparación de métodos EAP
EAP no es un método de autenticación único, sino un marco de trabajo que admite múltiples métodos internos. La elección del método EAP tiene implicaciones directas en la postura de seguridad, los requisitos de la infraestructura de certificados y los tipos de fallas que es probable que encuentre.
| Método EAP | Requisito de certificado | Nivel de seguridad | Complejidad de implementación | Caso de uso principal |
|---|---|---|---|---|
| EAP-TLS | Mutuo (cliente + servidor) | El más alto | Alta (requiere PKI + MDM) | Dispositivos corporativos administrados |
| PEAP-MSCHAPv2 | Solo del lado del servidor | Medio | Medio | Entornos integrados con AD |
| EAP-TTLS | Solo del lado del servidor | Medio | Medio | Entornos BYOD con sistemas operativos mixtos |
| EAP-FAST | Ninguno (utiliza PAC) | Medio - Alto | Baja | Soporte para dispositivos heredados |
WPA3-Enterprise con EAP-TLS es la mejor práctica actual de la industria para flotas de dispositivos corporativos administrados. Para los establecimientos que implementan Guest WiFi y redes de personal en paralelo - algo común en entornos de Hospitality y Retail - lo típico es un enfoque híbrido: EAP-TLS para dispositivos corporativos y un Captive Portal con backend RADIUS para invitados.
El flujo de autenticación: paso a paso
Comprender la secuencia precisa del intercambio 802.1X es esencial para identificar con precisión dónde ocurre una falla. El flujo procede de la siguiente manera:
- El Suplicante se asocia con el SSID. El Autenticador abre un puerto controlado, bloqueando todo el tráfico que no sea EAP.
- El Autenticador envía un EAP-Request/Identity al Suplicante.
- El Suplicante responde con un EAP-Response/Identity (la identidad del usuario o dispositivo).
- El Autenticador encapsula esto en un RADIUS Access-Request y lo reenvía al servidor RADIUS.
- El servidor RADIUS emite un Access-Challenge, proponiendo el método EAP (por ejemplo, EAP-TLS o PEAP).
- El Suplicante y el servidor RADIUS negocian el método EAP e intercambian credenciales a través de múltiples viajes de ida y vuelta de Access-Request / Access-Challenge, retransmitidos por el Autenticador.
- El servidor RADIUS valida las credenciales contra el directorio de identidad y devuelve un Access-Accept (con atributos opcionales de asignación de VLAN) o un Access-Reject (con un código de motivo).
- Si se acepta, el Autenticador abre el puerto controlado y el dispositivo obtiene acceso a la red. Para WPA2/WPA3-Enterprise, se realiza un saludo de 4 vías (4-Way Handshake) para derivar las claves de cifrado de la sesión.
Un fallo en cualquier paso de esta secuencia produce un perfil de síntomas diferente. Mapear el síntoma con el paso es la base de un triaje rápido.
Modos de Fallo Comunes e Indicadores de Diagnóstico
Modo de Fallo 1: Vencimiento de Certificado (Servidor o Cliente)
Este es el modo de fallo individual más disruptivo en implementaciones de producción de 802.1X. Cuando el certificado TLS del servidor RADIUS expira, todos los clientes fallan la autenticación simultáneamente - una interrupción completa de la red. Cuando un certificado de cliente expira (en implementaciones de EAP-TLS), los dispositivos individuales fallan mientras que otros continúan autenticándose normalmente.
Indicadores de diagnóstico: Los registros de eventos de NPS/RADIUS muestran el Código de Motivo 22 ("El certificado del cliente ha expirado o aún no es válido") o el Código de Motivo 16 ("La autenticación falló debido a una discrepancia en las credenciales del usuario"). En Windows NPS, verifique el ID de evento 6273 en el registro de eventos de Seguridad. En FreeRADIUS, busque TLS Alert read:fatal:certificate expired en la salida de depuración.
Resolución: Renueve el certificado vencido y envíe el certificado de CA actualizado a todos los clientes a través de un MDM. Implemente un monitoreo automatizado de vencimiento de certificados con un umbral de alerta de 90 días.
Modo de Fallo 2: Discrepancia en el Secreto Compartido de RADIUS
El secreto compartido se utiliza para autenticar los mensajes RADIUS entre el Autenticador y el servidor RADIUS. Una discrepancia provoca que el servidor RADIUS descarte silenciosamente los paquetes Access-Request. Desde la perspectiva del AP, el servidor RADIUS parece no responder.
Indicadores de diagnóstico: Los registros del AP muestran tiempos de espera agotados y retransmisiones de RADIUS. El servidor RADIUS no muestra entradas de registro correspondientes para los intentos fallidos - las solicitudes se descartan antes de ser procesadas. Una captura de Wireshark en la interfaz del servidor RADIUS mostrará paquetes UDP entrantes en el puerto 1812 que se descartan silenciosamente.
Resolución: Verifique y sincronice el secreto compartido tanto en el Autenticador (configuración del AP/controlador) como en el servidor RADIUS (configuración del cliente NAS). Utilice un secreto seguro generado aleatoriamente de al menos 32 caracteres. Implemente RadSec (RADIUS sobre TLS) para eliminar la dependencia del secreto compartido en implementaciones de RADIUS en la nube.
Modo de Fallo 3: Desconfiguración del Perfil del Suplicante
En implementaciones PEAP-MSCHAPv2, los clientes deben estar configurados para validar el certificado del servidor RADIUS frente a una CA de confianza. Si se deshabilita la validación de certificados - un atajo común durante la implementación inicial - la red queda vulnerable a ataques de recopilación de credenciales mediante AP falsos. Si se confía en la CA incorrecta, o si el CN/SAN del certificado del servidor no coincide con el nombre de servidor configurado, la autenticación fallará.
Indicadores de diagnóstico: Los dispositivos individuales fallan mientras que otros tienen éxito. Los registros de RADIUS muestran fallas en el saludo EAP-TLS o fallas en el establecimiento del túnel PEAP. En Windows, el ID de evento WLAN-AutoConfig 8001 u 8002 en el registro operativo indica fallas del lado del suplicante.
Resolución: Implemente perfiles de WiFi estandarizados a través de MDM (Microsoft Intune, Jamf o equivalente). Asegúrese de que el certificado de la CA de confianza esté incluido en el perfil y que se exija la validación del certificado del servidor. Nunca deshabilite la validación de certificados en producción.
Modo de falla 4: Problemas de tránsito de red (fragmentación de MTU)
Los intercambios de EAP-TLS implican la transmisión de cadenas de certificados completas, lo que puede generar paquetes RADIUS de gran tamaño. Si la ruta WAN entre el autenticador y un servidor RADIUS en la nube tiene un MTU bajo (común en ciertas configuraciones MPLS o SD-WAN), estos paquetes pueden fragmentarse. Muchos firewalls y dispositivos de inspección de estado descartan los paquetes UDP fragmentados, lo que provoca que el saludo TLS se detenga de forma silenciosa.
Indicadores de diagnóstico: La autenticación EAP-TLS falla de forma intermitente o constante en los sitios conectados a través de WAN, mientras que los sitios con RADIUS local tienen éxito. Las capturas de paquetes muestran que los paquetes RADIUS Access-Request se fragmentan en la interfaz WAN. La autenticación tiene éxito cuando el servidor RADIUS está en la LAN local.
Resolución: Implemente RadSec (RADIUS sobre TLS en el puerto TCP 2083). TCP maneja la fragmentación y la retransmisión de forma nativa, eliminando por completo este modo de falla. Como alternativa, ajuste el MTU en la interfaz WAN o configure los parámetros de fragmentación de RADIUS en el servidor.
Modo de falla 5: Falla de conectividad del directorio de identidad
El servidor RADIUS debe poder comunicarse con el directorio de identidad (Active Directory, LDAP, Azure AD) para validar las credenciales. Una falla de DNS, un cambio en las reglas del firewall o una interrupción del controlador de dominio provocarán que todos los intentos de autenticación fallen, a pesar de que el servicio RADIUS en sí funcione correctamente.
Indicadores de diagnóstico: Los registros del servidor RADIUS muestran que se reciben intentos de autenticación pero fallan con "No se puede contactar con el servidor LDAP" o errores equivalentes. ID de evento NPS 6273 con código de motivo 16 o 66. Es posible que el propio monitoreo de estado del servidor RADIUS no detecte esto si la conectividad del directorio no se monitorea de forma explícita.
Resolución: Implemente un monitoreo de estado dedicado para la ruta de conexión de RADIUS al directorio. Configure múltiples controladores de dominio o réplicas de LDAP como destinos de respaldo. Para implementaciones de RADIUS en la nube, asegúrese de que la integración del proveedor de identidad (Azure AD Connect, proxy LDAP) esté incluida en su monitoreo de disponibilidad.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.
Guía de implementación
Fase 1: Validación previa a la implementación
Antes de implementar 802.1X a gran escala, valide los siguientes requisitos previos. Omitir esta fase es la causa principal de fallas posteriores a la implementación.
Primero, confirme que el certificado de su servidor RADIUS sea emitido por una CA en la que confíen todas las plataformas de dispositivos clientes de su parque informático. En Windows, esto significa que la CA debe estar en el almacén de Entidades de certificación raíz de confianza. En iOS y Android, el certificado de la CA debe distribuirse explícitamente a través de perfiles MDM. No utilice certificados autofirmados en producción.
Segundo, verifique la conectividad de red entre todos los autenticadores (APs y switches) y el servidor RADIUS en los puertos UDP 1812 y 1813. Utilice un cliente de prueba RADIUS (como radtest en Linux o la herramienta de prueba NPS en Windows) para confirmar la autenticación de extremo a extremo antes de realizar la implementación en los SSIDs de producción.
Tercero, valide la integración de su directorio de identidad. Confirme que el servidor RADIUS puede realizar vinculaciones LDAP y consultas de membresía de grupo en su directorio. Realice pruebas con una cuenta de servicio y verifique que se devuelvan los atributos de asignación de VLAN esperados en la respuesta Access-Accept.
Fase 2: Selección del método EAP y estrategia de certificados
Para dispositivos corporativos administrados, implemente EAP-TLS con certificados de cliente distribuidos a través de MDM. Esto elimina el riesgo de robo de credenciales y proporciona la postura de autenticación más sólida. Asegúrese de que su plataforma MDM esté configurada para renovar automáticamente los certificados de los clientes antes de que expiren.
Para entornos con dispositivos no administrados o BYOD, PEAP-MSCHAPv2 es la opción más pragmática. Exija la validación del certificado del servidor en todos los perfiles de cliente. Nunca distribuya perfiles de WiFi con la validación de certificados desactivada.
Para dispositivos heredados (sensores IoT, terminales POS antiguos) que no pueden ejecutar un suplicante 802.1X, implemente la derivación de autenticación MAC (MAB) como alternativa. Asigne los dispositivos MAB a una VLAN altamente restringida con reglas de firewall explícitas que limiten su acceso a la red únicamente a los servicios que requieren.
Fase 3: Implementación y monitoreo
Implemente con un enfoque por fases: realice una prueba piloto con un grupo controlado de 20 a 50 dispositivos, valide los registros de autenticación, confirme la asignación de VLAN y verifique los registros de contabilidad (accounting) antes de expandir la implementación a todo el parque informático. Para implementaciones en grandes recintos - estadios, centros de conferencias, hoteles - este enfoque por fases es esencial para contener el radio de impacto de cualquier error de configuración.
Implemente un monitoreo continuo de: el vencimiento del certificado del servidor RADIUS (alerta a los 90 días), la disponibilidad y el tiempo de respuesta del servidor RADIUS, las tasas de éxito y falla de autenticación por SSID y sitio, y la conectividad del directorio de identidad. Para entornos de Salud y Retail sujetos a auditorías regulatorias, asegúrese de que los registros de contabilidad de RADIUS se conserven durante el período requerido (normalmente 12 meses bajo PCI-DSS).
Para implementaciones en Transport y grandes recintos públicos, considere implementar servidores RADIUS redundantes con conmutación por error automática. Un único servidor RADIUS es un punto único de falla para toda la infraestructura de control de acceso a la red.
Mejores Prácticas
Las siguientes mejores prácticas se basan en las especificaciones IEEE 802.1X, WPA3-Enterprise, los requisitos de PCI-DSS v4.0 y la experiencia operativa en implementaciones de redes para recintos corporativos.
Gestión del ciclo de vida de los certificados es el control operativo de mayor prioridad. Implemente un monitoreo automatizado con alertas a los 90, 60 y 30 días antes del vencimiento para todos los certificados de servidor RADIUS. Para implementaciones EAP-TLS, extienda este monitoreo a los certificados de los clientes a través de su plataforma de MDM. El vencimiento de los certificados es la causa principal de las interrupciones masivas de autenticación en implementaciones de producción 802.1X.
La implementación de RadSec debe ser la opción predeterminada para cualquier implementación 802.1X donde el tráfico RADIUS atraviese la red pública de internet o una WAN. RadSec (RFC 6614) encapsula RADIUS en TLS sobre TCP, lo que proporciona seguridad de transporte, elimina los problemas de fragmentación UDP y suprime la dependencia de secretos compartidos. La mayoría de las plataformas de nube RADIUS modernas y los proveedores de AP empresariales son compatibles con RadSec.
Los perfiles de cliente aplicados por MDM eliminan la mayor fuente de configuración errónea de los suplicantes. Todos los dispositivos propiedad de la empresa deben recibir sus perfiles de WiFi a través de MDM, no mediante configuración manual. Los perfiles deben incluir el certificado CA de confianza, aplicar la validación del certificado del servidor y especificar el método EAP correcto junto con la configuración de autenticación interna.
La segmentación de red mediante asignación dinámica de VLAN es un control obligatorio para el cumplimiento de PCI-DSS y una pieza fundamental de la arquitectura de red Zero Trust. Configure las políticas de autorización de RADIUS para asignar a los usuarios a la VLAN adecuada según su pertenencia a un grupo - el personal a la VLAN corporativa, los invitados a una VLAN aislada solo para internet, y los dispositivos IoT a una VLAN de gestión restringida. Esto limita el radio de impacto de cualquier dispositivo comprometido.
La retención de registros de contabilidad de RADIUS proporciona la pista de auditoría requerida por el Requisito 10 de PCI-DSS y es esencial para la investigación forense tras un incidente de seguridad. Asegúrese de que los registros de contabilidad capturen los eventos de inicio y finalización de sesión, la identidad del usuario, la dirección MAC del dispositivo, la VLAN asignada, la duración de la sesión y el volumen de datos. Integre la contabilidad de RADIUS con su SIEM para la detección de anomalías en tiempo real.
Para las organizaciones que implementan WiFi Analytics junto con 802.1X, la combinación de datos de autenticación por usuario y analíticas proporciona una potente capa de inteligencia operativa - lo que permite el análisis del tiempo de permanencia, la planificación de capacidad y la detección de anomalías a nivel de sesión individual.
Solución de problemas y mitigación de riesgos
Marco de triaje rápido
Cuando se reporta una falla de autenticación 802.1X, la primera pregunta de diagnóstico determina toda la ruta de solución de problemas: ¿Esto afecta a un solo usuario o dispositivo, o a todos los usuarios de la red?
Si la falla afecta a todos los usuarios simultáneamente, la causa raíz es casi seguro a nivel de infraestructura: un certificado de servidor RADIUS vencido, una interrupción del servidor RADIUS, una discrepancia de secreto compartido después de un cambio de configuración o una falla de conectividad entre el Authenticator y el servidor RADIUS. Comience por verificar la disponibilidad del servidor RADIUS y la validez del certificado.
Si la falla afecta a un solo usuario o dispositivo, la causa raíz es casi seguro a nivel de cliente: un certificado de cliente vencido (EAP-TLS), una configuración incorrecta del perfil del supplicant, credenciales incorrectas o un problema de software específico del dispositivo. Comience por verificar el almacén de certificados del cliente y la configuración del supplicant.
Herramientas de diagnóstico
Las siguientes herramientas son esenciales para la solución de problemas de 802.1X en diferentes componentes de la infraestructura.
| Herramienta | Plataforma | Caso de uso |
|---|---|---|
| NPS Event Log (Event IDs 6272/6273) | Windows Server | Éxito o falla de autenticación RADIUS con códigos de motivo |
| WLAN-AutoConfig Operational Log | Windows Client | Fallas de intercambio EAP en el lado del supplicant |
| CAPI2 Event Log | Windows Client | Fallas de validación de certificados |
debug radius authentication |
Cisco IOS/WLC | Depuración del intercambio RADIUS en el Authenticator |
radiusd -X |
FreeRADIUS | Salida de depuración completa que incluye la negociación EAP |
| Wireshark (filtro EAPOL) | Cualquiera | Captura de paquetes en el lado del cliente de tramas EAP |
| Wireshark (filtro EAP) | Cualquiera | Captura de paquetes RADIUS en el lado del servidor |
radtest |
Linux | Prueba manual de autenticación RADIUS |
Referencia de códigos de motivo de NPS
El ID de evento 6273 de Microsoft NPS (falla de autenticación) incluye un código de motivo que identifica directamente la causa de la falla. Los códigos más significativos desde el punto de vista operativo son:
| Código de motivo | Descripción | Causa raíz probable |
|---|---|---|
| 16 | La autenticación falló debido a una discrepancia en las credenciales del usuario | Contraseña incorrecta, certificado de cliente vencido o falla en la búsqueda de directorio |
| 22 | El certificado de cliente ha vencido o aún no es válido | Vencimiento del certificado de cliente - verificar la renovación del certificado MDM |
| 23 | La cuenta de usuario venció | Vencimiento de la cuenta de AD - verificar el estado de la cuenta |
| 48 | La solicitud de conexión no coincidió con ninguna política configurada | Configuración incorrecta de la política RADIUS - verificar las políticas de red de NPS |
| 66 | El usuario intentó utilizar un método de autenticación no habilitado en la política de red coincidente | Discrepancia del método EAP entre el cliente y el servidor |
Mitigación de riesgos: El desastre del vencimiento de certificados
La interrupción más común y prevenible de 802.1X es el vencimiento del certificado del servidor RADIUS. En enero de 2025, una importante cadena minorista experimentó una interrupción completa de la red del personal cuando el certificado de su servidor RADIUS venció a las 3:00 AM de un lunes por la mañana. Para las 9:00 AM, más de 300 terminales de punto de venta en 45 tiendas habían perdido la conectividad de red. El certificado se había implementado dos años antes sin monitoreo automatizado, y el recordatorio de renovación se había omitido durante una reestructuración del equipo.
La mitigación es sencilla: implemente un monitoreo automatizado de vencimiento de certificados integrado con su plataforma de alertas (PagerDuty, OpsGenie o equivalente). Establezca umbrales de alerta a los 90, 60 y 30 días. Asigne la renovación del certificado como una responsabilidad específica en su manual de procedimientos de operaciones de TI. Para plataformas RADIUS en la nube, verifique si el proveedor gestiona la renovación del certificado en su nombre - este es un diferenciador clave entre las ofertas gestionadas y las de autoservicio.
ROI e impacto empresarial
El costo del tiempo de inactividad de autenticación
Para los operadores de recintos, las fallas de autenticación de 802.1X se traducen directamente en un impacto empresarial medible. En entornos de Hospitality, una interrupción en la red del personal afecta los sistemas de gestión de propiedades, las terminales de punto de venta y la prestación de servicios a los huéspedes. En el sector Retail, las fallas de autenticación en las terminales de punto de venta detienen por completo las transacciones. En centros de conferencias y estadios, las fallas de autenticación durante eventos de alta afluencia generan fallas de servicio inmediatas y visibles.
El costo operativo de una interrupción de autenticación de 30 minutos en un hotel de 200 habitaciones - que afecte el acceso al PMS, el punto de venta del restaurante y las terminales de conserjería - generalmente supera las £5,000 en disrupción operativa directa, sin contar el impacto en la experiencia del huésped y las posibles penalizaciones por incumplimiento de SLA.
Valor de cumplimiento
Para las organizaciones dentro del alcance de PCI-DSS v4.0, una infraestructura 802.1X correctamente implementada cumple directamente con múltiples requisitos: Requisito 1 (controles de acceso a la red), Requisito 7 (restringir el acceso a los componentes del sistema), Requisito 8 (identificar usuarios y autenticar el acceso) y Requisito 10 (registrar y monitorear todo el acceso). La alternativa - redes PSK compartidas - no cumple con ninguno de los cuatro requisitos y genera una responsabilidad de auditoría significativa.
Para las organizaciones del sector público y las implementaciones de Healthcare sujetas a regulaciones de protección de datos, la autenticación por usuario y los registros de actividad detallados proporcionan el historial de auditoría necesario para demostrar el cumplimiento de las obligaciones de control de acceso.
Medición del éxito
Los indicadores clave de rendimiento para una implementación de 802.1X con buen funcionamiento son: tasa de éxito de autenticación (objetivo >99.5%), tiempo medio de autenticación (<150 ms para RADIUS en la nube), incidentes por vencimiento de certificados (objetivo cero) y disponibilidad del servidor RADIUS (objetivo 99.9%). Estas métricas deben rastrearse en su plataforma de gestión de red y revisarse mensualmente como parte del ritmo de sus operaciones de red. Para las organizaciones que utilizan WiFi Analytics, la combinación de datos de sesión por usuario de 802.1X con la analítica proporciona inteligencia empresarial adicional: medición precisa del tiempo de permanencia, distribución de tipos de dispositivos y patrones de utilización de la red que fundamentan la planificación de la capacidad y las decisiones de operaciones del recinto.
Para profundizar en la lectura sobre soluciones de control de acceso a la red relacionadas, consulte 10 Best Network Access Control (NAC) Solutions for 2026 y Cisco Wireless APs: 2026 Guide to Products & Deployment. Para implementaciones en escuelas y educación, WiFi in Schools: The 2026 Administrator & IT Guide cubre la implementación de 802.1X en entornos educativos multiusuario.
Definiciones clave
802.1X
IEEE 802.1X es un estándar de control de acceso a redes basado en puertos que define un marco de autenticación que opera en la Capa 2 del modelo OSI. Bloquea todo el tráfico de red de un dispositivo hasta que el servidor RADIUS lo haya autenticado positivamente, utilizando EAP como protocolo de intercambio de credenciales. Se aplica tanto a redes Ethernet cableadas como a redes inalámbricas (WiFi).
Los equipos de TI encuentran 802.1X como el mecanismo de autenticación para los SSID WPA2-Enterprise y WPA3-Enterprise. Es el estándar que permite la autenticación por usuario, la asignación dinámica de VLAN y el registro de auditoría requerido para el cumplimiento de PCI-DSS.
RADIUS (Servicio de autenticación remota de usuarios de marcación telefónica)
Un protocolo de red cliente - servidor (RFC 2865) que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para el acceso a la red. En las implementaciones de 802.1X, el servidor RADIUS valida las credenciales de usuario comparándolas con un directorio de identidades y devuelve respuestas de Access-Accept o Access-Reject al autenticador. Funciona a través de los puertos UDP 1812 (autenticación) y 1813 (contabilidad).
El servidor RADIUS es el componente que toma las decisiones en 802.1X. Cuando falla la autenticación, los logs del servidor RADIUS contienen el código de motivo que identifica la causa raíz. Las implementaciones comunes incluyen Microsoft NPS, FreeRADIUS y servicios alojados en la nube.
EAP (Protocolo de Autenticación Extensible)
Un marco de protocolo (RFC 3748) que define un conjunto de métodos de autenticación utilizados dentro de 802.1X. EAP en sí no es un método de autenticación sino un contenedor que admite múltiples métodos internos, incluidos EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS y EAP-FAST. El método EAP se negocia entre el suplicante y el servidor RADIUS; el autenticador retransmite las tramas EAP sin interpretarlas.
La selección del método EAP determina la postura de seguridad y la complejidad operativa del despliegue. EAP-TLS requiere una infraestructura de PKI y MDM, pero proporciona la seguridad más sólida. PEAP-MSCHAPv2 es más sencillo de implementar pero requiere una validación estricta de certificados para evitar el robo de credenciales.
Suplicante
El componente de software en el dispositivo del usuario final (laptop, smartphone, terminal de punto de venta) que inicia el intercambio de autenticación 802.1X. En Windows, el suplicante está integrado en el sistema operativo como el servicio de configuración automática de WLAN o de configuración automática cableada. En iOS y Android, se gestiona a través de la configuración del perfil de WiFi del dispositivo.
La configuración incorrecta del suplicante (particularmente la validación de certificados desactivada en implementaciones PEAP) es una de las fuentes más comunes tanto de fallas de autenticación como de vulnerabilidades de seguridad. Estandarizar la configuración del suplicante a través de un MDM es un control operativo crítico.
Autenticador
El dispositivo de red (punto de acceso inalámbrico o switch administrado) que aplica el control de acceso basado en puertos en una implementación de 802.1X. El autenticador no toma decisiones de autenticación; actúa como un intermediario entre el suplicante (utilizando EAPOL) y el servidor RADIUS (utilizando RADIUS). Bloquea todo el tráfico que no sea EAP en el puerto controlado hasta que el servidor RADIUS emita un Access-Accept.
La configuración del autenticador (específicamente la dirección IP o el nombre de host del servidor RADIUS, el secreto compartido y la configuración de tiempo de espera) es una fuente común de fallas. Después de realizar cambios en la infraestructura, siempre verifique que la configuración del cliente RADIUS del autenticador coincida con la configuración del cliente NAS del servidor RADIUS.
EAPOL (EAP sobre LAN)
El protocolo utilizado para transportar tramas EAP entre el suplicante y el autenticador a través del medio cableado o inalámbrico. Las tramas EAPOL son tramas de Capa 2 (tipo Ethernet 0x888E) y no requieren conectividad IP. El autenticador encapsula las tramas EAPOL en paquetes RADIUS para su reenvío al servidor de autenticación.
EAPOL es visible en las capturas de Wireshark en el lado del cliente. Filtrar por tramas EAPOL en una captura de paquetes inalámbricos permite a los ingenieros observar el intercambio EAP e identificar en qué paso falla la autenticación.
RadSec (RADIUS sobre TLS)
Una extensión del protocolo RADIUS (RFC 6614) que encapsula paquetes RADIUS en un túnel TLS a través del puerto TCP 2083. RadSec proporciona seguridad de transporte para el tráfico RADIUS que atraviesa redes no confiables (como el internet público hacia un servidor RADIUS en la nube), elimina los problemas de fragmentación UDP y suprime la dependencia de secretos compartidos para la autenticación de paquetes.
RadSec es el transporte recomendado para implementaciones de RADIUS en la nube. Resuelve simultáneamente dos modos de falla comunes: la fragmentación de MTU que provoca fallas en el saludo de EAP-TLS y la complejidad de la gestión de secretos compartidos en sitios distribuidos.
Asignación Dinámica de VLAN
Una función de autorización de RADIUS que permite al servidor RADIUS indicar al autenticador que ubique un dispositivo autenticado en una VLAN específica, según la pertenencia al grupo del usuario o el tipo de dispositivo. El servidor RADIUS devuelve los atributos de asignación de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) en la respuesta Access-Accept.
La asignación dinámica de VLAN es el mecanismo que impone la segmentación de red en despliegues 802.1X. Es un control obligatorio para el cumplimiento de PCI-DSS (aislando el Entorno de Datos de Tarjetas de Pago) y una piedra angular de la arquitectura de red Zero Trust. Los atributos de VLAN mal configurados en las políticas de RADIUS son una causa común de que los usuarios sean ubicados en el segmento de red incorrecto después de la autenticación.
Bypass de Autenticación MAC (MAB)
Un mecanismo de autenticación de respaldo que permite a los dispositivos sin suplicantes 802.1X autenticarse utilizando su dirección MAC como usuario y contraseña en un intercambio RADIUS. Debido a que las direcciones MAC se pueden suplantar, MAB proporciona una garantía de seguridad mínima y solo debe usarse para dispositivos que genuinamente no puedan admitir 802.1X.
MAB se requiere comúnmente para dispositivos IoT heredados, terminales POS más antiguos e impresoras de red. Los dispositivos autenticados a través de MAB deben ubicarse en una VLAN muy restringida con reglas de firewall explícitas. Nunca use MAB como un atajo de conveniencia para dispositivos que podrían admitir 802.1X.
NPS (Network Policy Server)
La implementación de Microsoft de un servidor RADIUS, incluida con Windows Server. NPS admite PEAP-MSCHAPv2, EAP-TLS y EAP-TTLS, y se integra de forma nativa con Active Directory para la validación de credenciales. Las fallas de autenticación se registran en el registro de eventos de seguridad de Windows como Event ID 6273 (falla) y 6272 (éxito), con códigos de motivo que identifican la causa específica de la falla.
NPS es el servidor RADIUS más ampliamente desplegado en entornos empresariales centrados en Windows. El registro de eventos de seguridad en el servidor NPS es la principal herramienta de diagnóstico para fallas de 802.1X en estos entornos. Asegúrese de que la política de auditoría de NPS esté habilitada tanto para eventos de éxito como de falla.
Ejemplos resueltos
Un grupo hotelero de 450 habitaciones con 12 propiedades ha implementado WPA2-Enterprise con PEAP-MSCHAPv2 en todos los sitios, utilizando un servidor Windows NPS local en cada ubicación. Después de una actualización de la infraestructura de red, el equipo de TI informa que el personal de tres sitios no puede autenticarse en el SSID corporativo. Los huéspedes en la red del Captive Portal no se ven afectados. Los servidores NPS en los sitios afectados están funcionando y el registro de eventos de seguridad de Windows muestra el ID de evento 6273 con el código de motivo 16. ¿Cuál es la causa más probable y cómo debería resolverla el equipo?
El código de motivo 16 en el ID de evento 6273 de NPS indica una falla de autenticación debido a una discrepancia de credenciales - pero en el contexto de una interrupción posterior a una actualización de infraestructura que afecta a múltiples sitios simultáneamente, la causa más probable no son contraseñas de usuario incorrectas, sino una discrepancia en el secreto compartido de RADIUS entre los puntos de acceso o el controlador inalámbrico recientemente configurados y los servidores NPS.
Paso 1: En el servidor NPS de uno de los sitios afectados, navegue a Clientes y servidores RADIUS > Clientes RADIUS y verifique el secreto compartido configurado para cada dirección IP de AP o controlador inalámbrico. Compare esto con la configuración del servidor RADIUS en el AP o controlador.
Paso 2: Si los secretos compartidos coinciden, verifique si la política de red de NPS está configurada correctamente para permitir PEAP-MSCHAPv2. Navegue a Políticas > Políticas de red, abra la política correspondiente y verifique que Microsoft: PEAP protegido (PEAP) aparezca como un método de autenticación permitido con EAP-MSCHAPv2 como el método interno.
Paso 3: Si la política es correcta, verifique la política de solicitud de conexión de NPS para confirmar que la solicitud se está procesando localmente (no reenviada a un servidor RADIUS remoto). Verifique que las condiciones coincidan con los atributos RADIUS entrantes del nuevo hardware de AP.
Paso 4: Habilite la depuración de contabilidad de RADIUS en el AP o controlador y verifique que los paquetes de solicitud de acceso (Access-Request) se estén enviando a la IP del servidor NPS y al puerto 1812 correctos. Si no llegan solicitudes al servidor NPS, el problema está en la configuración del autenticador, no en el servidor RADIUS.
Paso 5: Si las solicitudes llegan a NPS pero son rechazadas con el código de motivo 16, y se confirma que las credenciales son correctas, verifique si el controlador de dominio de Active Directory es accesible desde el servidor NPS. Un problema de DNS o de conectividad con el DC hará que NPS falle en la validación de credenciales con este código de motivo.
Resolución: En la mayoría de los escenarios posteriores a una actualización, la causa principal es una discrepancia de secreto compartido introducida al configurar el nuevo hardware de AP. Sincronice el secreto compartido en todos los clientes RADIUS y servidores NPS. Considere migrar a RadSec para eliminar por completo la gestión de secretos compartidos.
Una importante cadena minorista que opera 85 tiendas ha implementado EAP-TLS con certificados de cliente gestionados a través de Microsoft Intune. Un lunes por la mañana, la mesa de ayuda de TI recibe una oleada de reportes de los gerentes de las tiendas que indican que los dispositivos del personal no pueden conectarse a la red WiFi corporativa. El problema afecta a todas las tiendas simultáneamente. Los registros del servidor RADIUS muestran respuestas Access-Reject con el mensaje 'TLS Alert: certificate expired'. El propio servidor RADIUS funciona con normalidad y su propio certificado es válido por otros 18 meses. ¿Qué ha sucedido y cuál es la ruta de solución inmediata?
El mensaje 'TLS Alert: certificate expired' en los registros del servidor RADIUS, combinado con el hecho de que la falla es simultánea en las 85 tiendas y que el certificado del servidor RADIUS es válido, indica que los certificados de cliente implementados en los dispositivos del personal han expirado. En EAP-TLS, tanto el cliente como el servidor presentan certificados. Si el certificado del cliente ha expirado, el servidor RADIUS rechazará el saludo TLS y emitirá un Access-Reject.
Solución inmediata (0 a 2 horas):
Paso 1: Confirme el diagnóstico verificando la fecha de vencimiento del certificado en un dispositivo afectado. En Windows, abra certmgr.msc, navegue a Personal > Certificados y verifique la fecha de vencimiento del certificado de autenticación de WiFi. Si ha expirado, esto confirma la causa raíz.
Paso 2: En Microsoft Intune, navegue a Dispositivos > Perfiles de configuración y localice el perfil de certificado SCEP o PKCS utilizado para la autenticación de WiFi. Verifique el periodo de validez del certificado y los ajustes del umbral de renovación.
Paso 3: Si el perfil de certificado está configurado para renovarse automáticamente, verifique si los dispositivos han podido comunicarse con el servicio de gestión de Intune recientemente. Si los dispositivos estaban fuera de línea o sin registrar, es posible que la renovación automática no se haya realizado.
Paso 4: Fuerce la renovación del certificado activando una sincronización del dispositivo en Intune (Dispositivos > Todos los dispositivos > Sincronizar). Para los dispositivos que no pueden conectarse a WiFi, asegúrese de que tengan una ruta de conectividad alternativa (datos móviles o Ethernet cableada) para comunicarse con el servicio de Intune para la renovación.
Paso 5: Como medida temporal mientras se renuevan los certificados, considere crear un SSID temporal con PEAP-MSCHAPv2 para las tiendas afectadas para restablecer la capacidad operativa. Esto debe tratarse como un puente temporal y no como una solución permanente.
Prevención a largo plazo:
Configure los perfiles de certificado de Intune para que se renueven cuando quede el 20% de la vida útil del certificado (por ejemplo, para un certificado de 1 año, renovar aproximadamente 73 días antes de su vencimiento). Implemente alertas de SIEM para eventos Access-Reject de RADIUS con códigos de motivo de vencimiento de certificado. Añada el monitoreo de vencimiento de certificados a su revisión mensual de operaciones de TI.
Preguntas de práctica
Q1. ¿Su organización opera un estadio de 60,000 asientos con 800 puntos de acceso desplegados en vestíbulos, suites de hospitalidad y áreas internas. Los dispositivos del personal utilizan EAP-TLS con certificados administrados a través de Jamf. Durante un evento importante, el 15% de los dispositivos del personal en múltiples zonas reportan fallas de autenticación. Los registros del servidor RADIUS muestran respuestas Access-Reject. El 85% restante del personal se está autenticando normalmente. ¿Cuál es su enfoque de diagnóstico y cuál es la causa raíz más probable?
Sugerencia: El patrón de falla parcial (15% de los dispositivos, no todos) es la señal de diagnóstico clave. Enfoquese en lo que distingue a los dispositivos con fallas de los que tienen éxito: modelo de dispositivo, versión de OS, fecha de emisión del certificado o estado de inscripción en Jamf.
Ver respuesta modelo
El patrón de falla parcial descarta de inmediato causas a nivel de infraestructura (la expiración del certificado del servidor RADIUS, un error de coincidencia en el secreto compartido o una interrupción del servidor afectarían a todos los dispositivos). La causa raíz es casi con seguridad un subconjunto de certificados de cliente que han expirado o no se pudieron renovar.
Enfoque de diagnóstico: Extraiga los registros del servidor RADIUS y filtre por eventos Access-Reject. Tome nota de las identidades de los dispositivos (CN de certificados o direcciones MAC) de los equipos que fallan. En Jamf, realice una referencia cruzada de estos dispositivos con el estado de implementación del perfil de certificado. Verifique si los dispositivos con fallas comparten una fecha común de emisión de certificados; si todos se inscribieron en el mismo lote, es posible que tengan la misma fecha de expiración.
Causa raíz más probable: Un lote de certificados de cliente emitidos al mismo tiempo ha llegado a su fecha de expiración. Los dispositivos inscritos más recientemente tienen certificados válidos y se están autenticando normalmente.
Resolución: En Jamf, identifique los dispositivos afectados y active un push de renovación de certificados. Asegúrese de que el perfil de certificado esté configurado con un umbral de renovación adecuado (20% de la vida útil del certificado). Para los dispositivos que no pueden conectarse al servicio MDM de Jamf a través de WiFi (porque no pueden autenticarse), proporcione una conexión Ethernet por cable temporal o un SSID de PEAP temporal durante la duración del evento. Después del evento, implemente alertas de SIEM en eventos RADIUS Access-Reject con códigos de motivo de expiración de certificados para evitar que vuelva a ocurrir.
Q2. Una cadena minorista regional con 35 tiendas está migrando de servidores NPS locales a un servicio RADIUS en la nube. Durante el piloto en tres tiendas, la autenticación EAP-TLS funciona correctamente en dos tiendas, pero falla de manera intermitente en la tercera. La tercera tienda se conecta al servicio RADIUS en la nube a través de un enlace WAN MPLS. Las fallas de autenticación no son consistentes: algunos intentos tienen éxito y otros fallan. El proveedor de RADIUS en la nube confirma que el servicio está en buen estado y los registros muestran que llegan algunos paquetes Access-Request, pero no se envía ningún Access-Accept correspondiente. ¿Cuál es la causa más probable?
Sugerencia: Las fallas intermitentes en un sitio específico conectado a la WAN, combinadas con el hecho de que el proveedor de RADIUS en la nube ve algunos paquetes pero no todos, sugieren fuertemente un problema de tránsito de red en lugar de un error de configuración.
Ver respuesta modelo
La combinación de fallas intermitentes en un sitio conectado a la WAN y el hecho de que el proveedor de RADIUS en la nube vea secuencias de paquetes incompletas es una firma clásica de fragmentación de MTU. Las cadenas de certificados EAP-TLS producen paquetes RADIUS grandes que pueden exceder la MTU del enlace WAN MPLS. Cuando estos paquetes se fragmentan, el servidor RADIUS en la nube puede recibir el primer fragmento pero no los fragmentos posteriores, lo que hace que el handshake TLS se detenga y finalmente expire por tiempo límite.
Confirmación de diagnóstico: Realice una captura de Wireshark en la interfaz WAN de la tienda afectada. Filtre por tráfico UDP en el puerto 1812. Busque paquetes IP fragmentados en el intercambio RADIUS. Compare el tamaño de los paquetes en las tiendas exitosas frente a la tienda con fallas.
Opción de resolución 1 (preferida): Migre el sitio afectado a RadSec (RADIUS sobre TLS en el puerto TCP 2083). TCP maneja la fragmentación y la retransmisión de forma nativa, eliminando por completo este modo de falla. La mayoría de los proveedores de RADIUS en la nube y proveedores modernos de AP son compatibles con RadSec.
Opción de resolución 2: Reduzca la MTU en la interfaz WAN de la tienda afectada para que coincida con la MTU de la ruta MPLS, garantizando que los paquetes RADIUS no se fragmenten. Esta es una solución menos elegante ya que afecta a todo el tráfico en el enlace WAN.
Opción de resolución 3: Configure el servidor RADIUS para que utilice tamaños de registro TLS más pequeños para reducir la fragmentación de paquetes. Esta es una opción de configuración del lado del servidor disponible en algunas implementaciones de RADIUS.
Recomendación a largo plazo: Migre todos los sitios a RadSec como parte del despliegue de RADIUS en la nube. Esto elimina el riesgo de fragmentación, cifra el tráfico RADIUS en tránsito y elimina la complejidad de la gestión de secretos compartidos.
Q3. El director de TI de un centro de conferencias está planeando una actualización de red para soportar WPA3-Enterprise con 802.1X para el personal y un Captive Portal para los delegados de eventos. El lugar alberga más de 200 eventos al año, con un número de delegados que varía entre 50 y 5,000. El equipo de TI tiene experiencia interna en redes limitada y no cuenta con una infraestructura PKI existente. El director desea implementar 802.1X para el personal, pero le preocupa la complejidad operativa. ¿Qué método EAP debería recomendarse, qué infraestructura se requiere y cuáles son los riesgos operativos clave que se deben mitigar?
Sugerencia: Considere las limitaciones operativas: experiencia interna limitada, ausencia de una PKI existente y la necesidad de una solución que se pueda mantener de manera confiable. Equilibre los requisitos de seguridad con la viabilidad operativa.
Ver respuesta modelo
Dadas las limitaciones operativas - experiencia interna limitada y sin PKI existente - el método EAP recomendado para la autenticación del personal es PEAP-MSCHAPv2, no EAP-TLS. Aunque EAP-TLS ofrece una seguridad superior, requiere una infraestructura PKI y una plataforma MDM para la distribución de certificados. Sin estos elementos instalados, el despliegue de EAP-TLS conlleva un riesgo operativo significativo: la gestión del vencimiento de los certificados se convierte en un proceso manual y el equipo carece de la experiencia para solucionar problemas de la cadena de certificados bajo presión.
PEAP-MSCHAPv2 se integra directamente con Active Directory (o Azure AD), requiere únicamente un certificado en el lado del servidor y es manejable operativamente por un equipo sin una profunda experiencia en PKI. El compromiso de seguridad es aceptable siempre que se exija estrictamente la validación del certificado del servidor en todos los dispositivos cliente; este es el control no negociable que evita la recolección de credenciales mediante puntos de acceso falsos.
Infraestructura requerida: Un servicio RADIUS en la nube (para evitar la gestión de servidores locales), un certificado de servidor de una CA pública de confianza para el servicio RADIUS, una solución MDM (Microsoft Intune o equivalente) para desplegar perfiles de WiFi en los dispositivos del personal, y Active Directory o Azure AD como directorio de identidades.
Riesgos operativos clave a mitigar:
Validación de certificado desactivada en los clientes: Despliegue todos los perfiles de WiFi a través de MDM aplicando la validación de certificados. Nunca permita la configuración manual de perfiles de WiFi en los dispositivos del personal.
Vencimiento del certificado del servidor RADIUS: Configure un monitoreo automatizado con alertas a los 90 días. Con un servicio RADIUS en la nube, verifique si el proveedor gestiona la renovación del certificado; este es un criterio de selección clave.
Capacidad durante eventos masivos: Asegúrese de que el servicio RADIUS en la nube esté dimensionado para la carga máxima de autenticación simultánea. Durante un evento de 5,000 delegados, si los dispositivos del personal se vuelven a autenticar de forma simultánea (por ejemplo, tras un reinicio de red), el servicio RADIUS debe ser capaz de soportar el pico de tráfico.
Separación de redes de invitados y del personal: Asegúrese de que la red de invitados del Captive Portal y la red del personal con 802.1X estén en VLAN distintas con las reglas de firewall adecuadas entre ellas. Este es un requisito de PCI-DSS si algún dispositivo de la red del personal procesa datos de tarjetas de pago.
Continúe leyendo esta serie
Cómo revocar el acceso a WiFi cuando un empleado se va
Esta guía muestra a los equipos de TI y de operaciones de recintos cómo eliminar el acceso de un empleado a la WiFi del personal cuando este se retira, sin interrumpir al resto de los trabajadores. Compara la desvinculación basada en certificados 802.1X, iPSK de identidad específica y aprovisionamiento controlado por SCIM, para luego ofrecer un manual de procedimientos para el mismo día, un método de prueba y un modelo de evidencia de auditoría.
Planeación de un despliegue de WiFi 7 en un entorno clínico: dispositivos IoMT, interferencia y HIPAA
Esta guía exhaustiva explora la planeación de un despliegue de WiFi 7 en un entorno clínico, enfocándose en la estrategia de la banda de 6 GHz, la compatibilidad con dispositivos IoMT heredados, las obligaciones de interferencia de RF según la norma IEC 60601-1-2 y la segmentación de red alineada con HIPAA. Proporciona asesoramiento de arquitectura accionable para que los líderes de TI en salud protejan flotas mixtas de dispositivos utilizando la plataforma RADIUS-as-a-Service en la nube de Purple.
Cómo segmentar de forma segura las redes WiFi del personal y de invitados: mejores prácticas para LAN empresariales
Esta guía proporciona a los administradores de TI y arquitectos de red un modelo técnico e independiente de proveedores para proteger las LAN empresariales mediante la segmentación adecuada del tráfico de WiFi del personal y de invitados. Abarca la autenticación 802.1X, RADIUS en la nube, el aislamiento de VLAN y la gestión del ciclo de vida de las credenciales necesaria para eliminar las contraseñas compartidas y proteger los activos corporativos.
¿Tiene preguntas sobre su configuración específica?
Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.