Migración de la red WiFi de personal desde una contraseña compartida a 802.1X en una infraestructura multisede

Ejecute un nuevo SSID WPA-Enterprise junto al SSID con contraseña compartida y mueva los dispositivos por oleadas. Los dispositivos gestionados obtienen certificados EAP-TLS desde su MDM. Los teléfonos personales se incorporan a través de un Captive Portal. Los dispositivos que no pueden albergar un certificado obtienen su propia clave en una red xPSK. Desconecte la contraseña compartida en cada ubicación una vez que su registro de autenticación no muestre dispositivos heredados.

¿Qué cambia al migrar el WiFi del personal de una contraseña compartida a 802.1X?

Una contraseña de personal compartida es un único secreto en posesión de cada compañero, cada dispositivo y cada excompañero. Cuando alguien se va, se la queda. Cambiarla significa volver a introducir la clave en cada caja registradora, tablet y portátil de cada ubicación.

El requisito 2.3.2 de PCI-DSS v4.0.1 convierte esto en una obligación. Cubre los entornos inalámbricos conectados al entorno de datos de titulares de tarjetas o que transmiten datos de cuentas. Debe cambiar las claves de cifrado inalámbricas siempre que alguien que las conozca deje la empresa o el puesto que las requería. También debe cambiarlas cuando se sospeche o se sepa que una clave ha sido comprometida. En una plantilla con alta rotación, una lectura literal significa cambiar las claves la mayoría de las semanas.

IEEE 802.1X elimina el secreto compartido. Es el estándar para el control de acceso a redes basado en puertos. Un dispositivo debe probar quién es antes de que el punto de acceso reenvíe su tráfico. El punto de acceso pregunta a través de RADIUS, el protocolo que el equipo de red utiliza para consultar a un servidor de autenticación.

EAP-TLS (Extensible Authentication Protocol with Transport Layer Security, RFC 5216) es la forma más sólida de responder. El dispositivo y el servidor presentan cada uno un certificado. No hay contraseña que compartir, ser objeto de phishing o escribir en la pizarra de la oficina.

La identidad establece entonces la VLAN (virtual LAN, un segmento de red lógicamente independiente). RADIUS devuelve una VLAN para cada dispositivo utilizando los atributos de túnel definidos en el RFC 3580. Un portátil de finanzas y una tablet de cocina pueden unirse al mismo SSID y acabar en segmentos diferentes.

Dónde se ubica esto en Purple Access

Purple Access ejecuta tres redes en una sola plataforma:

• Open: un Captive Portal, la página web que ve un dispositivo antes de obtener acceso a la red. En esta migración, incorpora teléfonos personales.
• Secure: EAP-TLS, integración con proveedores de identidad, Passpoint y RADIUS en la nube. Los portátiles, tablets y teléfonos del personal terminan aquí.
• xPSK: una clave independiente para cada dispositivo, llamada iPSK o PPSK según su proveedor. Cada dispositivo que no pueda albergar un certificado termina aquí.

El WiFi de invitados permanece en su propia red y fuera de este proyecto. La guía Guest network security: A practical Guide for 2026 cubre ese aspecto. El filtrado DNS en cualquiera de estas redes corresponde a Shield. Para obtener una visión más amplia, consulte nuestra guía sobre WiFi security.

Comparativa de modelos de credenciales

PEAP-MSCHAPv2 (Protected EAP con nombre de usuario y contraseña) suele ser la solución intermedia habitual, por lo que debe incluirse en la comparación.

Modelo de credenciales	Qué presenta cada dispositivo	Qué se lleva una persona al irse de la empresa	Revocación de una persona o dispositivo	Efecto sobre los cambios de clave según PCI DSS 2.3.2	Ámbito adecuado
PSK compartida	Una única contraseña para todos	La clave de cada ubicación	Volver a generar la clave para todos los dispositivos del SSID	Cambiar la clave para todos cada vez que la conozca alguien que deje la empresa	Una sola ubicación pequeña sin datos de tarjetas en la red WiFi
PEAP-MSCHAPv2	Nombre de usuario y contraseña personales	Su propia contraseña hasta que se deshabilite la cuenta	Deshabilitar la cuenta	No hay clave compartida, pero las contraseñas se pueden capturar si no se validan los certificados del servidor	Redes o instalaciones que aún no disponen de una autoridad de certificación
EAP-TLS	Un certificado por dispositivo o persona	Nada utilizable una vez revocado el certificado	Revocar el certificado o deshabilitar la identidad	No hay clave compartida que cambiar	Portátiles gestionados, tabletas, terminales de mano y teléfonos incorporados
xPSK	Una clave única por dispositivo	Solo las claves de los dispositivos que haya introducido personalmente	Eliminar la clave de ese dispositivo	Cambiar solo las claves que haya gestionado la persona que se marcha	Cajas registradoras, terminales de pago, impresoras, CCTV, señalización digital

¿Qué se necesita antes de migrar una contraseña WiFi compartida a 802.1X?

No se necesitan nuevos puntos de acceso. Purple Access es independiente del hardware y funciona como una superposición en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Solo se deben tener preparadas seis cosas antes de la prueba piloto.

1. Un inventario de dispositivos por ubicación. Exporte la lista de clientes para el SSID del personal desde la consola de cada ubicación, cubriendo al menos 14 días. Clasifique cada dispositivo en una de las tres categorías siguientes: Los dispositivos gestionados están inscritos en su plataforma MDM (Mobile Device Management). Los dispositivos personales son teléfonos propiedad del personal. Los dispositivos sin interfaz de usuario (headless) son cajas registradoras, terminales de pago, impresoras, cámaras y cualquier otro equipo sin almacén de certificados.
2. Un proveedor de identidades con grupos limpios. Utilice Microsoft Entra ID, Okta o Google Workspace. Cada grupo que necesite su propio segmento se convierte en una regla de VLAN. En Okta WiFi Authentication: Setup Steps, Options and Fixes se explica detalladamente el proceso en el entorno de Okta.
3. Una autoridad de certificación a la que su MDM pueda realizar solicitudes. Microsoft Intune, Jamf Pro y la mayoría de los demás sistemas MDM emiten certificados a través de perfiles SCEP (Simple Certificate Enrollment Protocol) o PKCS. Decida ahora si un certificado identifica al dispositivo o a la persona. Las tabletas compartidas y los terminales de mano necesitan certificados de dispositivo.
4. Un plan de VLAN extendido a cada ubicación. Un plan típico consta de cinco segmentos: personal, dispositivos corporativos gestionados, dispositivos de pago, otros dispositivos sin interfaz de usuario y un segmento restringido para sistemas heredados. Confirme que el enlace troncal (trunk) del conmutador a cada punto de acceso admita todas las VLAN.
5. Configurar Purple Access como el servidor RADIUS para el SSID seguro. En caso de que su proveedor utilice RADIUS para claves por dispositivo, apunte también la red xPSK hacia él. Contar con RADIUS-as-a-Service implica que no hay nada que instalar, parchear ni agrupar en clústeres en las sedes o ubicaciones.
6. Un responsable asignado en cada centro. Necesita a alguien que pueda identificar los dispositivos desconocidos en el inventario y aprobar su desconexión.

¿Cómo migrar la red WiFi de los empleados a 802.1X sin un fin de semana de transición?

Tres principios eliminan el fin de semana de transición. Cree las nuevas redes junto a la antigua. Mueva los dispositivos por clase, no por centro. Desconecte centro por centro, basándose en las evidencias del registro de autenticación.

¿Se pueden ejecutar ambos SSID durante la migración?

Sí, y debería ejecutarlos juntos durante todo el proyecto. La verdadera cuestión es el tiempo de aire (airtime). Cada SSID emitido añade tramas beacon en cada radio, por lo que las guías de diseño de los fabricantes, entre ellas la de Cisco Meraki, recomiendan mantener bajo el número de SSID.

La solución más limpia consiste en convertir el SSID antiguo en la red xPSK. Mantenga su nombre y modo de seguridad. Añada la contraseña compartida antigua como una clave más dentro de la lista de claves por dispositivo, asignada a la VLAN reducida antigua. Los dispositivos que conocen la contraseña antigua se reconectan sin darse cuenta. Cada dispositivo que traslada recibe su propia clave.

Cuando a la clave antigua no le queden dispositivos en un centro, elimínela. La contraseña compartida quedará desactivada y nunca habrá aparecido un nuevo SSID. Su estado final será de tres SSID: invitados, empleados seguro y xPSK.

Pruebe esto primero en un centro. Varios fabricantes ejecutan funciones por clave en WPA2-Personal en lugar de WPA3-SAE, así que consulte la documentación de su fabricante. Si su plataforma no puede albergar la contraseña antigua como una clave, ejecute cuatro SSID durante la migración y elimine el SSID antiguo en el momento de la desconexión.

Fase 1: crear una vez y aplicar a todas las instalaciones

Configure el SSID seguro y la red xPSK una vez y, a continuación, aplíquelos a cada centro desde una plantilla. Utilice WPA3-Enterprise donde su flota gestionada lo admita; de lo contrario, utilice un modo de transición WPA2/WPA3.

Fabricante	Consola	Configuración de SSID seguro	Función de clave por dispositivo	Aplicar en varios centros con
Cisco Meraki	Meraki Dashboard	Enterprise con mi servidor RADIUS	Identity PSK (iPSK)	Plantillas de configuración
HPE Aruba	Aruba Central	Nivel de seguridad Enterprise	MPSK	Grupos
Ruckus	SmartZone o RUCKUS One	Autenticación 802.1X EAP	Dynamic PSK (DPSK)	Zonas o ubicaciones
Juniper Mist	Portal Mist	Seguridad WLAN Enterprise (802.1X)	Multi PSK	Plantillas WLAN
Ubiquiti UniFi	UniFi Network	WPA Enterprise con un perfil RADIUS	Private Pre-Shared Keys	Configuración del sitio por centro

Las etiquetas cambian entre versiones de firmware, por lo que debe seguir la documentación de su fabricante para conocer la ruta actual. Encontrará más guías paso a paso de configuración en nuestras Guías de acceso.

Fase 2: prueba piloto en dos o tres centros representativos

Elija centros que sean diferentes: uno grande, uno pequeño y uno con un modelo de switch poco habitual. Ejecute todas las fases posteriores de principio a fin primero en esos centros. El piloto existe para encontrar el enlace troncal que no transporta una VLAN, la caja registradora que solo admite WPA2 y el perfil MDM que se instala en el orden incorrecto.

Fase 3: enviar certificados a dispositivos gestionados a través del MDM

Los dispositivos gestionados son los que más rápido avanzan porque el MDM llega a todas las sedes a la vez. Despliegue tres perfiles en orden: el certificado de raíz de confianza, el certificado de dispositivo y, a continuación, el perfil de WiFi. La mayoría de los MDM fallan en el perfil de WiFi si falta el certificado al que hacen referencia.

El perfil de WiFi define el SSID seguro, establece EAP-TLS y fija el nombre y la raíz del certificado del servidor RADIUS. Una vez que un dispositivo se haya autenticado en el SSID seguro, envíe un perfil que elimine la red antigua. De lo contrario, el dispositivo podría volver al SSID anterior en el que ya confía.

Fase 4: incorporar teléfonos personales al mismo SSID

El personal se conecta a la red abierta, a menudo escaneando un código QR colocado en la oficina central. Inician sesión en el Captive Portal con su identidad corporativa y reciben el perfil de red seguro. Nuestra guía principal sobre Captive portals cubre el diseño de portales.

Un perfil Passpoint (Hotspot 2.0) es lo que más ayuda a una red multisede. Passpoint permite que un teléfono encuentre una red y se una a ella por sus credenciales en lugar de por el nombre del SSID. Así, una única incorporación funciona en todas las sedes. Asigne los teléfonos personales a una VLAN de personal solo con acceso a internet, aislada de los segmentos de pago y administración. Realice la incorporación por regiones para que el servicio de soporte reciba un flujo constante de consultas en lugar de un pico imprevisto.

Fase 5: migrar cada dispositivo que no pueda almacenar un certificado a su propia clave

Asigne a cada dispositivo sin interfaz una clave única y vincule las claves por clase a las VLAN. Los terminales de pago van al segmento de pagos y las cámaras al segmento de cámaras. Registre el dispositivo, la dirección MAC, la sede, la clave y la persona que la introdujo.

Las impresoras y los grabadores de cámaras suelen tener interfaces web que se pueden volver a clavear de forma remota. Las cajas registradoras y los terminales pueden requerir la plataforma de gestión del proveedor o una visita presencial. La guía PPSK for retail store devices: a deployment checklist for tills, scanners and CCTV on Cisco Meraki and Juniper Mist detalla esta fase en profundidad.

¿Cuánto se tarda en desplegar 802.1X en un entorno multisede?

Tome los plazos indicados a continuación como estimaciones de planificación para validar durante la prueba piloto, no como métricas definitivas. Los dispositivos sin interfaz marcan el ritmo, ya que son el único tipo que puede requerir intervención presencial.

Fase	Qué ocurre	Alcance	Duración estimada
0. Preparación	Inventario, grupos de identidad, plan de VLAN, autoridad de certificación	Toda la red, sin cambios en los dispositivos	2 - 3 semanas
1. Creación	SSID seguro y red xPSK en plantillas	Toda la red	1 semana
2. Piloto	Todas las fases de principio a fin	2 - 3 sedes	3 - 4 semanas
3. Dispositivos gestionados	El MDM despliega los certificados y el perfil de WiFi	Todas las sedes a la vez	2 semanas más 2 semanas para casos rezagados
4. Teléfonos personales	Incorporación a través de la red abierta	20 - 30 sedes por oleada	2 semanas por oleada
5. Dispositivos sin interfaz	Clave única por dispositivo	Remoto o visita presencial	Medio día por sede, ejecutado en paralelo
6. Apagado	Eliminar la clave antigua	Por sede	Mínimo 14 días consecutivos sin incidencias por sede

Las fases 3, 4 y 5 se solapan. Teniendo en cuenta estos supuestos, prevea de 10 a 14 semanas para 50 sedes y de 20 a 26 semanas para 200.

Caso práctico: un grupo de 64 hoteles con Cisco Meraki

Cifras ilustrativas. Cada hotel utilizaba unos 40 dispositivos con una única clave compartida para el personal. Esto suponía 22 dispositivos gestionados, seis teléfonos personales y 12 dispositivos headless: terminales de pago, impresoras de recibos y reproductores de señalización. El personal de limpieza de la agencia conocía la clave, por lo que cada rotación de agencia activaba la condición de salida de empleados del requisito PCI-DSS 2.3.2.

El equipo convirtió el SSID heredado a iPSK y mantuvo la contraseña antigua como una sola clave en una VLAN restringida. Crearon el SSID Enterprise en una plantilla de configuración. Intune desplegó los certificados a los 1408 dispositivos gestionados durante la tercera semana posterior al piloto. Los directores de guardia incorporaron 384 teléfonos personales región por región. Los ingenieros reconfiguraron la clave de los 768 dispositivos headless durante las visitas de mantenimiento programadas.

Resultado: en la novena semana, la clave heredada solo daba servicio a dispositivos headless. El último hotel la eliminó en la semana 16, sin necesidad de realizar un corte nocturno. Ahora, la salida de un empleado implica deshabilitar una sola cuenta, en lugar de cambiar la clave de 2560 dispositivos en 64 hoteles.

Caso práctico: una cadena minorista de 180 tiendas con Juniper Mist

Cifras ilustrativas. Cada tienda utilizaba 27 dispositivos con la clave compartida: 12 escáneres portátiles, tres PC de oficina central, cuatro impresoras de etiquetas, seis cámaras y dos teléfonos de encargados. El cambio de clave tras las salidas de empleados se había estancado porque nadie podía llegar a todas las tiendas el mismo día.

Los escáneres y los PC pasaron a EAP-TLS a través del MDM, un total de 2700 dispositivos. Las impresoras y las cámaras pasaron a Multi PSK, con 1800 claves únicas asignadas a dos VLAN. Las tiendas se migraron en seis oleadas de 30. El piloto identificó un formato de tienda cuyos switches no realizaban el enlace troncal (trunk) de la VLAN de cámaras. El equipo corrigió la plantilla antes de la primera oleada.

Resultado: el recuento de dispositivos heredados por tienda llegó a cero en las 180 tiendas para la semana 22. Ya no existe ninguna clave de personal compartida en ninguna parte de la infraestructura.

¿Cómo comprobar que la migración funciona, sede por sede?

Valide cada fase en el piloto

Realice cuatro pruebas en cada sede piloto antes de escalar:

• Prueba de conexión: un nuevo dispositivo gestionado, un teléfono incorporado y una caja registradora con clave modificada se conectan a la primera.
• Prueba de VLAN: cada dispositivo se ubica en el segmento que le corresponde según su identidad o clave.
• Prueba de roaming: un dispositivo portátil mantiene su sesión mientras se desplaza entre puntos de acceso.
• Prueba de salida de empleado: deshabilite una identidad de prueba y revoque su certificado; a continuación, confirme que se rechaza la siguiente autenticación.

Mida el progreso por sede desde el registro de autenticación

Cargue tres datos por sede cada semana, extraídos del registro de autenticación y de la lista de clientes del controlador:

1. Dispositivos autenticados con EAP-TLS en el SSID seguro.
2. Dispositivos con su propia clave xPSK.
3. Dispositivos que aún utilizan la clave heredada.

El progreso equivale a los dos primeros divididos entre el total de dispositivos de personal distintos detectados en los últimos 14 días. Ordene los centros por recuento de dispositivos antiguos y centre el esfuerzo donde el recuento sea mayor. Cuente los teléfonos personales por identidad, no por dirección MAC. iOS y Android aleatorizan las direcciones MAC por red, por lo que un mismo teléfono puede parecer dos.

¿Cuándo se desactiva la contraseña compartida?

Elimine la clave antigua en un centro cuando se cumplan las cuatro condiciones siguientes:

• El recuento de dispositivos antiguos ha sido cero durante 14 días consecutivos, lo que cubre dos ciclos completos de turnos.
• Cada dispositivo sin pantalla ni interfaz del inventario tiene su propia clave.
• Las incidencias del servicio de soporte técnico para ese centro han vuelto al nivel de referencia.
• El responsable del centro ha dado su aprobación.

Registre la fecha. A partir de ese momento, no existirá ninguna clave compartida que la norma 2.3.2 le exija cambiar. El registro de claves y el registro de autenticación se convierten en pruebas de conformidad con el requisito. Si más adelante aparece un dispositivo que se había omitido, asígnele su propia clave. Nunca restaure la clave compartida.

¿Qué suele fallar en un despliegue de 802.1X en múltiples centros y cómo se soluciona?

Los dispositivos vuelven a conectarse al SSID antiguo

Los dispositivos recuerdan ambas redes y pueden preferir la antigua. Elimine la red antigua mediante un perfil MDM una vez que el SSID seguro funcione. En los teléfonos personales, incluya «olvidar la red antigua» en las instrucciones de incorporación.

Los dispositivos se unen sin validar el servidor

Un perfil de WiFi que omite la validación del certificado del servidor confiará en un punto de acceso malicioso que emita el mismo SSID. Vincule la entidad de certificación raíz de confianza y el nombre del servidor RADIUS en cada perfil.

Los clientes se autentican pero no obtienen dirección IP

RADIUS ha asignado una VLAN que el enlace troncal del conmutador no transporta. Audite los enlaces troncales en cada modelo de conmutador durante el piloto y, a continuación, corrija la plantilla, no el centro individual.

Portátiles Windows con fallos en PEAP

Microsoft documenta que Windows Defender Credential Guard bloquea el inicio de sesión único MSCHAPv2 con credenciales guardadas. Migrar esos portátiles a EAP-TLS elimina la dependencia de las contraseñas.

Los certificados caducan en toda la infraestructura a la vez

Los certificados emitidos en una sola distribución caducan en la misma semana. Configure la renovación automática en el MDM mucho antes de la caducidad y escalone el envío inicial si su entidad de certificación lo permite.

Un número excesivo de SSID ralentiza todas las redes

Ejecutar simultáneamente SSID para invitados, antiguos, seguros y xPSK añade una sobrecarga de tramas baliza (beacons) en cada radio. Convierta el SSID antiguo en la red xPSK, tal y como se ha descrito anteriormente, para mantener el recuento total en tres.

¿Cuánto cuesta una migración a 802.1X y qué beneficio se obtiene?

Los costes corresponden a licencias y mano de obra, no a hardware. Se paga por Purple Access, además del trabajo con perfiles MDM, las visitas a los centros para configurar dispositivos sin pantalla ni interfaz y el tiempo del servicio de soporte técnico durante las fases de incorporación. Los puntos de acceso, conmutadores y controladores se mantienen tal como están.

El beneficio radica en lo que se deja de hacer. En el escenario del sector minorista, una sola rotación de la clave compartida en toda la red de centros implicaba volver a introducirla en 4860 dispositivos. Asumiendo unos tres minutos por dispositivo, esto equivale a 243 horas de trabajo del personal por cada rotación. Tras la migración, la baja de un empleado solo requiere desactivar una identidad y cambiar las claves de los dispositivos que esa persona haya configurado.

También obtiene un registro de autenticación que indica qué identidad o clave se unió a qué ubicación y cuándo. Ese registro sirve como prueba para PCI DSS 2.3.2 y para las revisiones de derechos de acceso según el control 5.18 del Anexo A de ISO 27001. Purple cuenta con las certificaciones ISO 27001 y Cyber Essentials y opera con un tiempo de actividad del 99,999 % en más de 80 000 ubicaciones activas. Ese tiempo de actividad es fundamental cuando el servidor RADIUS decide si el personal puede trabajar.

Preguntas frecuentes

¿Necesitamos puntos de acceso nuevos para migrar la red WiFi del personal a 802.1X?

No. 802.1X y las claves por dispositivo funcionan en los puntos de acceso que ya posee. Purple Access es independiente del hardware y funciona como una capa en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Solo tiene que configurar un SSID Enterprise que apunte al servidor RADIUS en la nube de Purple, además de una red de claves por dispositivo utilizando la función propia de su fabricante. la única comprobación física necesaria es que cada enlace de conmutador (trunk) transporte las nuevas VLAN.

¿Podemos mantener el SSID con contraseña compartida y el SSID 802.1X al mismo tiempo?

Sí, y debería hacerlo, ya que mantener ambos es lo que elimina la necesidad de realizar la migración durante un fin de semana. Si su plataforma lo permite, convierta el SSID heredado en la red xPSK. Mantenga la contraseña antigua como una clave en una VLAN restringida para que los dispositivos sigan funcionando mientras los migra. Elimine esa clave en cada ubicación una vez que su registro de autenticación muestre que ningún dispositivo la ha utilizado durante 14 días consecutivos.

¿Qué ocurre con los dispositivos que no admiten 802.1X?

Se trasladan a la red xPSK, cada uno con su propia clave. Las cajas registradoras, terminales de pago, impresoras, cámaras y pantallas de señalización digital raras veces cuentan con un certificado, pero casi todas aceptan una frase de paso WPA2. Cada clave se asigna a una VLAN para su clase de dispositivo, de modo que puede revocar un dispositivo sin afectar a los demás. Mantenga un registro de quién introdujo cada clave, ya que la norma PCI DSS 2.3.2 sigue aplicándose a las claves que conocía una persona que ha dejado la empresa.

¿Cuánto tiempo lleva una migración a 802.1X en múltiples ubicaciones?

Planifique de 10 a 14 semanas para 50 ubicaciones y de 20 a 26 semanas para 200, y luego pruebe esas estimaciones en su proyecto piloto. Los dispositivos gestionados son los que se mueven más rápido porque el MDM aplica la configuración a todas las ubicaciones a la vez. Los dispositivos sin interfaz de usuario (headless) marcan el ritmo, ya que algunos requieren una visita presencial. Cada ubicación necesita al menos 14 días sin incidencias en el registro de autenticación antes de desactivar la contraseña compartida.

¿Hace el protocolo 802.1X que la red WiFi de nuestro personal cumpla con PCI DSS?

Ningún control individual logra eso por sí solo, y la decisión final corresponde a su auditor. EAP-TLS y las claves por dispositivo le proporcionan pruebas para el requisito 2.3.2 de PCI DSS v4.0.1. Una vez que no existe ninguna clave compartida, la marcha de un empleado ya no obliga a cambiar la clave en toda la infraestructura. El registro de autenticación muestra qué identidad o clave se unió a qué ubicación y cuándo, lo que también respalda las revisiones de derechos de acceso según la norma ISO 27001.

¿Deberíamos utilizar PEAP con contraseñas en lugar de certificados?

Utilice EAP-TLS siempre que pueda. PEAP-MSCHAPv2 elimina la clave compartida, pero sigue dependiendo de las contraseñas. Dichas contraseñas se pueden capturar si un dispositivo no valida el certificado del servidor. Microsoft también documenta que Windows Defender Credential Guard bloquea el inicio de sesión único de MSCHAPv2 con credenciales guardadas. Esto interrumpe la conexión WiFi basada en contraseñas en muchos portátiles de Windows gestionados. Los certificados distribuidos mediante su MDM evitan ambos problemas y no requieren ninguna acción por parte del personal.

¿Necesitamos servidores RADIUS locales para 802.1X?

No. Purple Access proporciona RADIUS en la nube, por lo que no hay nada que instalar, parchear ni hacer de nuevo redundante en cada ubicación. Sus puntos de acceso envían solicitudes de autenticación a Purple. Purple comprueba el certificado o la clave, aplica reglas de identidad desde Microsoft Entra ID, Okta o Google Workspace y devuelve la VLAN. Purple opera con un tiempo de actividad del 99,999 % y cuenta con las certificaciones ISO 27001 y Cyber Essentials.

¿Puede el personal utilizar teléfonos personales en el mismo SSID 802.1X?

Sí, siempre que su directiva lo permita. El personal se conecta a la red abierta, inicia sesión en el Captive Portal con su identidad de trabajo y recibe el perfil de red seguro. Un perfil Passpoint conecta después el teléfono automáticamente en cada ubicación de las instalaciones. Asigne los teléfonos personales a una VLAN del personal solo con acceso a Internet, aislada de los segmentos de pago y administración. Pruebe en la fase piloto que su proceso de baja de empleados elimine correctamente su acceso.