Si opera un SSID para el personal con una contraseña compartida, ya conoce el patrón. Alguien se va y la contraseña debería cambiar, pero no lo hace. Se añade a un contratista para un proyecto corto y mantiene el acceso más tiempo de lo previsto. El equipo de soporte sigue recibiendo tickets de usuarios que olvidaron a qué red unirse, o introdujeron la contraseña correcta en la solicitud equivocada, o se quedaron bloqueados tras una rotación de contraseñas.
Las organizaciones no mantienen las contraseñas compartidas de WiFi porque les gusten. Las mantienen porque son fáciles de explicar y rápidas de implementar. El problema es que la comodidad operativa del primer día se convierte en deuda técnica para el sexto mes. La autenticación por certificado de WiFi soluciona eso al reemplazar un secreto reutilizable con una identidad de dispositivo que la red puede verificar de forma automática.
El fin del problema de las contraseñas de WiFi compartidas
Un lunes por la mañana típico se ve así. Instalaciones ha abierto una nueva área, por lo que la contraseña de WiFi se ha entregado a más personas. Un empleado se ha ido, un proveedor sigue en el sitio y alguien ha escrito la contraseña en un pizarrón en una sala de comunicaciones porque "ayuda durante la configuración". Para la hora del almuerzo, la red sigue funcionando, pero nadie puede decir con certeza qué dispositivos deberían estar en ella.
Ese es el problema con las PSK y los portales cautivos. Hacen que el acceso sea fácil al principio, pero difícil de controlar con el tiempo. Las credenciales se comparten, se copian en notas, se guardan en dispositivos no administrados y se conservan mucho después del momento en que deberían haberse eliminado. Si está evaluando las ventajas y desventajas operativas y de seguridad, esta comparación de WPA2 Enterprise vs PSK es un marco de referencia útil.
Qué cambia cuando desaparecen las contraseñas
Con la autenticación por certificado, el usuario no escribe ninguna contraseña de WiFi. El dispositivo se aprovisiona con su propia identidad y la conexión se realiza de forma automática en segundo plano. Eso cambia el modelo de soporte de inmediato.
En lugar de preguntar: "¿Quién sabe la contraseña?", se pregunta: "¿Debería este dispositivo tener acceso?". Esa es una pregunta mucho mejor. Vincula el acceso a un punto final administrado, al estado de un usuario o a ambos.
Un cambio práctico ocurre en tres áreas:
- La baja de usuarios se vuelve precisa. Se revoca el acceso de un dispositivo o de un usuario en lugar de cambiar la contraseña para todos.
- El soporte se vuelve más limpio. Los usuarios dejan de tomar decisiones manuales durante la conexión, por lo que hay menos posibilidades de configurar algo mal.
- La política se vuelve aplicable. Puede exigir dispositivos administrados para el acceso interno y mantener los dispositivos personales o de invitados en una ruta independiente.
Las contraseñas compartidas se propagan de forma lateral por toda la organización. Los certificados no. Se mantienen vinculados a la identidad del dispositivo que usted emitió.
Por qué esto funciona bien en entornos reales
La mayor mejora no es que la criptografía sea más fuerte, aunque lo es. El mayor beneficio es que el modelo operativo es más sensato. Una red para el personal debería comportarse como el acceso con tarjeta de identificación a una oficina, no como el pizarrón de un bar con el código del día.
Es por eso que el WiFi basado en certificados suele consolidarse una vez que los equipos lo implementan correctamente. Elimina toda una categoría de fricción y, al mismo tiempo, ofrece a los equipos de seguridad algo que rara vez obtienen de las configuraciones de WiFi heredadas: un control individual y auditable.
Cómo funciona la autenticación por certificado tras bambalinas
La forma más sencilla de entender la autenticación por certificado de WiFi es dejar de pensar en contraseñas y empezar a pensar en el acceso a un edificio.
Una contraseña de WiFi compartida es como el código de una puerta escrito en la pared. Cualquiera que lo sepa puede entrar y, si se filtra, hay que cambiarlo para todos. Una red basada en certificados funciona más bien como una oficina segura con tarjetas de identificación, un recepcionista y una lista central de emisores de tarjetas de confianza.
Los componentes principales
Aquí está el mapeo práctico.
| Componente | Analogía en el mundo real | Función |
|---|---|---|
| 802.1X | Proceso de acceso en la puerta principal | Controla cómo un dispositivo solicita la entrada |
| EAP-TLS | Rutina de inspección de tarjetas | Define cómo se verifica la identidad con los certificados |
| Certificado | Tarjeta de identificación a prueba de alteraciones | Demuestra que el dispositivo tiene una identidad emitida |
| Servidor RADIUS | Escritorio de seguridad | Verifica la identidad presentada y devuelve la aprobación o rechazo |
| Autoridad de Certificación | Oficina emisora de tarjetas | Firma los certificados en los que la red acuerda confiar |
| Punto de acceso | Puerta o torniquete | Pasa la autenticación a RADIUS y luego abre el acceso a la red |
En los entornos empresariales y del sector público del Reino Unido, la base técnica es 802.1X/EAP-TLS. El dispositivo presenta un certificado X.509 a un servidor de autenticación con respaldo de RADIUS, el cual verifica dicho certificado frente a una CA de confianza antes de conceder el acceso; además, la clave privada nunca sale del dispositivo, tal como se describe en esta perspectiva general de la autenticación mediante certificados WiFi . La misma fuente señala que el Cyber Assessment Framework v3.1 de 2023 del NCSC destaca la autenticación sólida y la garantía de identidad sólida como controles principales para los servicios críticos, razón exacta por la cual el acceso basado en certificados sigue apareciendo en los debates sobre zero-trust en el Reino Unido.
Qué ocurre realmente durante la conexión
El saludo de conexión parece complicado hasta que se reduce a una secuencia de comprobaciones.
El dispositivo se conecta al SSID.
No envía una contraseña. Inicia un intercambio 802.1X.El punto de acceso reenvía la solicitud.
El AP no toma la decisión de confianza por sí solo. Retransmite la autenticación al servidor RADIUS.El servidor demuestra su identidad al dispositivo.
El dispositivo comprueba el certificado del servidor para garantizar que el cliente interactúe únicamente con un servicio de autenticación de confianza.El dispositivo presenta su propio certificado.
Esta es la credencial digital. La clave privada permanece en el dispositivo y se utiliza para demostrar la posesión.RADIUS valida la cadena de certificados.
Comprueba si el certificado fue emitido por una CA de confianza y si la política permite que ese dispositivo acceda a esa red.Se concede el acceso.
Si las comprobaciones son correctas, el servidor RADIUS devuelve la aprobación y el AP permite que el dispositivo se conecte a la red.
Por qué es importante la autenticación mutua
El WiFi basado en contraseñas suele hacer una sola pregunta: ¿conoces el secreto? EAP-TLS hace dos. ¿Es la red realmente la que afirma ser y es el dispositivo realmente uno al que le hemos emitido una identidad?
Regla práctica: Si los dispositivos de tus clientes no validan el certificado del servidor RADIUS, habrás mantenido la complejidad del WiFi empresarial sin obtener el modelo de confianza completo.
Esa comprobación mutua es la razón principal por la que el WiFi basado en certificados funciona mejor en entornos regulados y sensibles a la seguridad. Transforma el acceso inalámbrico de un ejercicio de secreto compartido en un flujo de trabajo de verificación de identidad.
Los inigualables beneficios de seguridad de eliminar las contraseñas
El argumento más sólido a favor del WiFi basado en certificados no es abstracto. Es visible en el antes y el después de los incidentes cotidianos.
Con una contraseña compartida, una sola credencial filtrada puede crear una tarea de limpieza caótica. Tienes que cambiar la clave del SSID, actualizar los dispositivos portátiles, configurar el hardware de las salas de conferencias y esperar que nadie haya copiado la contraseña anterior en alguna configuración guardada. Con los certificados, el radio de impacto es menor porque el acceso está vinculado a una identidad emitida específica, no a una clave utilizada por todos.
Si estás evaluando alternativas operativas a las contraseñas, el passwordless WiFi es el enfoque correcto. Su principal ventaja no es la novedad. Es el control.
Antes y después de perder un dispositivo
Antes de la autenticación por certificado, la pérdida de una laptop obligaba a tomar una decisión difícil: dejar la contraseña compartida y aceptar el riesgo, o cambiarla e interrumpir a todos los usuarios legítimos.
Con la autenticación por certificado, la respuesta es más precisa. Revocas la confianza de ese dispositivo y dejas a todos los demás tranquilos. Así es como debería verse un acceso inalámbrico maduro.
Antes y después de una solicitud tipo phishing
El WiFi basado en contraseñas acostumbra a los usuarios a confiar en las ventanas de diálogo. Si un dispositivo detecta un SSID familiar, muchos usuarios escribirán lo que se les pida. Ese hábito es difícil de defender a gran escala.
El WiFi basado en certificados cambia el comportamiento del cliente. El dispositivo se autentica con su identidad instalada en lugar de pedirle al usuario que introduzca una contraseña. Esto elimina al factor humano de la parte más propensa a errores del flujo de trabajo.
Unas pocas mejoras directas suelen ser lo más importante:
- Confianza por dispositivo en lugar de confianza grupal. Un certificado pertenece a un dispositivo final, no a todo un departamento.
- Auditoría más clara. Puedes vincular las decisiones de acceso a las credenciales emitidas y a los eventos del ciclo de vida.
- Mayor alineación con zero-trust. La red puede requerir una identidad verificada antes de otorgar acceso interno.
- Menos daños colaterales. Un solo problema no obliga a realizar un restablecimiento general de contraseñas.
Por qué las redes falsas se vuelven más difíciles de explotar
Una red de tipo "evil twin" depende de la confusión. Imita un SSID legítimo y espera a que los dispositivos o usuarios se conecten en el lugar equivocado. La autenticación por certificado dificulta ese ataque porque el cliente debe validar el lado del servidor del intercambio antes de continuar.
Esto no significa que el diseño sea infalible por defecto. Significa que la implementación debe realizarse correctamente. Si los equipos omiten la configuración de confianza de los certificados, aceptan cualquier certificado de servidor o registran dispositivos con instrucciones deficientes, reducen el beneficio.
El WiFi sin contraseña es tan fuerte como sus procesos de inscripción y sus puntos de confianza. El saludo de conexión es sólido. El registro descuidado no lo es.
El punto general es simple. Los secretos compartidos extienden el riesgo horizontalmente. Los certificados mantienen la confianza vinculada a un punto final conocido, que es exactamente donde debería comenzar una política inalámbrica moderna.
Dominar el ciclo de vida y el aprovisionamiento de certificados
La mayoría de los proyectos fallidos de certificados WiFi no fallan porque EAP-TLS sea defectuoso. Fallan porque el ciclo de vida se trató como una tarea de configuración única.
Emitir un certificado es la parte fácil. Mantenerlo actualizado, reemplazarlo antes de que expire, revocarlo cuando sea necesario y demostrar que los dispositivos correctos tienen los perfiles correctos es donde se demuestra la madurez operativa. Si gestiona bien el ciclo de vida, el WiFi basado en certificados se vuelve más silencioso que el WiFi basado en contraseñas. Si lo gestiona mal, el día del vencimiento se convierte en un colapso del soporte técnico.
Comience con la ruta de registro
Existen varios modelos de aprovisionamiento viables, pero no son iguales.
El aprovisionamiento impulsado por MDM o UEM suele ser la opción más limpia para flotas administradas. Herramientas como Microsoft Intune, Jamf y Workspace ONE pueden enviar payloads de certificados, raíces de confianza y configuraciones de WiFi de manera conjunta. Esto reduce la interacción del usuario y hace que la renovación sea práctica.
La emisión basada en SCEP o EST es útil cuando se desea un registro automatizado vinculado a un flujo de trabajo de PKI. Estos protocolos ayudan a los dispositivos a solicitar certificados de manera estructurada sin depender de la manipulación manual de archivos. Se adaptan mejor cuando el equipo de PKI y el equipo de puntos finales están alineados.
El aprovisionamiento manual todavía tiene cabida para pilotos, entornos pequeños, dispositivos especializados o excepciones estrechamente controladas. No es el lugar donde la mayoría de las organizaciones quieren estar a largo plazo.
Una comparación sencilla ayuda:
| Método de aprovisionamiento | Mejor opción | Debilidad común |
|---|---|---|
| MDM/UEM | Laptops, móviles y tablets administrados | Depende de una cobertura de gestión de dispositivos estable |
| SCEP o EST | Emisión empresarial automatizada | Requiere disciplina de diseño de PKI |
| Instalación manual | Grupos piloto y casos excepcionales | No es escalable y genera problemas de vencimiento |
La disciplina del ciclo de vida importa más que el despliegue inicial
El modelo de autenticación basado en certificados GovWifi del gobierno del Reino Unido es un buen ejemplo de la realidad operativa. Cada dispositivo gestionado se aprovisiona con una cadena de certificados única y luego se autentica automáticamente en las redes GovWifi cercanas sin introducir una contraseña, ya que el dispositivo presenta su certificado al servidor RADIUS y el acceso se concede solo después de que la verificación del certificado se realiza correctamente, como se describe en la guía de autenticación de dispositivos GovWifi . La misma guía es sincera sobre la compensación: las organizaciones necesitan entender PKI y mantener los certificados TLS vigentes y seguros.
Ese último punto es donde se enfocan los equipos experimentados. El punto débil no suele ser el saludo de conexión o handshake. Es la gestión del ciclo de vida.
Cómo se ve una buena gestión del ciclo de vida
Las buenas implementaciones suelen tener cuatro hábitos establecidos desde el principio:
- Renovación automatizada: Los dispositivos se renuevan antes de su vencimiento con suficiente margen para evitar interrupciones drásticas.
- Flujo de trabajo de revocación: Los equipos de seguridad y de endpoints saben exactamente cómo invalidar un dispositivo extraviado, robado o retirado.
- Gestión del almacén de confianza: Los certificados raíz e intermedios se distribuyen de forma consistente en todas las plataformas.
- Desincorporación: Los dispositivos retirados pierden los certificados y los perfiles de WiFi como parte del proceso de salida o deba de usuarios.
El certificado en sí no es el producto. El producto es un ciclo de vida funcional en torno a ese certificado.
Lo que no funciona bien en la práctica
Algunos antipatrones aparecen una y otra vez:
- "Los renovaremos más tarde". El vencimiento no es un problema del futuro. Es parte del diseño inicial.
- Equipos separados sin un proceso compartido. Los equipos de PKI, de endpoints y de red poseen cada uno un tercio de la verdad, y nadie es dueño de la ruta completa.
- Excepciones manuales que se convierten en la norma. Las instalaciones únicas se transforman en una infraestructura sin gestionar.
- Sin pruebas de revocación. Los equipos asumen que la revocación funciona porque la PKI lo soporta, pero nunca verifican cómo se comporta la red.
Los entornos más estables tratan la autenticación de certificados WiFi como una infraestructura de identidad de endpoints, no como una función de SSID. Esa mentalidad evita la mayoría de las interrupciones evitables.
Integración de la autenticación WiFi con su proveedor de identidad
Una vez que el WiFi basado en certificados está en su lugar, el siguiente paso de madurez es obvio. Deje de tratar el acceso inalámbrico como una isla separada y conéctelo al sistema de identidad que ya rige a los usuarios, grupos y el estado de los dispositivos.
Esto significa vincular la política de acceso a la red con un proveedor de identidad como Microsoft Entra ID, Google Workspace u Okta. En la práctica, la red inalámbrica deja de ser un problema de autenticación aislado y se convierte en otra expresión de su modelo de identidad existente.
Por qué esto cambia las operaciones
Sin la integración de IdP, el acceso a la WiFi a menudo vive en un proceso secundario. Se crea un usuario en el directorio y, a continuación, alguien aprueba por separado el acceso al dispositivo, crea un perfil o añade una regla en una consola de red. Esa duplicación es donde se introducen los retrasos y las inconsistencias.
Con la integración, el directorio se convierte en la única fuente de información. Cuando Recursos Humanos incorpora a un nuevo empleado, el ciclo de vida de la cuenta puede activar el registro de dispositivos y la asignación de perfiles. Cuando alguien se va, el mismo evento de identidad puede eliminar el acceso sin tener que esperar a una tarea de red manual.
Eso le proporciona consistencia en áreas que suelen desalinearse:
- El estado de usuario y el acceso a la WiFi se mantienen alineados
- La membresía de grupo puede definir las políticas
- El cumplimiento del dispositivo puede influir en quién obtiene acceso al SSID interno
- La desvinculación se vuelve inmediata en lugar de depender de un ticket
Dónde encajan las plataformas
Puede estructurar esto de varias maneras. Algunas organizaciones conectan RADIUS, PKI y MDM directamente y mantienen el plano de control a nivel interno. Otras utilizan servicios gestionados en la nube para simplificar esa pila tecnológica.
Una opción gestionada como RADIUS-as-a-Service puede reducir la carga operativa de ejecutar infraestructura de autenticación de forma local (on-prem) al mismo tiempo que vincula las políticas a los sistemas de directorio. Ese modelo suele resultar atractivo cuando el equipo de red desea controles de acceso basados en certificados sin necesidad de gestionar otra plataforma de servidores.
La decisión de diseño práctica
La pregunta de diseño no es "¿Puede mi WiFi utilizar certificados?" Es "¿Qué eventos de identidad deberían conceder, modificar o eliminar el acceso?"
Un modelo sensato suele verse así:
| Evento de identidad | Resultado de red |
|---|---|
| El usuario se incorpora | El dispositivo asignado recibe el perfil de WiFi correcto |
| El usuario cambia de rol | La política basada en grupos ajusta el derecho a VLAN, ACL o SSID |
| El dispositivo deja de cumplir normativas | El acceso interno se limita o se elimina |
| El usuario se va | El acceso se revoca como parte del proceso de desvinculación |
Si su IdP ya decide quién puede acceder al correo electrónico, SaaS y VPN, también debería influir en quién puede unirse a su WiFi interna.
Cuando los equipos realizan esa transición, el WiFi deja de ser una tarea operativa aislada. Se convierte en parte del control de acceso basado en la identidad, que es el lugar al que pertenece.
Mejores prácticas de implementación y migración
Las migraciones más limpias rara vez son las más rápidas. Son escalonadas, observables y aburridas. Eso es algo bueno.
La transición de un acceso por PSK o Captive Portal a un WiFi basado en certificados no debe comenzar con un cambio drástico de la noche a la mañana. Comience por probar la cadena de confianza, el comportamiento de los clientes y la mecánica del ciclo de vida con un diseño paralelo. En la práctica, esto suele significar un SSID dedicado para el personal para dispositivos piloto, un grupo de inscripción pequeño y opciones claras de reversión.
Implementación por fases
Una secuencia sencilla funciona bien en la mayoría de los entornos:
Configurar un SSID piloto
Limítelo a TI, seguridad y un grupo pequeño de usuarios avanzados. Valide la implementación de perfiles, el comportamiento de roaming y los modos de falla.Probar el ciclo de vida completo, no solo la primera conexión
La renovación, revocación, el reemplazo de certificados y la baja de usuarios requieren ensayos. El éxito del primer día dice muy poco por sí solo.Expandir por clase de dispositivo
Comience con laptops y dispositivos móviles administrados. Deje los equipos especializados y las plataformas complejas para fases posteriores.Retirar el acceso heredado de forma gradual
Dé tiempo a los usuarios para realizar la transición. Elimine la dependencia de contraseñas compartidas solo después de que la ruta administrada sea estable.
Diseñar para la revocación desde el primer día
La autenticación de certificados WiFi basada en EAP-TLS utiliza la validación mutua de certificados. El cliente verifica el certificado del servidor RADIUS y el servidor RADIUS verifica la firma del certificado del cliente, el emisor, la expiración y el estado de revocación antes de emitir un Access-Accept, como se explica en esta guía de certificados EAP-TLS para WiFi . Esa misma guía señala que se debe configurar CRL u OCSP, y que OCSP es obligatorio para implementaciones de alta seguridad y baja latencia.
Esto tiene una consecuencia práctica. La seguridad y la latencia están vinculadas al diseño de la revocación. Si las comprobaciones de revocación se dejan como una idea de último momento, se pueden producir decisiones de confianza obsoletas o retrasos problemáticos.
Una lista de verificación de planificación útil:
- Elija su modelo de revocación de forma anticipada. No deje las decisiones de CRL u OCSP para después de que los usuarios se conecten.
- Automatice la renovación de certificados. La renovación impulsada por MDM o UEM no es opcional en una implementación seria.
- Valide la confianza del certificado del servidor en los clientes. Un cliente que omite esta comprobación debilita todo el diseño.
- Mida el comportamiento de la conexión durante las pruebas. Esté atento a los retrasos que apunten a problemas de revocación o de ruta PKI.
Nota de campo: la autenticación mediante certificados de WiFi es tanto un proyecto de operaciones PKI como un proyecto de red.
Gestione los dispositivos que no admiten 802.1X de forma limpia
Algunos terminales heredados, dispositivos embebidos y plataformas de IoT particulares no admitirán la autenticación 802.1X basada en certificados de una manera fácil de gestionar. Pretender lo contrario solo retrasará el proyecto.
Para esos dispositivos, utilice una estrategia independiente y limítelos estrictamente. iPSK puede ser un puente práctico para dispositivos que necesitan credenciales únicas pero no pueden realizar una autenticación completa por certificado. La clave es evitar que las excepciones contaminen el diseño del personal. Mantenga estos dispositivos en rutas de política aisladas con un acceso más restringido.
Simplifique la incorporación para los usuarios
Una buena experiencia de WiFi con certificado suele ser invisible para el usuario. Un mal sistema de WiFi con certificado les entrega un PDF, tres solicitudes de confianza y un número de soporte técnico.
Para dispositivos gestionados, el objetivo de incorporación es cero puntos de decisión. El certificado, la cadena de confianza y el perfil de WiFi deben llegar juntos. Para BYOD, utilice un flujo de trabajo independiente con un lenguaje sencillo y límites explícitos sobre el acceso que reciben esos dispositivos.
Casos de uso reales y escenarios avanzados
El valor de la autenticación mediante certificados es más fácil de apreciar cuando se aplica en entornos reales en lugar de diagramas de laboratorio.
En un hospital, el problema no es si el personal puede recordar una contraseña. El problema es si los dispositivos clínicos gestionados, las estaciones de trabajo móviles y los terminales especializados pueden conectarse de manera constante sin tener que compartir credenciales. El acceso basado en certificados se adapta a ese modelo porque la decisión de confianza sigue a la identidad del dispositivo en lugar de a un secreto que tiende a difundirse.
En un entorno comercial o de hospitalidad, el patrón es ligeramente diferente. Los dispositivos del personal necesitan un acceso interno seguro, mientras que el acceso de invitados debe seguir siendo sencillo y segmentado. Ahí es donde el diseño inalámbrico basado en la identidad empieza a dar resultados. El mismo lugar puede admitir un acceso para el personal respaldado por certificados y una experiencia de invitado independiente diseñada para una incorporación más sencilla.
Dónde funciona especialmente bien
- Oficinas corporativas: las laptops y teléfonos gestionados se conectan automáticamente, y el acceso puede regirse por las políticas del directorio y del dispositivo.
- Entornos de atención médica: las contraseñas compartidas desaparecen de los carros, las tabletas y las áreas de trabajo clínico.
- Campus educativos: el personal y los dispositivos gestionados por la institución pueden conectarse sin solicitudes repetidas en todos los edificios.
- Sitios industriales y con alta densidad de IoT: Los dispositivos que admiten certificados obtienen controles de identidad más sólidos, mientras que el hardware que no los admite se aísla mediante rutas de excepción.
Escenarios avanzados que vale la pena planificar
Las propiedades multi-tenant, las residencias de estudiantes y los recintos de gran tamaño a menudo necesitan un enfoque híbrido. La experiencia de red debe parecer sencilla para el usuario, mientras que la aplicación de políticas subyacente sigue siendo estricta. Los certificados ayudan en el lado del personal y de los dispositivos gestionados porque preservan la confianza por dispositivo, incluso cuando el entorno es altamente compartido.
Passpoint y OpenRoaming también encajan de forma natural en este contexto, especialmente para el acceso de invitados y visitas recurrentes. No son lo mismo que la autenticación interna EAP-TLS para el personal, pero comparten el mismo principio: reducir la fricción al momento de la conexión y, al mismo tiempo, mejorar la confianza y la consistencia tras bambalinas.
Las implementaciones más sólidas no intentan imponer un solo método a cada dispositivo y a cada tipo de usuario. Combinan la autenticación por certificado para los dispositivos que deben gestionarse, el acceso segmentado de invitados para los visitantes y la gestión controlada de excepciones para el hardware heredado.
Si está planeando dejar atrás las contraseñas compartidas de WiFi, Purple es una opción a evaluar junto con su infraestructura actual de PKI, MDM, RADIUS y gestión de identidad. Se enfoca en el acceso a WiFi basado en identidad para personal, invitados y entornos multi-tenant, incluyendo esquemas de acceso sin contraseña, autenticación gestionada en la nube e integración con plataformas de directorio.
