Si gestionas un SSID de personal con una contraseña compartida, ya conoces el patrón. Alguien se marcha y la contraseña debería cambiarse, pero no se hace. Se añade un contratista para un proyecto corto y mantiene el acceso más tiempo de lo previsto. El servicio de soporte sigue atendiendo tickets de usuarios que olvidaron a qué red unirse, introdujeron la contraseña correcta en la ventana equivocada o se quedaron atascados tras un cambio de contraseña.
Las organizaciones no mantienen las contraseñas de WiFi compartidas porque les gusten. Las mantienen porque son fáciles de explicar y rápidas de desplegar. El problema es que la comodidad operativa del primer día se convierte en deuda técnica al sexto mes. La autenticación mediante certificados WiFi soluciona esto al sustituir un secreto reutilizable por una identidad de dispositivo que la red puede verificar automáticamente.
El fin del problema de las contraseñas de WiFi compartidas
Un lunes por la mañana habitual se parece a esto. El departamento de instalaciones ha abierto una nueva zona, por lo que la contraseña de WiFi se ha entregado a más personas. Un empleado se ha marchado, un proveedor sigue en las instalaciones y alguien ha escrito la contraseña en una pizarra de la sala de comunicaciones porque "ayuda durante la configuración". A la hora de comer, la red sigue funcionando, pero nadie puede decir con seguridad qué dispositivos deberían estar conectados a ella.
Ese es el problema de las PSK y los portales cautivos. Facilitan el acceso al principio, pero complican su control a lo largo del tiempo. Las credenciales se comparten, se copian en notas, se guardan en dispositivos no gestionados y se conservan mucho después del momento en que deberían haberse eliminado. Si estás sopesando las ventajas y desventajas operativas y de seguridad, esta comparación de WPA2 Enterprise vs PSK ofrece un marco de referencia útil.
Qué cambia cuando desaparecen las contraseñas
Con la autenticación mediante certificados, el usuario no introduce 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. Esto cambia el modelo de soporte de inmediato.
En lugar de preguntar "¿Quién sabe la contraseña?", se pregunta "¿Debería tener acceso este dispositivo?". Esa es una pregunta mucho mejor. Vincula el acceso a un punto final gestionado, al estado de un usuario, o a ambos.
Se produce un cambio práctico en tres áreas:
- La salida de empleados es más precisa. Se revoca el acceso de un solo dispositivo o usuario en lugar de cambiar la contraseña para todo el mundo.
- El soporte se simplifica. Los usuarios ya no tienen que tomar decisiones manuales al conectarse, por lo que hay menos posibilidades de que la configuración falle.
- Las políticas se vuelven aplicables. Se puede exigir el uso de dispositivos gestionados para el acceso interno y mantener los dispositivos personales o de invitados en una vía independiente.
Las contraseñas compartidas se propagan de forma descontrolada por la organización. Los certificados no. Se mantienen vinculados a la identidad del dispositivo que has emitido.
Por qué funciona tan bien en entornos reales
La mayor mejora no es que la criptografía sea más sólida, aunque lo es. La gran ventaja es que el modelo operativo es más sensato. Una red para empleados debería comportarse como el acceso con tarjeta a una oficina, no como la pizarra de un pub con el código de hoy.
Por eso el WiFi basado en certificados suele consolidarse una vez que los equipos lo implementan correctamente. Elimina toda una categoría de fricciones y ofrece a los equipos de seguridad algo que rara vez obtienen de las configuraciones WiFi heredadas: un control individual y auditable.
Cómo funciona la autenticación por certificado en detalle
La forma más sencilla de entender la autenticación por certificado en WiFi es dejar de pensar en contraseñas y empezar a pensar en el acceso a un edificio.
Una contraseña WiFi compartida es como el código de una puerta escrito en la pared. Cualquiera que lo conozca puede entrar y, si se filtra, hay que cambiarlo para todo el mundo. 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í tiene la correspondencia práctica.
| Componente | Analogía en el mundo real | Función |
|---|---|---|
| 802.1X | Proceso de acceso por la puerta principal | Controla cómo solicita el acceso un dispositivo |
| EAP-TLS | Rutina de inspección de tarjetas | Define cómo se comprueba la identidad mediante certificados |
| Certificado | Tarjeta de identificación a prueba de manipulaciones | Demuestra que el dispositivo tiene una identidad emitida |
| Servidor RADIUS | Puesto de seguridad | Verifica la identidad presentada y devuelve una respuesta de permitir o denegar |
| Autoridad de certificación | Oficina emisora de tarjetas | Firma los certificados en los que la red decide confiar |
| Punto de acceso | Puerta o torno de acceso | Envía la autenticación a RADIUS y luego abre el acceso a la red |
En 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 soporte RADIUS, que verifica dicho certificado frente a una CA de confianza antes de conceder el acceso, y la clave privada nunca sale del dispositivo, tal como se describe en este resumen de la autenticación de 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 por la cual el acceso basado en certificados sigue apareciendo en los debates sobre zero-trust del Reino Unido.
Qué ocurre realmente al unirse a la red
El proceso de saludo parece complicado hasta que se reduce a una secuencia de comprobaciones.
El dispositivo se une 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í mismo. Retransmite la autenticación al servidor RADIUS.El servidor demuestra su identidad al dispositivo.
El dispositivo comprueba el certificado del servidor para asegurarse de que el cliente interactúa ú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 se superan las comprobaciones, el servidor RADIUS devuelve la aprobación y el AP permite que el dispositivo entre en la red.
Por qué es importante la autenticación mutua
El WiFi basado en contraseñas suele hacer una sola pregunta: ¿conoce el secreto? EAP-TLS hace dos. ¿Es la red realmente la que afirma ser y es el dispositivo realmente uno al que hemos emitido una identidad?
Regla práctica: Si sus dispositivos cliente no están validando el certificado del servidor RADIUS, habrá 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. Convierte el acceso inalámbrico, que antes era una práctica basada en secretos compartidos, en un flujo de trabajo de verificación de identidad.
Las ventajas de seguridad inigualables de prescindir de 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 generar un proceso de limpieza caótico. Hay que cambiar la clave del SSID, actualizar los dispositivos portátiles, configurar el hardware de las salas de reuniones y esperar que nadie haya copiado la contraseña antigua 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 un secreto que todos utilizan.
Si está evaluando alternativas operativas a las contraseñas, el passwordless WiFi es el enfoque adecuado. Su principal ventaja no es la novedad. Es el control.
Antes y después de la pérdida de un dispositivo
Antes de la autenticación mediante certificados, la pérdida de un portátil obligaba a tomar una decisión difícil. Dejar la contraseña compartida y asumir el riesgo, o cambiarla e interrumpir la actividad de todos los usuarios legítimos.
Después de la autenticación mediante certificados, la respuesta es mucho más precisa. Se revoca la confianza de ese dispositivo y se deja al resto en paz. Así es como debería ser un acceso inalámbrico maduro.
Antes y después de un intento de phishing
El WiFi basado en contraseñas acostumbra a los usuarios a confiar en los mensajes de solicitud de credenciales. Si un dispositivo detecta un SSID conocido, 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 un secreto. Esto elimina al factor humano de la parte del flujo de trabajo más propensa a errores.
Suelen destacar algunas mejoras directas:
- Confianza por dispositivo en lugar de confianza de grupo. Un certificado pertenece a un único endpoint, no a todo un departamento.
- Auditoría más clara. Puede vincular las decisiones de acceso a las credenciales emitidas y a los eventos de su ciclo de vida.
- Mayor alineación con zero-trust. La red puede exigir una identidad verificada antes de conceder acceso interno.
- Menos daños colaterales. Un único problema no obliga a restablecer las contraseñas de forma generalizada.
Por qué las redes falsas son más difíciles de explotar
Una red de tipo "evil twin" (gemelo malvado) se basa en la confusión. Imita a un SSID legítimo y espera a que los dispositivos o usuarios se conecten en el lugar equivocado. La autenticación mediante certificados dificulta este ataque porque el cliente debe validar el lado del servidor del intercambio antes de proceder.
Eso no significa que el diseño sea infalible por defecto. Significa que el despliegue debe realizarse correctamente. Si los equipos omiten la configuración de confianza de los certificados, aceptan cualquier certificado de servidor o realizan el onboarding de los dispositivos con instrucciones imprecisas, reducen el beneficio.
El passwordless WiFi es tan fuerte como lo sean sus anclajes de confianza y su proceso de registro. El saludo de conexión es sólido. Un onboarding descuidado, no.
La idea general es sencilla. Los secretos compartidos extienden el riesgo horizontalmente. Los certificados mantienen la confianza asociada a un punto de conexión conocido, que es exactamente donde debe comenzar una política de red inalámbrica moderna.
Dominio del ciclo de vida y el aprovisionamiento de certificados
La mayoría de los proyectos de WiFi basados en certificados que fracasan no lo hacen porque EAP-TLS no sea sólido. Fracasan porque el ciclo de vida se trató como una tarea de configuración única.
Emitir un certificado es la parte fácil. Mantenerlo al día, reemplazarlo antes de que expire, revocarlo cuando sea necesario y demostrar que los dispositivos correctos tienen los perfiles adecuados es donde se demuestra la madurez operativa. Si gestionas correctamente el ciclo de vida, el WiFi por certificado resulta más silencioso que el WiFi basado en contraseñas. Si lo gestionas mal, el día del vencimiento se convierte en una crisis para el equipo de soporte.
Comienza con la ruta de inscripción
Existen varios modelos de aprovisionamiento viables, pero no todos son iguales.
El aprovisionamiento gestionado por MDM o UEM suele ser la opción más limpia para las flotas gestionadas. Herramientas como Microsoft Intune, Jamf y Workspace ONE pueden enviar de forma conjunta cargas de certificados, raíces de confianza y configuraciones de WiFi. Esto reduce la intervención del usuario y facilita la renovación.
La emisión basada en SCEP o EST es útil cuando se desea una inscripción automatizada vinculada a un flujo de trabajo de PKI. Estos protocolos ayudan a los dispositivos a solicitar certificados de forma estructurada sin depender de la gestión manual de archivos. Son ideales cuando el equipo de PKI y el de puntos de conexión están alineados.
El aprovisionamiento manual todavía tiene cabida para proyectos piloto, entornos pequeños, dispositivos especializados o excepciones estrictamente controladas. No es el escenario en el que la mayoría de las organizaciones quieren establecerse a largo plazo.
Una comparación sencilla resulta de ayuda:
| Método de aprovisionamiento | Mejor opción para | Punto débil común |
|---|---|---|
| MDM/UEM | Portátiles, móviles y tabletas gestionados | Depende de una cobertura sólida de la gestión de dispositivos |
| SCEP o EST | Emisión corporativa automatizada | Requiere disciplina en el diseño de la PKI |
| Instalación manual | Grupos piloto y casos excepcionales | No es escalable y propicia 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, tal como se describe en la guía de autenticación de dispositivos GovWifi . La misma guía es sincera sobre el compromiso: las organizaciones deben entender la PKI y mantener los certificados TLS actualizados y seguros.
Ese último punto es en el que se centran los equipos experimentados. El punto débil no suele ser el intercambio de señales (handshake). Es la gestión del ciclo de vida.
Cómo es 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 que caduquen con suficiente margen para evitar cortes abruptos.
- Flujo de trabajo de revocación: los equipos de seguridad y de endpoints saben exactamente cómo se invalida un dispositivo perdido, robado o retirado.
- Gestión del almacén de confianza: los certificados raíz e intermedios se distribuyen de forma coherente entre las plataformas.
- Desmantelamiento: los dispositivos retirados pierden los certificados y los perfiles de WiFi como parte de su baja del servicio.
El certificado en sí no es el producto. El producto es un ciclo de vida funcional alrededor de ese certificado.
Lo que no funciona bien en la práctica
Hay algunos antipatrones que aparecen una y otra vez:
- "Ya los renovaremos más tarde". La caducidad no es un problema del futuro. Forma parte del diseño inicial.
- Equipos separados sin un proceso compartido. Los equipos de PKI, de endpoints y de red poseen cada uno una tercera parte de la verdad, y nadie posee el camino completo.
- Las excepciones manuales se convierten en norma. Las instalaciones puntuales se convierten en un parque de dispositivos sin gestionar.
- Sin pruebas de revocación. Los equipos asumen que la revocación funciona porque la PKI es compatible, pero nunca verifican cómo se comporta la red.
Los entornos más estables tratan la autenticación de WiFi por certificado como infraestructura básica de identidad del endpoint, no como una función de SSID. Esa mentalidad evita la mayoría de las interrupciones evitables.
Integrar la autenticación WiFi con su proveedor de identidad
Una vez que el acceso 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, los grupos y el estado de los dispositivos.
Esto significa vincular la política de acceso a la red a 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 independiente y se convierte en otra expresión de su modelo de identidad existente.
Por qué esto cambia las operaciones
Sin la integración con el IdP, el acceso WiFi suele gestionarse en un proceso secundario. Se crea un usuario en el directorio y, a continuación, alguien aprueba de forma independiente el acceso del dispositivo, crea un perfil o añade una regla en una consola de red. En esa duplicidad es donde se introducen los retrasos y las incoherencias.
Con la integración, el directorio se convierte en la única fuente de información. Cuando el departamento de 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 marcha, el mismo evento de identidad puede eliminar el acceso sin tener que esperar a realizar una tarea de red manual.
Esto proporciona coherencia en aspectos que suelen desajustarse:
- El estado del usuario y el acceso WiFi se mantienen alineados
- La pertenencia a grupos puede determinar la política
- El cumplimiento de los dispositivos puede influir en quién obtiene acceso al SSID interno
- La baja de usuarios se vuelve inmediata en lugar de depender de un ticket
Dónde encajan las plataformas
Esto se puede configurar de varias formas. 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 de tecnología.
Una opción gestionada como RADIUS-as-a-Service puede reducir la carga operativa de ejecutar una infraestructura de autenticación local, al tiempo que vincula la política a los sistemas de directorio. Este modelo suele resultar atractivo cuando el equipo de red desea controles de acceso basados en certificados sin tener que soportar otra plataforma de servidores.
La elección de diseño práctica
La pregunta de diseño no es "¿Puede mi WiFi utilizar certificados?", sino "¿Qué eventos de identidad deberían conceder, modificar o eliminar el acceso?"
Un modelo sensato suele ser el siguiente:
| Evento de identidad | Resultado de red |
|---|---|
| El usuario se incorpora | El dispositivo asignado recibe el perfil WiFi correcto |
| El usuario cambia de función | La política basada en grupos ajusta la asignación de VLAN, ACL o SSID |
| El dispositivo deja de cumplir las normas | El acceso interno se limita o se elimina |
| El usuario se marcha | El acceso se revoca como parte del proceso de baja |
Si su IdP ya decide quién puede acceder al correo electrónico, al SaaS y a la VPN, también debería influir en quién puede unirse a su WiFi interno.
Cuando los equipos realizan ese cambio, el WiFi deja de ser una tarea operativa aislada. Pasa a formar parte del control de acceso basado en la identidad, que es donde debe estar.
Prácticas recomendadas de despliegue y migración
Las migraciones más limpias rara vez son las más rápidas. Son escalonadas, observables y aburridas. Y eso es algo bueno.
La transición de un acceso PSK o de un Captive Portal a un WiFi basado en certificados no debe comenzar con un cambio de la noche a la mañana. Comience por demostrar 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 al personal para los dispositivos piloto, un grupo de inscripción pequeño y opciones claras de reversión.
Despliegue por fases
Una secuencia sencilla funciona bien en la mayoría de los entornos:
Configurar un SSID piloto
Limítelo al equipo de TI, seguridad y a un pequeño grupo de usuarios avanzados. Valide el despliegue de perfiles, el comportamiento de roaming y los modos de fallo.Probar todo el ciclo de vida, no solo la primera conexión
La renovación, la revocación, la sustitución de certificados y la baja de usuarios requieren ensayos. El éxito del primer día dice muy poco por sí solo.Ampliar por tipo de dispositivo
Comience con los portátiles y móviles gestionados. Deje los equipos especializados y las plataformas más 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 cuando la vía gestionada sea estable.
Diseñar para la revocación desde el primer día
La autenticación de certificados WiFi basada en EAP-TLS utiliza una validación mutua de certificados. El cliente verifica el certificado del servidor RADIUS y el servidor RADIUS verifica la firma, el emisor, la caducidad y el estado de revocación del certificado del cliente antes de emitir un Access-Accept, tal como se explica en esta guía sobre certificados EAP-TLS para WiFi . Esa misma guía señala que se debe configurar CRL u OCSP, y que OCSP es obligatorio para despliegues de alta seguridad y baja latencia.
Esto tiene una consecuencia práctica. La seguridad y la latencia están ligadas al diseño de la revocación. Si las comprobaciones de revocación se dejan para el final, puede acabar con decisiones de confianza obsoletas o retrasos molestos.
Una lista de comprobación de planificación útil:
- Elija su modelo de revocación de forma anticipada. No deje las decisiones sobre 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 un despliegue serio.
- 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 la ruta de PKI.
Nota de campo: la autenticación mediante certificados WiFi es tanto un proyecto de operaciones de PKI como un proyecto de red.
Gestione los dispositivos que no admiten 802.1X de forma limpia
Algunos terminales antiguos, dispositivos integrados y plataformas IoT particulares no admitirán el estándar 802.1X basado en certificados de una forma que sea gestionable. Pretender lo contrario solo ralentiza el proyecto.
Para esos dispositivos, utilice una estrategia independiente y limítela estrictamente. La tecnología iPSK puede ser una solución práctica de transición para los dispositivos que necesitan credenciales exclusivas pero no pueden realizar una autenticación completa por certificados. La clave es evitar que las excepciones contaminen el diseño destinado al personal. Mantenga estos dispositivos en rutas de políticas aisladas con un acceso más restringido.
Simplifique la incorporación para los usuarios
Un buen sistema de certificados WiFi suele ser invisible para el usuario. Un mal sistema de certificados WiFi les obliga a leer un PDF, aceptar tres avisos de confianza y llamar a un número de soporte técnico.
Para los dispositivos gestionados, el objetivo de la incorporación es que no haya puntos de decisión. El certificado, la cadena de confianza y el perfil WiFi deben llegar de forma conjunta. Para los dispositivos BYOD, utilice un flujo de trabajo independiente con un lenguaje sencillo y límites explícitos sobre el acceso que reciben dichos dispositivos.
Casos de uso reales y escenarios avanzados
El valor de la autenticación por certificado es más fácil de apreciar cuando se aplica en entornos reales en lugar de en diagramas de laboratorio.
En un hospital, el problema no es si el personal recuerda 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 forma constante sin tener que compartir credenciales. El acceso basado en certificados se adapta a ese modelo porque la decisión de confianza se basa en la identidad del dispositivo en lugar de en un secreto que tiende a difundirse.
En el sector minorista o de la hostelería, el patrón es ligeramente diferente. Los dispositivos del personal necesitan un acceso interno seguro, mientras que el acceso de invitados debe ser sencillo y segmentado. Ahí es donde el diseño inalámbrico basado en la identidad empieza a dar sus frutos. El mismo establecimiento puede admitir un acceso para el personal respaldado por certificados y una experiencia de invitados independiente diseñada para una incorporación más sencilla.
Dónde funciona especialmente bien
- Oficinas corporativas: los ordenadores portátiles y teléfonos gestionados se conectan automáticamente, y el acceso puede basarse en las políticas de directorio y del dispositivo.
- Centros sanitarios: las contraseñas compartidas desaparecen de los carros, las tabletas y las zonas de trabajo clínicas.
- Campus educativos: el personal y los dispositivos gestionados por la institución pueden conectarse sin peticiones de confirmación repetidas por todos los edificios.
- Entornos industriales y con alta densidad de IoT: los dispositivos compatibles con certificados obtienen controles de identidad más sólidos, mientras que el hardware no compatible se aísla mediante rutas de excepción.
Escenarios avanzados que conviene planificar
Las propiedades multiinquilino, las residencias de estudiantes y los grandes recintos a menudo requieren un enfoque híbrido. La experiencia de red debe resultar sencilla para el usuario, mientras que la aplicación de políticas subyacente debe seguir siendo estricta. Los certificados resultan de gran ayuda en lo que respecta al personal y a los dispositivos gestionados, ya que preservan la confianza por dispositivo incluso en entornos compartidos.
Passpoint y OpenRoaming también encajan de forma natural en este contexto, especialmente para el acceso de invitados y las visitas recurrentes. No son lo mismo que la autenticación interna EAP-TLS para el personal, pero comparten el mismo principio: reducir las fricciones al conectar y, al mismo tiempo, mejorar la confianza y la coherencia en segundo plano.
Los despliegues más sólidos no intentan imponer un único método a cada dispositivo y a cada tipo de usuario. Combinan la autenticación por certificado para los dispositivos que deben ser gestionados, un acceso segmentado de invitados para las visitas y una gestión de excepciones controlada para el hardware heredado.
Si está planeando dejar atrás las contraseñas compartidas de WiFi, Purple es una opción que puede evaluar junto con su infraestructura actual de PKI, MDM, RADIUS y gestión de identidades. Se centra en el acceso WiFi basado en la identidad para el personal, los invitados y los entornos multiinquilino, incluyendo patrones de acceso sin contraseña, autenticación gestionada en la nube e integración con plataformas de directorio.
