Migración del WiFi del personal de una contraseña compartida a 802.1X en una propiedad multisitio

Ejecute un nuevo SSID WPA-Enterprise junto con el SSID de contraseña compartida y migre los dispositivos por etapas. Los dispositivos administrados reciben certificados EAP-TLS desde su MDM. Los teléfonos personales se conectan a través de un Captive Portal. Los dispositivos que no pueden almacenar un certificado obtienen su propia clave en una red xPSK. Desactive la contraseña compartida en cada sitio 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 compartida para el personal es un solo secreto en manos de cada colaborador, cada dispositivo y cada excolaborador. Cuando alguien deja la empresa, la conserva. Cambiarla implica volver a ingresar la clave en cada caja registradora, tableta y laptop en todos los sitios.

El requisito 2.3.2 de PCI-DSS v4.0.1 convierte esto en una obligación. Cubre 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ámbrico cada vez que alguien que las conoce 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 un entorno con alta rotación de personal, una interpretación literal significa cambiar las claves casi todas 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 realiza la consulta a través de RADIUS, el protocolo que utiliza el equipo de red para consultar a un servidor de autenticación.

EAP-TLS (Protocolo de Autenticación Extensible con Seguridad en la Capa de Transporte, RFC 5216) es la forma más segura de responder. El dispositivo y el servidor presentan cada uno un certificado. No hay contraseña para compartir, realizar phishing ni anotar en el pizarrón de la oficina posterior.

La identidad establece entonces la VLAN (LAN virtual, un segmento de red lógicamente separado). RADIUS devuelve una VLAN para cada dispositivo utilizando los atributos de túnel definidos en la RFC 3580. Una laptop de finanzas y una tableta de cocina pueden conectarse al mismo SSID y terminar 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, permite la incorporación de teléfonos personales.
• Secure: EAP-TLS, integración con proveedores de identidad, Passpoint y RADIUS-as-a-Service en la nube. Las laptops, tabletas y teléfonos del personal terminan aquí.
• xPSK: una clave independiente para cada dispositivo, denominada iPSK o PPSK según su proveedor. Todos los dispositivos que no puedan almacenar un certificado terminan aquí.

El WiFi para 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 de DNS en cualquiera de estas redes corresponde a Purple Shield. Para obtener una visión más amplia, consulte nuestra guía principal de WiFi security.

Comparación de modelos de credenciales

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

Modelo de credencial	Lo que presenta cada dispositivo	Lo que se lleva un empleado al salir	Revocar a una persona o dispositivo	Efecto en los cambios de clave PCI DSS 2.3.2	Ideal para
PSK compartida	Una contraseña para todos	La clave de cada sitio	Volver a generar la clave en todos los dispositivos del SSID	Cambiar la clave para todos cada vez que un empleado saliente la conocía	Un solo sitio pequeño sin datos de tarjetas en WiFi
PEAP-MSCHAPv2	Nombre de usuario y contraseña personales	Su propia contraseña hasta que se deshabilite la cuenta	Deshabilitar la cuenta	Sin clave compartida, pero las contraseñas se pueden capturar si no se validan los certificados del servidor	Infraestructuras que aún no tienen una autoridad de certificación
EAP-TLS	Un certificado por dispositivo o persona	Nada útil una vez que se revoca el certificado	Revocar el certificado o deshabilitar la identidad	Sin clave compartida que cambiar	Laptops gestionadas, tabletas, dispositivos portátiles y teléfonos incorporados
xPSK	Una clave única por dispositivo	Solo las claves de los dispositivos que ingresaron personalmente	Eliminar la clave de ese dispositivo	Cambiar solo las claves que manejaba el empleado saliente	Cajas registradoras, terminales de pago, impresoras, CCTV, señalización

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

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

1. Un inventario de dispositivos por sitio. Exporte la lista de clientes para el SSID del personal desde la consola de cada sitio, abarcando al menos 14 días. Clasifique cada dispositivo en una de estas tres categorías. Los dispositivos gestionados están inscritos en su MDM (plataforma de gestión de dispositivos móviles). 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 un almacén de certificados.
2. Un proveedor de identidad con grupos organizados. Utilice Microsoft Entra ID, Okta o Google Workspace. Cada grupo que requiera su propio segmento se convierte en una regla de VLAN. Autenticación WiFi con Okta: pasos de configuración, opciones y soluciones explica detalladamente el proceso en Okta.
3. Una autoridad de certificación a la que su MDM pueda hacer solicitudes. Microsoft Intune, Jamf Pro y la mayoría de los demás 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 y los dispositivos portátiles compartidos requieren certificados de dispositivo.
4. Un plan de VLAN implementado en cada sitio. Un plan típico tiene cinco segmentos: personal, dispositivos corporativos gestionados, dispositivos de pago, otros dispositivos sin interfaz de usuario y un segmento heredado restringido. Confirme que el enlace troncal del conmutador a cada punto de acceso admita cada VLAN.
5. Purple Access configurado como el servidor RADIUS para el SSID seguro. Cuando su proveedor utilice RADIUS para claves por dispositivo, apunte también la red xPSK hacia él. Un RADIUS basado en SaaS significa que no hay nada que instalar, parchar o agrupar en clústeres en los sitios.
6. Un responsable asignado en cada sitio. Necesitas a alguien que pueda identificar los dispositivos desconocidos en el inventario y autorizar la desconexión.

¿Cómo migrar el WiFi del personal a 802.1X sin un fin de semana de transición?

Tres principios eliminan el fin de semana de transición. Construye las nuevas redes junto a la antigua. Mueve los dispositivos por clase, no por sitio. Desconecta sitio por sitio, basándote en la evidencia del registro de autenticación.

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

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

La solución ordenada es convertir el SSID heredado en la red xPSK. Mantén su nombre y modo de seguridad. Agrega la contraseña compartida anterior como una clave dentro de la lista de claves por dispositivo, asignada a la VLAN heredada restringida. Los dispositivos que conocen la contraseña anterior se reconectan sin darse cuenta. Cada dispositivo que mueves obtiene su propia clave.

Cuando la clave heredada ya no tenga dispositivos en un sitio, la eliminas. La contraseña compartida queda deshabilitada y nunca apareció un nuevo SSID. Tu estado final es de tres SSIDs: invitados, personal seguro y xPSK.

Prueba esto primero en un sitio. Varios proveedores ejecutan funciones por clave en WPA2-Personal en lugar de WPA3-SAE, así que consulta la documentación de tu proveedor. Si tu plataforma no puede mantener la contraseña antigua como una sola clave, ejecuta cuatro SSIDs durante la migración y elimina el SSID heredado al momento de la desconexión.

Fase 1: construir una vez y aplicar en toda la propiedad

Configura el SSID seguro y la red xPSK una vez, y luego aplícalos a cada sitio desde una plantilla. Utiliza WPA3-Enterprise donde tu flota administrada lo admita; de lo contrario, usa un modo de transición WPA2/WPA3.

Proveedor	Consola	Configuración de SSID seguro	Función de clave por dispositivo	Aplicar en todos los sitios 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 sedes
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 de sitio por sitio

Las etiquetas cambian entre versiones de firmware, por lo que debes seguir la documentación de tu proveedor para ver la ruta actual. Hay más guías paso a paso de configuración en nuestras Guías de acceso.

Fase 2: prueba piloto en dos o tres sitios representativos

Elige sitios que sean diferentes: uno grande, uno pequeño y uno con un modelo de conmutador inusual. Ejecuta primero cada fase posterior de principio a fin en esos sitios. El piloto existe para encontrar el enlace troncal que no pasa 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 los dispositivos administrados a través del MDM

Los dispositivos gestionados se mueven más rápido porque el MDM llega a todos los sitios a la vez. Implemente tres perfiles en orden: el certificado 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 nombra el SSID seguro, configura EAP-TLS y fija el nombre del certificado del servidor RADIUS y la raíz. Una vez que un dispositivo se ha autenticado en el SSID seguro, envíe un perfil que elimine la red antigua. De lo contrario, el dispositivo puede 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 posterior. Inician sesión en el Captive Portal con su identidad de trabajo y reciben el perfil de red seguro. Nuestra guía fundamental de Captive Portals cubre el diseño de portales.

Un perfil Passpoint (Hotspot 2.0) es lo que más ayuda a una propiedad multisitio. Passpoint permite que un teléfono encuentre y se una a una red por su credencial en lugar de por el nombre del SSID. De esta forma, una sola incorporación funciona en cada sitio. Asigne los teléfonos personales a una VLAN de personal solo con internet, alejada de los segmentos de pago y de la oficina posterior. Ejecute la incorporación por región para que la mesa de ayuda tenga un flujo constante y no un pico de trabajo.

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

Asigne a cada dispositivo headless una clave única y mapee las claves por clase a las VLAN. Las terminales de tarjeta van al segmento de pagos y las cámaras al segmento de cámaras. Registre el dispositivo, la dirección MAC, el sitio, la clave y la persona que la ingresó.

Las impresoras y las grabadoras de cámaras suelen tener interfaces web que se pueden volver a clavear de forma remota. Las cajas registradoras y las terminales pueden necesitar la plataforma de gestión del proveedor o una visita al sitio. La guía PPSK para dispositivos de personal en tiendas minoristas: una lista de verificación de implementación para cajas registradoras, escáneres y CCTV en Cisco Meraki y Juniper Mist cubre esta fase en detalle.

¿Cuánto tiempo lleva un despliegue de 802.1X en varios sitios?

Considere las siguientes duraciones como supuestos de planificación para probar en su piloto, no como referencias definitivas. Los dispositivos headless marcan el ritmo, porque son la única clase que puede requerir asistencia presencial en el sitio.

Fase	Qué sucede	Alcance	Duración estimada
0. Preparar	Inventario, grupos de identidad, plan de VLAN, autoridad de certificación	Toda la propiedad, sin cambios en dispositivos	2 - 3 semanas
1. Construir	SSID seguro y red xPSK en plantillas	Toda la propiedad	1 semana
2. Piloto	Cada fase de principio a fin	2 - 3 sitios	3 - 4 semanas
3. Dispositivos gestionados	El MDM despliega certificados y perfil de WiFi	Todos los sitios a la vez	2 semanas más 2 semanas para rezagados
4. Teléfonos personales	Incorporación a través de la red abierta	20 - 30 sitios por ola	2 semanas por ola
5. Dispositivos headless	Clave única por dispositivo	Remoto o visita al sitio	Medio día por sitio, ejecutado en paralelo
6. Apagado	Eliminar la clave antigua	Por sitio	14 días limpios mínimo por sitio

Las fases 3, 4 y 5 se empalman. Con base en esos supuestos, considere de 10 a 14 semanas para 50 sitios y de 20 a 26 semanas para 200.

Escenario de ejemplo: un grupo de 64 hoteles con Cisco Meraki

Cifras ilustrativas. Cada hotel ejecutaba aproximadamente 40 dispositivos con una sola clave compartida para el personal. Eso significaba 22 dispositivos administrados, seis teléfonos personales y 12 dispositivos sin interfaz de usuario (headless): terminales de pago, impresoras de recibos y reproductores de señalización digital. El personal de limpieza de la agencia conocía la clave, por lo que cada rotación de personal activaba la condición de baja PCI-DSS 2.3.2.

El equipo convirtió el SSID heredado a iPSK y mantuvo la contraseña anterior como una clave en una VLAN restringida. Crearon el SSID Enterprise en una plantilla de configuración. Intune distribuyó los certificados a los 1,408 dispositivos administrados en la tercera semana posterior a la prueba piloto. Los gerentes de turno incorporaron 384 teléfonos personales región por región. Los ingenieros reconfiguraron las claves de los 768 dispositivos sin interfaz durante las visitas de mantenimiento programadas.

Resultado: para la semana nueve, la clave heredada solo soportaba dispositivos sin interfaz. El último hotel la eliminó en la semana 16, sin necesidad de realizar un cambio nocturno drástico. Ahora, la baja de un empleado implica deshabilitar una sola cuenta, en lugar de cambiar la clave de 2,560 dispositivos en 64 hoteles.

Escenario de ejemplo: una cadena minorista de 180 tiendas con Juniper Mist

Cifras ilustrativas. Cada tienda ejecutaba 27 dispositivos con la clave compartida: 12 escáneres portátiles, tres computadoras de oficina central, cuatro impresoras de etiquetas, seis cámaras y dos teléfonos de gerentes. El cambio de claves tras la salida de empleados se había detenido porque nadie podía dar cobertura a todas las tiendas el mismo día.

Los escáneres y las computadoras se migraron a EAP-TLS a través del MDM, dando un total de 2,700 dispositivos. Las impresoras y cámaras se migraron a Multi PSK, con 1,800 claves únicas vinculadas a dos VLAN. Las tiendas se migraron en seis bloques de 30. La prueba piloto detectó un formato de tienda cuyos switches no realizaban el enlace troncal (trunking) para la VLAN de las cámaras. El equipo corrigió la plantilla antes de iniciar el primer bloque.

Resultado: el conteo de claves heredadas por tienda llegó a cero en las 180 sucursales para la semana 22. Ya no existe ninguna clave compartida de personal en toda la red de la empresa.

¿Cómo verificar que la migración funcione, sitio por sitio?

Valide cada fase en la prueba piloto

Realice cuatro pruebas en cada sitio piloto antes de escalar la implementación:

• Prueba de conexión: un dispositivo administrado nuevo, un teléfono incorporado y una caja registradora con clave actualizada se conectan a la primera.
• Prueba de VLAN: cada dispositivo se asigna al segmento que su identidad o clave debe establecer.
• Prueba de roaming: un dispositivo portátil mantiene su sesión activa mientras se desplaza entre puntos de acceso.
• Prueba de bajas de personal: deshabilite una identidad de prueba, revoque su certificado y confirme que se rechace la siguiente autenticación.

Mida el progreso por sitio mediante el registro de autenticación

Reporte tres métricas por sitio cada semana, basadas en el registro de autenticación y la lista de clientes del controlador:

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

El progreso se calcula dividiendo los primeros dos entre todos los dispositivos del personal distintos detectados en los últimos 14 días. Ordene los sitios según el conteo heredado y dirija los esfuerzos donde el conteo sea mayor. Cuente los teléfonos personales por identidad y no por dirección MAC. iOS y Android aleatorizan las direcciones MAC por red, por lo que un solo teléfono puede parecer dos.

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

Elimine la clave heredada en un sitio cuando se cumplan las cuatro condiciones siguientes:

• El conteo heredado ha sido cero durante 14 días consecutivos, lo que cubre dos ciclos completos de turnos.
• Cada dispositivo headless del inventario tiene su propia clave.
• Los tickets de soporte técnico para ese sitio han vuelto a los niveles habituales.
• El responsable del sitio ha dado su aprobación.

Registre la fecha. A partir de ese momento, no existirá ninguna clave compartida para que la norma 2.3.2 le exija cambiarla. Su registro de claves y el registro de autenticación se convierten en evidencia del cumplimiento del requisito. Si más adelante aparece un dispositivo que se había pasado por alto, asígnele su propia clave. Nunca restaure la clave compartida.

¿Qué problemas surgen en una implementación de 802.1X multisitio y cómo se resuelven?

Los dispositivos vuelven a conectarse al SSID heredado

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

Los dispositivos se conectan sin validar el servidor

Un perfil de WiFi que omite la validación del certificado del servidor confiará en un punto de acceso no autorizado que transmita el mismo SSID. Fije la raíz de confianza y el nombre del servidor RADIUS en cada perfil.

Los clientes se autentican pero no obtienen una dirección IP

RADIUS asignó una VLAN que el enlace troncal del switch no transporta. Audite los enlaces troncales en cada modelo de switch en la prueba piloto y corrija la plantilla, no el sitio individual.

Las computadoras portátiles con Windows fallan en PEAP

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

Los certificados vencen en toda la red al mismo tiempo

Los certificados emitidos en un solo despliegue vencen en la misma semana. Configure la renovación automática en el MDM con suficiente antelación a la fecha de vencimiento y escalone el despliegue inicial si su autoridad de certificación lo permite.

El exceso de SSIDs ralentiza todas las redes

Mantener activos los SSIDs de invitados, heredados, seguros y xPSK al mismo tiempo añade una sobrecarga de señalización en cada radio. Convierta el SSID heredado en la red xPSK, como se describió anteriormente, para mantener el conteo total en tres.

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

Los costos se centran en las licencias y la mano de obra, no en el hardware. Usted paga por Purple Access, además del trabajo de perfiles de MDM, las visitas a los sitios para dispositivos headless y el tiempo de soporte técnico durante las olas de integración. Los puntos de acceso, switches y controladores se mantienen tal como están.

El beneficio se refleja en las tareas que deja de realizar. En el escenario del sector minorista, una sola rotación de la clave compartida en toda la empresa implicaba volver a ingresarla en 4,860 dispositivos. Asumiendo un promedio de tres minutos por dispositivo, esto equivale a 243 horas de trabajo del personal por cada rotación. Después de 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 muestra qué identidad o clave se unió a qué sitio y cuándo. Ese registro sirve como evidencia para PCI DSS 2.3.2 y para revisiones de derechos de acceso bajo 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 en vivo. Ese tiempo de actividad es fundamental cuando RADIUS decide si el personal puede trabajar.

Preguntas frecuentes

¿Necesitamos nuevos puntos de acceso para migrar el 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 superposición en la nube en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Solo debe configurar un SSID Enterprise que apunte al RADIUS en la nube de Purple, además de una red de claves por dispositivo utilizando la función propia de su proveedor. La única verificación física es que cada enlace troncal del switch transporte las nuevas VLAN.

¿Podemos ejecutar el SSID de contraseña compartida y el SSID 802.1X al mismo tiempo?

Sí, y debería hacerlo, porque ejecutar ambos es lo que elimina la necesidad de un fin de semana de transición drástica. Siempre que su plataforma lo permita, convierta el SSID heredado en la red xPSK. Mantenga la contraseña anterior como una clave en una VLAN restringida para que los dispositivos sigan funcionando mientras los migra. Elimine esa clave en cada sitio una vez que su registro de autenticación muestre que ningún dispositivo la ha utilizado durante 14 días consecutivos.

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

Se migran a la red xPSK, cada uno con su propia clave. Es raro que las cajas registradoras, terminales de pago, impresoras, cámaras y pantallas de señalización cuenten con un certificado, pero casi todas aceptan una frase de contraseña WPA2. Cada clave se asigna a una VLAN para su clase de dispositivo, por lo que puede revocar un dispositivo sin afectar a los demás. Mantenga un registro de quién ingresó cada clave, ya que PCI DSS 2.3.2 aún se aplica a las claves que conocía una persona que dejó la empresa.

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

Calcule de 10 a 14 semanas para 50 sitios y de 20 a 26 semanas para 200, luego ponga a prueba esos cálculos en su prueba piloto. Los dispositivos gestionados se mueven más rápido porque el MDM se despliega en todos los sitios a la vez. Los dispositivos sin interfaz de usuario marcan el ritmo, ya que algunos requieren una visita física al sitio. Cada sitio necesita al menos 14 días limpios en el registro de autenticación antes de desactivar la contraseña compartida.

¿802.1X hace que nuestro WiFi para el personal cumpla con PCI DSS?

Ningún control individual logra eso por sí solo, y su evaluador es quien emite el juicio. EAP-TLS y las claves por dispositivo le brindan evidencia para el requisito 2.3.2 de PCI DSS v4.0.1. Una vez que no existe una clave compartida, la salida 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é sitio y cuándo, lo que también respalda las revisiones de derechos de acceso bajo ISO 27001.

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

Use EAP-TLS siempre que sea posible. PEAP-MSCHAPv2 elimina la clave compartida, pero aún depende de contraseñas. Esas contraseñas pueden ser capturadas 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. Eso interrumpe el WiFi basado en contraseñas en muchas laptops administradas con Windows. Los certificados enviados por su MDM evitan ambos problemas y no requieren ninguna acción por parte del personal.

¿Necesitamos servidores RADIUS localmente para 802.1X?

No. Purple Access proporciona RADIUS-as-a-Service en la nube, por lo que no hay nada que instalar, parchear o hacer resistente en cada sitio. Sus puntos de acceso envían solicitudes de autenticación a Purple. Purple verifica 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.

¿El personal puede usar teléfonos personales en la misma SSID 802.1X?

Sí, si su política lo permite. 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 luego conecta el teléfono automáticamente en cada sitio de la propiedad. Mapee los teléfonos personales a una VLAN de personal solo para internet, alejada de los segmentos de pago y de administración. Pruebe en la fase piloto que su proceso de baja de personal elimine su acceso.