Saltar al contenido principal
Español

EAP-TLS frente a PEAP: ¿Qué protocolo de autenticación es el adecuado para su red?

Decida qué método 802.1X debe utilizar cada grupo de dispositivos de su red: EAP-TLS para dispositivos corporativos que pueda inscribir, PEAP con validación de certificado de servidor bloqueada para dispositivos personales y de contratistas, y un Captive Portal o OpenRoaming para invitados. También puede planificar una migración que ejecute ambos métodos en un solo servicio RADIUS sin tiempo de inactividad.

Por Iain JewittPublicado Actualizado
📖 14 min de lectura3,899 palabras3 ejemplos prácticos3 preguntas de práctica12 definiciones clave

Video overview

Escuchar esta guía

Ver transcripción del podcast
EAP-TLS vs PEAP: ¿Qué protocolo de autenticación es el adecuado para su red? Una sesión informativa técnica de Purple [INTRODUCCIÓN - aproximadamente 1 minuto] Le damos la bienvenida a la sesión informativa técnica de Purple. Soy su anfitrión, y hoy vamos a analizar una de las decisiones más trascendentales que tomará al diseñar o actualizar la infraestructura inalámbrica de su empresa: la elección entre EAP-TLS y PEAP para su marco de autenticación 802.1X. Si es usted un responsable de TI, arquitecto de red o CTO a cargo de un grupo hotelero, un complejo comercial, un estadio o una organización del sector público, esta decisión afecta a su postura de seguridad, su nivel de cumplimiento y la carga de trabajo operativo diario que soporta su equipo. Así que vayamos directos al grano. Tanto EAP-TLS como PEAP son métodos de autenticación 802.1X. Ambos dependen de un servidor RADIUS para gestionar las solicitudes de autenticación y ofrecen una seguridad significativamente mayor que una contraseña WPA2 compartida. Pero la forma en que verifican la identidad es fundamentalmente diferente, y esa diferencia tiene importantes implicaciones para la forma en que despliega, gestiona y escala su red. [ANÁLISIS TÉCNICO DETALLADO - aproximadamente 5 minutos] Empecemos con EAP-TLS: Extensible Authentication Protocol Transport Layer Security. EAP-TLS es el estándar de oro de la autenticación de WiFi corporativa. Su característica definitoria es la autenticación mutua por certificado. Lo que esto significa en la práctica es lo siguiente: cuando un dispositivo intenta conectarse a su red, el servidor RADIUS presenta un certificado digital al dispositivo. El dispositivo comprueba ese certificado con sus Autoridades de Certificación de confianza. Pero aquí está la diferencia crítica con PEAP: a continuación, el dispositivo presenta su propio certificado al servidor. El servidor valida ese certificado de cliente y, solo si ambos certificados son válidos y de confianza, la red concede el acceso. No hay contraseñas implicadas. Ninguna. La autenticación se basa totalmente en certificados. Esto hace que EAP-TLS sea extraordinariamente resistente al robo de credenciales, a los ataques de diccionario y a los ataques de Man-in-the-Middle. Sencillamente, no se puede robar una contraseña que no existe en el flujo de autenticación. Ahora bien, la contrapartida es la complejidad del despliegue. Para ejecutar EAP-TLS a escala, se necesita una infraestructura de clave pública (PKI) para emitir, gestionar y revocar certificados para cada uno de los dispositivos de la red. También se necesita una solución de gestión de dispositivos móviles para enviar esos certificados de forma silenciosa a los terminales. Si gestiona un entorno corporativo con Microsoft Intune o Jamf, esto es totalmente viable. Si no es así, EAP-TLS se convierte en una tarea de gran envergadura. La otra consideración operativa es la gestión del ciclo de vida de los certificados. Los certificados caducan. Si el certificado de su servidor RADIUS caduca, todos los dispositivos de su red fallarán en la autenticación simultáneamente. Eso supone una interrupción catastrófica. Los procesos de supervisión y renovación de certificados son innegociables. Ahora examinemos PEAP: Protected Extensible Authentication Protocol. PEAP se diseñó para abordar la complejidad de implementación de EAP-TLS ofreciendo al mismo tiempo una seguridad robusta. La clave fundamental de PEAP es esta: solo se necesita que el servidor tenga un certificado. El cliente no necesita ninguno. Así es como funciona. El servidor RADIUS presenta su certificado al dispositivo cliente. El cliente valida al servidor - al igual que en EAP-TLS. Esto establece un túnel TLS cifrado. Dentro de ese túnel, el cliente realiza una autenticación estándar basada en contraseña, normalmente utilizando MSCHAPv2, contra su almacén de identidades - ya sea Active Directory, LDAP, Google Workspace o lo que sea que esté utilizando. La contraseña nunca viaja en texto plano. Siempre está protegida dentro del túnel cifrado. Por lo tanto, PEAP es verdaderamente seguro - siempre que esté configurado correctamente. Y ahí es donde tenemos que hablar sobre la configuración incorrecta más común y peligrosa en las implementaciones de PEAP. Si un dispositivo cliente no está configurado para validar estrictamente el certificado del servidor RADIUS, un atacante puede configurar un punto de acceso falso con el mismo nombre de red, presentar un certificado fraudulento y el dispositivo se conectará sin problemas. El atacante captura entonces el intercambio de autenticación MSCHAPv2, que puede ser descifrado sin conexión. Esto no es un ataque teórico - es una técnica bien documentada utilizada en pruebas de penetración reales. La solución es sencilla: utilice políticas de grupo (GPO), perfiles MDM o herramientas de incorporación para aplicar una validación estricta del certificado del servidor en cada dispositivo cliente. Pero la realidad operativa es que, en entornos BYOD, garantizar que esta configuración se aplique de forma coherente en miles de dispositivos personales no gestionados es verdaderamente difícil. Permítame ofrecerle una comparación concreta. Piense en una cadena de tiendas con 500 ubicaciones. Disponen de tabletas y escáneres portátiles propiedad de la empresa, todos gestionados a través de Microsoft Intune. EAP-TLS es la opción correcta. Intune distribuye los certificados automáticamente. Si se pierde un escáner, el departamento de TI revoca su certificado y queda fuera de la red en cuestión de minutos - sin restablecimiento de contraseñas ni cambios de contraseñas compartidas en 500 tiendas. La seguridad es absoluta. Piense ahora en un gran centro de conferencias que ofrece WiFi para 3.000 miembros del personal en sus dispositivos personales. Sin MDM. El personal utiliza Google Workspace. PEAP integrado con Google Secure LDAP es la opción pragmática. El personal se autentica con sus credenciales estándar. El equipo de TI proporciona documentación de incorporación para configurar la validación de certificados. Se puede implementar en días, no en meses. La arquitectura que sustenta ambos protocolos es el mismo modelo 802.1X de tres componentes: el suplicante - que es el dispositivo cliente -, el autenticador, que es su punto de acceso o switch, y el servidor RADIUS. El autenticador actúa como un guardián, bloqueando todo el tráfico hasta que el servidor RADIUS indica que la autenticación se ha realizado correctamente. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Entonces, ¿cuáles son las recomendaciones prácticas? Primero: si dispone de una solución MDM y de dispositivos propiedad de la empresa, implemente EAP-TLS. La inversión inicial en PKI y gestión de certificados da sus frutos al reducir el riesgo y simplificar las auditorías de cumplimiento. Para entornos regulados - sector sanitario, financiero, público - esto no es opcional. Es la arquitectura que sus auditores esperan ver. Segundo: si gestiona un entorno BYOD o no dispone de infraestructura de MDM, implemente PEAP. Pero no se salte la configuración de validación del certificado del servidor. Utilice herramientas de incorporación, portales de control de acceso a la red o perfiles de MDM siempre que sea posible para exigir esto. Trátelo como un paso de despliegue obligatorio, no como una medida de refuerzo opcional. Tercero: independientemente del protocolo que elija, incorpore redundancia de RADIUS en su arquitectura. La autenticación es un proceso crítico. El fallo de un único servidor RADIUS significa que nadie puede acceder a la red. Las soluciones de RADIUS alojadas en la nube pueden proporcionar resiliencia sin los costes fijos de gestionar una infraestructura local redundante. Cuarto: segmente su red tras la autenticación. Una autenticación de 802.1X correcta no debería conceder acceso sin restricciones a toda su red corporativa. Utilice políticas de asignación de VLAN para ubicar a los usuarios en los segmentos de red adecuados con los controles de acceso correspondientes. Los errores comunes que deben evitarse: la expiración de certificados que causa fallos de autenticación masivos en despliegues EAP-TLS; los dispositivos cliente que no validan los certificados del servidor en despliegues PEAP; y los problemas de tiempo de espera de RADIUS causados por una alta latencia entre el controlador inalámbrico y el servidor de autenticación - especialmente relevante en entornos distribuidos geográficamente. [PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto] Permítame repasar algunas preguntas que escucho con frecuencia. ¿Puedo ejecutar tanto EAP-TLS como PEAP en la misma red? Sí. Muchas organizaciones ejecutan EAP-TLS para dispositivos corporativos en un SSID y PEAP para BYOD o acceso de invitados en un SSID independiente, con la segmentación de red adecuada entre ellos. ¿Modifica WPA3 esta decisión? WPA3 Enterprise exige el modo de seguridad de 192 bits para despliegues de alta seguridad, lo que se alinea con EAP-TLS. WPA3 Personal utiliza SAE en lugar de PSK, pero para los despliegues empresariales de 802.1X, la selección del método EAP sigue siendo relevante. ¿Cumple PEAP con PCI-DSS? Sí, cuando se configura correctamente exigiendo la validación del certificado del servidor. Sin embargo, para los entornos que gestionan datos de titulares de tarjetas, EAP-TLS es cada vez más el enfoque recomendado en las evaluaciones de seguridad. ¿Qué ocurre con OpenRoaming? OpenRoaming utiliza autenticación basada en certificados de forma interna, alineándose con los principios de EAP-TLS. Las plataformas como Purple pueden actuar como proveedor de identidad para OpenRoaming, lo que permite un roaming seguro y fluido entre ubicaciones sin necesidad de volver a autenticarse. [RESUMEN Y PASOS SIGUIENTES - aproximadamente 1 minuto] En resumen: EAP-TLS es la opción de mayor seguridad, ya que elimina por completo las contraseñas mediante la autenticación mutua por certificados. Requiere una infraestructura PKI y MDM, pero ofrece el nivel de cumplimiento más sólido y el control de acceso más detallado a nivel de dispositivo. PEAP es la opción pragmática para BYOD y entornos sin infraestructura de gestión de certificados, ya que proporciona una autenticación cifrada sólida utilizando las credenciales existentes, pero solo si la validación del certificado del servidor se aplica de forma rigurosa. El marco de decisión es sencillo: si gestiona sus dispositivos, utilice EAP-TLS. Si sus usuarios traen sus propios dispositivos, utilice PEAP - pero configúrelo correctamente. Para sus próximos pasos: audite su configuración de autenticación actual, evalúe su preparación para PKI y MDM, y revise su infraestructura RADIUS en busca de redundancia y latencia. Si está desplegando o actualizando el WiFi para invitados junto con su red corporativa, considere cómo una plataforma como Purple puede integrarse con su marco de autenticación para proporcionar tanto seguridad como análisis prácticos a partir de su red. Gracias por escuchar el Purple Technical Briefing. Hasta la próxima.

Parte de nuestra serie principal: Guía de seguridad WiFi para empresas →

Elija EAP-TLS cuando controle los dispositivos. Cada dispositivo demuestra su identidad con un certificado, por lo que no hay contraseña que se pueda pescar mediante phishing ni descifrar. Elija PEAP cuando no pueda emitir certificados, como en los dispositivos personales, y exija la validación del certificado del servidor en cada cliente. Ninguno de los dos se adapta a los invitados anónimos, por lo que se recomienda utilizar un Captive Portal o OpenRoaming en su lugar.

¿Debería elegir EAP-TLS o PEAP?

Ambos protocolos se ejecutan dentro de IEEE 802.1X, el estándar para el control de acceso a redes basado en puertos. 802.1X hace que un dispositivo demuestre quién es antes de que el punto de acceso reenvíe su tráfico. Esa prueba viaja como mensajes EAP (Extensible Authentication Protocol) a un servidor RADIUS, el servicio que aprueba o rechaza cada conexión.

EAP-TLS y PEAP son dos formas de transportar esa prueba. La diferencia radica en lo que presenta el dispositivo.

  • EAP-TLS está definido en la norma RFC 5216 y actualizado para TLS 1.3 en la norma RFC 9190. El servidor y el dispositivo presentan cada uno un certificado digital. La identidad se basa en una clave privada que nunca sale del dispositivo.
  • PEAP (Protected EAP) solo pide un certificado al servidor. El dispositivo crea un túnel cifrado hacia el servidor y luego envía un nombre de usuario y una contraseña en su interior, casi siempre con MSCHAPv2.

La recomendación rápida:

  • Portátiles, tabletas, escáneres y dispositivos de pago gestionados: EAP-TLS.
  • Teléfonos personales y dispositivos de contratistas que no pueda inscribir: PEAP, con la validación del certificado del servidor activada de forma obligatoria.
  • Invitados, aficionados, pasajeros y compradores: ninguno de los dos. Utilice un Captive Portal o OpenRoaming a través de Guest WiFi.

La mayoría de las instalaciones ejecutan ambos métodos en un solo servicio RADIUS, separados por la propiedad del dispositivo. El resto de esta guía muestra dónde se sitúa esa línea y cuánto cuesta ejecutar cada opción.

¿En qué se diferencian EAP-TLS y PEAP en la práctica?

Cómo funciona la negociación EAP-TLS

El servidor RADIUS envía su certificado en primer lugar. El dispositivo lo comprueba con una autoridad de certificación (CA) raíz de confianza. A continuación, el dispositivo envía su propio certificado y demuestra que posee la clave privada correspondiente.

El servidor confirma que el certificado del dispositivo es válido y no ha sido revocado. Comprueba la revocación con una lista de revocación de certificados (CRL) o mediante OCSP (Online Certificate Status Protocol, RFC 6960). Solo entonces el punto de acceso admite el dispositivo.

Ninguna contraseña cruza la red en ningún momento. Una contraseña obtenida por phishing no puede abrir la red, porque la red nunca pide ninguna.

Cómo funciona la negociación PEAP

El servidor RADIUS envía su certificado y el dispositivo lo valida. Las dos partes crean un túnel TLS. Dentro de ese túnel, el dispositivo ejecuta MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol versión 2) contra un directorio como Active Directory. Si las credenciales coinciden, el dispositivo obtiene acceso.

Microsoft, Cisco y RSA Security desarrollaron PEAP conjuntamente. Nunca se convirtió en un estándar de la IETF. Microsoft publica la versión que utilizan la mayoría de los dispositivos en su especificación de protocolo MS-PEAP.

Por qué la validación del certificado del servidor determina la seguridad de PEAP

El túnel protege la contraseña solo si el dispositivo comprueba quién está al otro lado. Si se omite esa comprobación, un atacante puede transmitir el nombre de su red desde un punto de acceso no autorizado, conocido como "evil twin". A continuación, el dispositivo completa MSCHAPv2 con el atacante y le entrega el reto y la respuesta.

En 2012, la advertencia de seguridad de Microsoft 2743314 avisó de que los intercambios MSCHAPv2 no encapsulados se pueden descifrar. La mitigación de Microsoft consistió en envolverlos en PEAP exigiendo la validación del certificado del servidor. Esa sigue siendo la regla hoy en día.

EAP-TLS no comparte esta debilidad. Un dispositivo que se conecta a un punto de acceso no autorizado no tiene ninguna contraseña reutilizable que entregar.

EAP-TLS frente a PEAP frente a frente

EAP-TLS PEAP (MSCHAPv2)
Lo que presenta el dispositivo Su propio certificado y clave privada Nombre de usuario y contraseña dentro de un túnel TLS
Certificados requeridos Servidor y cada dispositivo cliente Solo servidor
Especificación definitoria IETF RFC 5216 y RFC 9190 Especificación Microsoft MS-PEAP
Exposición a contraseñas robadas por phishing o reutilizadas Ninguna - no existe contraseña Total - la contraseña es la credencial
Exposición a evil twin Baja - no hay secreto reutilizable que capturar Alta si la validación del servidor está desactivada
Modo WPA3-Enterprise de 192 bits Compatible No compatible
Windows Credential Guard No le afecta Bloquea las credenciales MSCHAPv2 guardadas
Infraestructura necesaria RADIUS, PKI, MDM o herramienta de incorporación RADIUS, certificado de servidor, directorio
Revocar un dispositivo perdido Revocar ese certificado individual Restablecer la cuenta, afectando a todos los dispositivos de esa persona
Efecto del cambio de contraseña Ninguno Es necesario actualizar cada perfil de WiFi guardado
Mejor uso Flotas corporativas, dispositivos de pago y clínicos Dispositivos personales, contratistas, entornos sin PKI

Dos cambios de plataforma que decantan la decisión

Windows. La documentación de Microsoft Credential Guard indica que las conexiones WiFi y VPN basadas en MSCHAPv2 no pueden utilizar credenciales guardadas cuando Credential Guard está activo. Credential Guard está habilitado por defecto en los dispositivos Windows 11 Enterprise y Education elegibles a partir de la versión 22H2. Microsoft recomienda migrar a métodos basados en certificados como EAP-TLS.

Android. Las versiones recientes de Android eliminaron la opción de omitir la validación del certificado del servidor. Los perfiles PEAP ahora deben nombrar un certificado CA y un dominio de servidor. Esto cierra la brecha del evil twin, pero dificulta la configuración manual para el personal.

¿Cuándo es EAP-TLS la opción correcta?

Elija EAP-TLS cuando se cumplan tres condiciones: los dispositivos son de su propiedad, puede distribuir la configuración en ellos y una contraseña comprometida causaría un daño real.

  • Portátiles de empresa gestionados a través de una plataforma MDM (gestión de dispositivos móviles) como Microsoft Intune.
  • Terminales de punto de venta y escáneres portátiles en redes dentro del alcance de PCI-DSS.
  • Tabletas y carros clínicos en el sector sanitario, donde una contraseña compartida en planta supone un riesgo permanente.
  • Dispositivos de administración, recepción y limpieza en hoteles.
  • Redes creadas para el modo WPA3-Enterprise de 192 bits, que la especificación WPA3 vincula a los conjuntos de cifrado EAP-TLS.

Los certificados también permiten que la cancelación de accesos sea precisa. Al revocar un certificado, un dispositivo pierde el acceso, mientras que los demás dispositivos de esa persona siguen funcionando. Esto se adapta a la perfección a las incorporaciones, cambios de puesto y salidas en su MDM y directorio.

Almacene las claves privadas como no exportables en el TPM (Trusted Platform Module) del dispositivo o en un enclave seguro siempre que el hardware lo admita. Un certificado que no se pueda copiar fuera del dispositivo no se podrá reutilizar en ningún otro lugar.

Caso práctico: un grupo hotelero con 30 establecimientos

Los casos prácticos de esta guía son combinaciones de implementaciones habituales y no representan resultados de clientes con nombres reales.

Situación. Un grupo hotelero gestiona 30 establecimientos de unas 200 habitaciones cada uno. Los portátiles de administración, las tabletas del personal de limpieza y los PC de recepción comparten una misma red WiFi para empleados. Los dispositivos inician sesión con PEAP utilizando un grupo reducido de cuentas compartidas de Active Directory. Cuando se pierde una tableta, el equipo de TI restablece la contraseña compartida y vuelve a configurar cada uno de los dispositivos que la utilizan.

Qué se hizo. Todos los dispositivos ya estaban inscritos en un MDM. El equipo implementó una PKI en la nube (infraestructura de clave pública, el sistema que emite y revoca certificados). Enviaron los certificados de los dispositivos mediante SCEP (Simple Certificate Enrollment Protocol, RFC 8894). A continuación, el perfil de WiFi de empleados cambió a EAP-TLS. PEAP permaneció activo en el mismo servicio RADIUS durante toda la transición. La asignación dinámica de VLAN ubicó las tabletas de limpieza en un segmento distinto al de los portátiles de finanzas.

Resultado. Las cuentas compartidas de WiFi se redujeron a cero. Perder una tableta ahora implica revocar un solo certificado en lugar de restablecer la contraseña en docenas de dispositivos. La rotación de contraseñas ya no interrumpe la conexión WiFi, porque ya no existe ninguna contraseña de WiFi. Encontrará más información sobre redes para el sector hostelero en nuestra página de Hoteles.

¿Cuándo es PEAP la opción adecuada?

Elija PEAP cuando no pueda instalar un certificado en el dispositivo y la persona que inicia sesión disponga de una cuenta de directorio.

  • Personal que utiliza teléfonos personales bajo una directiva BYOD (trae tu propio dispositivo), donde la inscripción en el MDM no resulta aceptable.
  • Contratistas, personal temporal de eventos y trabajadores de agencias con cuentas de corta duración.
  • Instalaciones con Active Directory pero sin PKI, como paso intermedio hacia EAP-TLS.

PEAP solo resulta aceptable para estos casos si se aplican tres controles.

  1. Bloquee la validación del certificado del servidor en cada dispositivo. Indique la CA de confianza y el nombre exacto del servidor. Despliéguelo mediante una directiva de grupo, un perfil de MDM o una herramienta de incorporación, nunca de forma manual.
  2. Mantenga predecible el certificado del servidor. Emítalo desde una CA en la que sus dispositivos ya confíen y mantenga estable el nombre del servidor en las renovaciones.
  3. Refuerce la contraseña del directorio. PEAP es tan seguro como lo sea la contraseña dentro del túnel. Obligue a usar una longitud adecuada y bloquee en el directorio las contraseñas que se sepan comprometidas.

Caso práctico: un centro de conferencias con personal de temporada

Situación. Un centro de conferencias y eventos en el centro de la ciudad contrata a unos 300 empleados temporales en cada temporada alta. Utilizan sus propios teléfonos para las aplicaciones de turnos y radio. El centro no puede exigirles que registren sus teléfonos personales en un MDM. Hasta entonces, una contraseña compartida de WPA2-Personal estaba colgada en el tablón de anuncios de la sala de personal.

Qué se hizo. El departamento de TI creó una cuenta de directorio con fecha de finalización para cada trabajador temporal. La WiFi del personal se migró a PEAP. Un perfil de incorporación de un solo uso fijó la CA y el nombre del servidor en cada teléfono. Las cuentas se desactivan automáticamente en la fecha de fin de contrato. Los asistentes se mantuvieron en una red independiente con Captive Portal.

Resultado. Se retiró la contraseña compartida. Las personas que dejan la empresa pierden el acceso en su fecha de finalización, no en el siguiente cambio de contraseña. Cada conexión del personal se asocia a una cuenta con nombre en los registros RADIUS, que el equipo de seguridad puede auditar tras cada evento.

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.

¿Cuánto cuesta ejecutar EAP-TLS y PEAP?

Ninguno de los dos protocolos implica el pago de licencias. Ambos están integrados en Windows, macOS, iOS, Android y ChromeOS. El coste reside en la infraestructura y en el tiempo del personal.

Concepto de coste EAP-TLS PEAP
Servicio RADIUS Necesario Necesario
Certificado del servidor RADIUS Necesario, renovado según el calendario de la CA Necesario, renovado según el calendario de la CA
PKI para emitir certificados de cliente Necesario, local o en la nube No necesario
MDM o herramienta de incorporación Necesario más allá de una fase piloto Recomendado, para forzar la validación del servidor
Renovaciones de certificados de cliente En cada dispositivo, según el calendario que defina Ninguna
Tiques por contraseñas de WiFi Ninguno Bloqueos y actualizaciones de perfil tras cada cambio
Pruebas de auditoría para acceso inalámbrico Registros de emisión y revocación de certificados Registros de cuentas y directivas de contraseñas

En qué se gasta con EAP-TLS

EAP-TLS requiere una inversión inicial. Se paga por una PKI y por el tiempo del personal para diseñar las plantillas de certificados, el registro y la revocación. Si ya utiliza un MDM, gran parte del coste de implantación queda cubierto. Tras el lanzamiento, la principal tarea recurrente es la renovación de certificados, la cual se automatiza mediante el MDM.

En qué se gasta con PEAP

PEAP empieza siendo económico, pero sus costes aumentan con el tiempo. Cada cambio de contraseña puede dejar credenciales obsoletas en teléfonos y portátiles. Los intentos fallidos repetidos pueden bloquear la cuenta en Active Directory, lo que genera un tique en el servicio de soporte. Dichos costes aumentan en función del número de empleados y de la frecuencia de rotación de contraseñas.

Tenga en cuenta la vida útil del certificado del servidor

Si el certificado de su servidor RADIUS procede de una CA pública, su periodo de validez es cada vez más corto. La votación Ballot SC-081 del CA/Browser Forum reduce progresivamente la validez máxima de los certificados TLS públicos. El límite bajará a 200 días a partir de marzo de 2026 y a 47 días a partir de marzo de 2029. Por ello, muchos equipos emiten el certificado RADIUS desde una CA privada, lo que les permite gestionar las renovaciones según sus propios plazos.

El coste de cometer errores

El informe Cost of a Data Breach Report 2024 de IBM situó el coste medio global de una brecha en 4,88 millones de USD. Las credenciales robadas o comprometidas estuvieron entre los vectores de ataque iniciales más comunes en dicho informe. EAP-TLS elimina las contraseñas WiFi de la superficie de ataque para cada dispositivo que cubre.

Escenario práctico: una cadena minorista con 120 tiendas

Situación. Una cadena minorista gestiona 120 tiendas con escáneres portátiles y dispositivos de punto de venta móviles que utilizan PEAP. Los dispositivos comparten una cuenta de servicio. Cada rotación programada de esa cuenta provocaba fallos de autenticación nocturnos en las tiendas donde los dispositivos mantenían la contraseña antigua.

Qué se hizo. El equipo de TI migró los escáneres y los dispositivos de pago a EAP-TLS utilizando el MDM que ya utilizaba. Cada dispositivo recibió su propio certificado. Los teléfonos del personal de la tienda se mantuvieron en PEAP, en una VLAN independiente sin ruta hacia el entorno de datos de los titulares de tarjetas.

Resultado. Las interrupciones en el día de rotación desaparecieron, ya que los dispositivos dentro del alcance dejaron de depender de una contraseña compartida. La revocación pasó a ser por dispositivo en lugar de por tienda. Las comprobaciones trimestrales de puntos de acceso no autorizados según el requisito 11.2.1 de PCI DSS continuaron sin cambios. Consulte nuestra página de Retail para obtener más información sobre redes en tiendas.

¿Qué interrumpe cada protocolo y cómo prevenirlo?

Certificados caducados

Si el certificado de la CA o el certificado del servidor RADIUS caduca, todas las autenticaciones fallan a la vez. Esto afecta por igual a EAP-TLS y PEAP. Configure alertas a los 90, 30 y siete días antes de cada fecha de caducidad, y asigne un responsable para cada certificado.

Validación de servidor desactivada

Un perfil PEAP que omite la validación del servidor entrega las credenciales a cualquier gemelo malicioso. Audite los perfiles de los dispositivos con frecuencia y añada esta comprobación a su revisión de seguridad. Elimine cualquier instrucción de configuración manual que indique al personal tocar en "No validar".

Latencia de RADIUS y puntos únicos de fallo

La autenticación se encuentra en la ruta crítica. Una latencia alta entre el controlador, el servidor RADIUS y el directorio provoca tiempos de espera agotados en EAP. Ejecute RADIUS con redundancia o utilice cloud RADIUS con más de una región. Para entornos distribuidos, como estaciones y material rodante en Trains, ubique un proxy RADIUS local cerca de los puntos de acceso.

Puntos de acceso no autorizados

Utilice la detección de intrusiones inalámbricas integrada en la plataforma de sus puntos de acceso para identificar dispositivos no autorizados de forma continua. Si acepta pagos con tarjeta, el requisito 11.2.1 de PCI DSS exige probar la presencia de puntos de acceso no autorizados al menos cada tres meses.

Una red plana tras la autenticación

Un inicio de sesión 802.1X correcto no debería abrir toda la red. Utilice la asignación dinámica de VLAN, donde RADIUS devuelve la VLAN (LAN virtual) para cada dispositivo mediante los atributos definidos en la norma RFC 3580. Los dispositivos de pago, los teléfonos del personal y los sistemas del edificio se ubican así en segmentos separados con sus propios controles de acceso.

¿Cómo decidir según su infraestructura?

Comience por la propiedad del dispositivo, no por la preferencia del protocolo. La siguiente matriz relaciona las situaciones habituales con una recomendación.

Su situación Método recomendado Motivo
Portátiles corporativos en un MDM EAP-TLS Los certificados se despliegan mediante las herramientas que ya paga
Terminales de pago y escáneres dentro del alcance PCI-DSS EAP-TLS Sin contraseñas compartidas que rotar o filtrar
Dispositivos clínicos en plantas hospitalarias EAP-TLS Revocación por dispositivo, sin contraseña compartida en la planta
Teléfonos personales del personal, sin MDM permitido PEAP con validación de servidor bloqueada Inicio de sesión en el directorio sin registrar el teléfono
Personal de temporada y contratistas PEAP con cuentas fechadas El acceso finaliza automáticamente en la fecha de fin de contrato
Smart TV, impresoras y sensores sin 802.1X iPSK en una VLAN dedicada Clave única por dispositivo, sin necesidad de suplicante 802.1X
Huéspedes de hotel, aficionados, pasajeros y compradores Captive Portal o OpenRoaming Sin cuenta de directorio y sin dispositivo que gestionar

iPSK (clave precompartida de identidad, también llamada PPSK) proporciona a cada dispositivo o grupo su propia clave WiFi en un único nombre de red. Utilícelo para dispositivos que no puedan ejecutar un suplicante 802.1X.

Una ruta de cuatro pasos hacia una decisión

  1. Inventaríe los dispositivos por propiedad. Divídalos en gestionados por la empresa, personales, sin pantalla y de invitados.
  2. Compruebe lo que ya ejecuta. Un MDM existente hace que EAP-TLS para dispositivos gestionados sea un proyecto modesto.
  3. Establezca el estado objetivo. EAP-TLS para cada dispositivo gestionado, PEAP solo donde el registro sea imposible.
  4. Migre sin interrumpir la infraestructura. Ejecute ambos métodos en un servicio RADIUS, mueva los dispositivos gestionados a EAP-TLS y, a continuación, retire sus perfiles PEAP.

¿Dónde encaja Purple?

Purple es independiente del hardware. Funcionamos como una superposición en la nube sobre Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. No hay que arrancar y reemplazar nada. Purple se superpone sobre la red que ejecuta hoy.

Para el personal y los residentes, las redes basadas en la identidad de Purple vinculan el acceso WiFi del personal y el WiFi multinquilino a la identidad. Funcionan a través de RADIUS en la nube vinculado a Microsoft Entra ID, Okta o Google Workspace. Las altas, cambios y bajas se gestionan desde el directorio en lugar de hacerlo manualmente. Los dispositivos que no pueden ejecutar 802.1X obtienen iPSK.

Para los invitados, el WiFi para invitados de Purple ofrece un Captive Portal, una página web que se muestra antes del acceso, con opciones de suscripción de elección consciente. También admite OpenRoaming, la federación de la Wireless Broadband Alliance basada en Passpoint (Hotspot 2.0). OpenRoaming permite que los dispositivos que regresan se conecten automáticamente a través de una conexión cifrada. El plan Connect de Purple incluye un proveedor de identidad para OpenRoaming. WiFi Analytics convierte después esas conexiones en datos de primera parte sobre el tiempo de permanencia y las visitas repetidas.

Purple funciona en más de 80.000 instalaciones activas y gestionó 440 millones de inicios de sesión en 2024 (datos propios de Purple). Purple cuenta con la certificación ISO 27001, cumple con el GDPR y tiene la certificación Cyber Essentials.

Preguntas frecuentes

¿Es EAP-TLS más seguro que PEAP?

Sí. EAP-TLS autentica a ambas partes mediante certificados, por lo que no hay contraseñas que puedan ser objeto de phishing, adivinadas o capturadas desde un punto de acceso no autorizado. PEAP protege la contraseña dentro de un túnel cifrado. Su seguridad depende de que cada dispositivo valide el certificado del servidor. Si se configura correctamente, PEAP es aceptable para dispositivos personales. Para los dispositivos propiedad de la empresa, los terminales de pago y el equipamiento clínico, EAP-TLS elimina por completo este tipo de ataques a las credenciales.

¿Exige PCI-DSS el uso de EAP-TLS para redes inalámbricas?

No. PCI-DSS v4.0 no especifica un método EAP concreto. Exige criptografía fuerte en redes inalámbricas que transmitan datos de titulares de tarjetas y comprobaciones trimestrales de puntos de acceso no autorizados según el requisito 11.2.1. También establece controles de contraseñas allí donde se utilicen. EAP-TLS deja las contraseñas de WiFi fuera del alcance de la auditoría para los dispositivos incluidos, lo que simplifica la acreditación. PEAP también puede cumplir con la normativa si se aplican y documentan la validación del servidor y la directiva de contraseñas.

¿Podemos migrar de PEAP a EAP-TLS sin interrupciones en el servicio?

Sí. Un único servicio RADIUS puede aceptar ambos métodos en el mismo nombre de red. Cada dispositivo utiliza el método especificado en su perfil. Emita los certificados y distribuya el nuevo perfil de EAP-TLS a través de su MDM; a continuación, supervise los registros de RADIUS a medida que los dispositivos realicen la transición. Cuando ningún dispositivo gestionado se autentique ya mediante PEAP, elimine sus perfiles PEAP. Mantenga PEAP únicamente para los dispositivos personales que no pueda inscribir.

¿Necesitamos un MDM para ejecutar EAP-TLS?

Para más de un grupo reducido de dispositivos, la respuesta práctica es sí. Cada dispositivo necesita un certificado, una CA de confianza y un perfil de WiFi. Además, cada certificado debe renovarse antes de que caduque. Un MDM como Microsoft Intune automatiza este proceso a través de SCEP o un protocolo de inscripción similar. Sin él, una herramienta de incorporación puede instalar certificados en dispositivos personales, pero la instalación manual no es escalable más allá de una fase piloto.

¿Cuánto cuesta EAP-TLS en comparación con PEAP?

Ninguno de los dos protocolos tiene coste de licencia. La diferencia radica en la infraestructura y el tiempo del personal. PEAP requiere un servicio RADIUS, un certificado de servidor y un directorio que probablemente ya tenga en funcionamiento. EAP-TLS añade una PKI - en la nube o local - y un MDM para entregar y renovar los certificados. Si ya paga por un MDM, el coste adicional se reduce principalmente a la PKI. A cambio, los bloqueos por rotación y el restablecimiento de contraseñas de WiFi desaparecen.

¿Funcionará Purple con los puntos de acceso que ya poseemos?

Sí. Purple es independiente del hardware y funciona como una superposición en la nube compatible con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet. Todos ellos admiten 802.1X con un servidor RADIUS externo. Sus puntos de acceso no limitan la elección entre EAP-TLS y PEAP. No hace falta reemplazar nada: Purple se integra sobre la red que utiliza hoy en día.

¿Deberían los invitados utilizar EAP-TLS o PEAP?

No. Ambos protocolos presuponen una persona conocida o un dispositivo gestionado, y los invitados de hoteles, estadios y estaciones no son ninguno de los dos. Utilice un Captive Portal para la aceptación explícita y los términos de uso. Utilice OpenRoaming, creado sobre Passpoint, para que los dispositivos habituales se conecten automáticamente a través de un enlace cifrado. El Guest WiFi de Purple cubre ambos aspectos, y el plan Connect incluye un proveedor de identidad para OpenRoaming.\n\n### ¿Sigue siendo seguro utilizar PEAP en 2026?\n\nSí, dentro de ciertos límites. PEAP con validación de certificado de servidor bloqueada y contraseñas de directorio robustas sigue siendo una opción razonable para dispositivos personales. Su función se está reduciendo en Windows, donde Credential Guard bloquea las credenciales MSCHAPv2 guardadas. Microsoft recomienda en su lugar la autenticación basada en certificados. Planifique EAP-TLS para cada dispositivo Windows gestionado y mantenga PEAP para los dispositivos que no controle.

Definiciones clave

IEEE 802.1X

El estándar IEEE para el control de acceso a la red basado en puertos. Requiere que un dispositivo se autentique antes de que el punto de acceso reenvíe su tráfico, transportando el intercambio como mensajes EAP a un servidor RADIUS.

Tanto EAP-TLS como PEAP se ejecutan dentro de 802.1X, por lo que la elección en esta guía radica en qué método EAP utiliza su despliegue 802.1X, no en si debe usar 802.1X.

EAP-TLS

Un método EAP definido en IETF RFC 5216 y actualizado para TLS 1.3 en RFC 9190. El servidor y el dispositivo presentan cada uno un certificado digital, y el dispositivo demuestra que posee una clave privada que nunca sale de él.

El método recomendado para portátiles corporativos, terminales de pago, escáneres y dispositivos clínicos, ya que ninguna contraseña cruza la red y perder un dispositivo solo cuesta la revocación de un certificado.

PEAP

Protected EAP, desarrollado por Microsoft, Cisco y RSA Security y documentado en la especificación del protocolo MS-PEAP de Microsoft en lugar de un estándar IETF. Solo el servidor presenta un certificado; el dispositivo envía las credenciales dentro de un túnel TLS.

La alternativa para teléfonos personales y dispositivos de contratistas que no se pueden inscribir. Solo es aceptable con la validación del certificado de servidor activada y bloqueada y contraseñas de directorio robustas.

MSCHAPv2

Microsoft Challenge Handshake Authentication Protocol versión 2, el método interno basado en contraseña que se utiliza casi siempre dentro de PEAP. El aviso de seguridad de Microsoft 2743314 (2012) advirtió que los intercambios MSCHAPv2 no encapsulados se pueden descifrar.

Su debilidad es la razón por la que la validación del certificado del servidor determina la seguridad de PEAP, y por la que Windows Credential Guard ahora bloquea las credenciales guardadas de WiFi MSCHAPv2.

RADIUS

El servicio de autenticación que recibe los mensajes EAP retransmitidos por el punto de acceso y aprueba o rechaza cada conexión 802.1X, devolviendo opcionalmente atributos como la VLAN para el dispositivo.

Un servicio RADIUS puede aceptar EAP-TLS y PEAP en el mismo nombre de red, lo que permite una migración sin tiempo de inactividad. Ejecútelo con redundancia, ya que la autenticación se encuentra en la ruta crítica.

Evil twin

Un punto de acceso malicioso que emite su nombre de red. Un cliente PEAP que omite la validación del certificado del servidor completa el proceso MSCHAPv2 con él y le entrega un desafío y su respuesta.

El principal riesgo de PEAP. Las versiones recientes de Android eliminaron la opción de omitir la validación, y el requisito 11.2.1 de PCI DSS exige revisiones trimestrales para detectar puntos de acceso no autorizados.

OCSP y CRL

Online Certificate Status Protocol (RFC 6960) y la lista de revocación de certificados, los dos mecanismos que utiliza un servidor RADIUS para confirmar que un certificado de cliente no ha sido revocado durante el proceso de negociación EAP-TLS.

La comprobación de revocación es lo que permite desvincular dispositivos individuales: revoque un certificado y solo ese dispositivo perderá el acceso.

PKI

Infraestructura de clave pública, el sistema que emite y revoca certificados, ejecutado localmente o en la nube. EAP-TLS la necesita para emitir un certificado a cada dispositivo cliente.

El principal coste inicial de EAP-TLS. Si ya paga por un MDM, la PKI representa la mayor parte del gasto adicional en comparación con PEAP.

SCEP

Simple Certificate Enrollment Protocol, especificado en la RFC 8894, utilizado por plataformas MDM como Microsoft Intune para solicitar e instalar certificados de dispositivo de forma automática.

Cómo llegan los certificados a los dispositivos gestionados a escala y se renuevan antes de caducar, motivo por el cual la instalación manual no escala más allá de una prueba piloto.

Asignación dinámica de VLAN

Servicio RADIUS que devuelve una VLAN (LAN virtual) para cada dispositivo autenticado utilizando los atributos de túnel definidos en la RFC 3580, de modo que el punto de acceso sitúe el dispositivo en el segmento correcto.

Evita que un inicio de sesión 802.1X exitoso abra una red plana, manteniendo los dispositivos de pago alejados de los teléfonos del personal y fuera del alcance del entorno de datos de titulares de tarjetas.

Windows Credential Guard

Una función de seguridad de Windows que, según la documentación de Microsoft, impide las conexiones WiFi y VPN basadas en MSCHAPv2 que utilizan credenciales guardadas. Está activada de forma predeterminada en dispositivos elegibles con Windows 11 Enterprise y Education a partir de la versión 22H2.

Un cambio en la plataforma que inclina la decisión hacia EAP-TLS para parques de dispositivos Windows gestionados, ya que Microsoft recomienda métodos basados en certificados.

iPSK

Clave precompartida de identidad, también llamada PPSK, que proporciona a cada dispositivo o grupo su propia clave WiFi en un solo nombre de red sin necesidad de un suplicante 802.1X.

La elección correcta para televisores inteligentes, impresoras y sensores que no pueden ejecutar EAP-TLS o PEAP, ubicados en una VLAN dedicada.

Ejemplos prácticos

Un grupo hotelero con 30 propiedades ejecuta portátiles de administración, tabletas de personal de limpieza y PC de recepción en una única red WiFi de personal utilizando PEAP con un número reducido de cuentas compartidas de Active Directory. Cada tableta extraviada obliga a restablecer la contraseña compartida y a reconfigurar cada dispositivo que la utilice.

Como todos los dispositivos ya estaban inscritos en un MDM, el equipo desplegó una PKI en la nube e impulsó certificados de dispositivo mediante SCEP (RFC 8894). El perfil de WiFi de personal cambió a EAP-TLS, mientras que PEAP permaneció activo en el mismo servicio RADIUS durante toda la transición. La asignación dinámica de VLAN ubicó las tabletas de limpieza en un segmento diferente al de los portátiles de finanzas. Las cuentas WiFi compartidas se redujeron a cero. Perder una tableta ahora solo implica una revocación de certificado en lugar de un restablecimiento de contraseña en docenas de dispositivos, y la rotación de contraseñas ya no interrumpe el WiFi porque no queda ninguna contraseña de WiFi.

Un centro de conferencias en el centro de la ciudad contrata a unos 300 trabajadores temporales en cada temporada alta. Utiliizan sus teléfonos personales para aplicaciones de turnos y radio, no se les puede pedir que los inscriban en un MDM y han compartido una única contraseña WPA2-Personal fijada en el tablón de anuncios de la sala de personal.

El equipo de TI creó una cuenta de directorio con fecha de finalización para cada trabajador temporal y migró el WiFi de personal a PEAP. Un perfil de incorporación de un solo uso fijó la CA de confianza y el nombre del servidor en cada teléfono, cerrando la brecha de ataque gemelo malvado ("evil twin") sin necesidad de inscripción en MDM. Las cuentas se desactivan automáticamente en la fecha de finalización del contrato y los asistentes permanecieron en una red independiente con Captive Portal. La contraseña compartida se retiró. Quienes dejan la empresa pierden el acceso en su fecha de finalización en lugar de en el siguiente cambio de contraseña, y cada conexión del personal se asigna a una cuenta con nombre en los registros RADIUS para su auditoría tras cada evento.

Una cadena minorista con 120 tiendas ejecuta escáneres portátiles y dispositivos de punto de venta móviles en PEAP con una cuenta de servicio compartida. Cada rotación programada de esa cuenta provoca fallos de autenticación nocturnos en las tiendas donde los dispositivos conservan la contraseña antigua.

El equipo de TI migró los escáneres y dispositivos de pago a EAP-TLS a través del MDM que ya utilizaba, asignando a cada dispositivo su propio certificado. Los teléfonos del personal de la tienda permanecieron en PEAP, en una VLAN independiente sin ruta hacia el entorno de datos de titulares de tarjetas. Las interrupciones en los días de rotación cesaron porque los dispositivos implicados ya no dependían de una contraseña compartida, y la revocación pasó a ser por dispositivo en lugar de por tienda. Las comprobaciones trimestrales de puntos de acceso no autorizados según el requisito 11.2.1 de PCI-DSS continuaron sin cambios, mientras que la eliminación de las contraseñas WiFi de los dispositivos afectados redujo las evidencias necesarias para la auditoría.

Preguntas de práctica

Q1. El departamento de TI de una universidad está desplegando WiFi seguro en todo el campus para 20.000 estudiantes. Los estudiantes traen sus propios portátiles y smartphones con una combinación de Windows, macOS, iOS y Android. El director de TI insiste en la máxima seguridad y propone EAP-TLS. ¿Cuál es su recomendación arquitectónica?

Sugerencia: Considere la carga operativa de la gestión de certificados en dispositivos no gestionados y de propiedad personal dentro de un parque de dispositivos heterogéneo.

Ver respuesta modelo

Aconseje no utilizar EAP-TLS para este caso de uso específico. Aunque EAP-TLS ofrece la máxima seguridad, desplegar y gestionar más de 20 000 certificados de cliente en dispositivos de estudiantes no gestionados sin una solución MDM creará una carga de soporte insostenible. Los estudiantes cambian de dispositivo con frecuencia, y el proceso de incorporación para la instalación de certificados en iOS, Android, Windows y macOS es complejo sin la automatización de un MDM. Recomiende PEAP (o EAP-TTLS) integrado con el servicio de directorio de estudiantes de la universidad. Asegúrese de utilizar herramientas de incorporación sólidas para configurar los dispositivos de los estudiantes de modo que validen estrictamente el certificado del servidor. Opcionalmente, despliegue EAP-TLS en un SSID independiente para los dispositivos del personal gestionados por la universidad, creando así una arquitectura de seguridad por niveles.

Q2. Durante una auditoría de seguridad, un pentester logra recopilar credenciales de usuario de su red inalámbrica protegida con PEAP configurando un punto de acceso no autorizado que emite el mismo SSID. ¿Cuál es la causa raíz de esta vulnerabilidad y cuál es la solución?

Sugerencia: Piense en lo que ocurre durante la fase de establecimiento del túnel TLS en PEAP y en lo que el dispositivo cliente está - o no está - verificando.

Ver respuesta modelo

La causa raíz es una configuración incorrecta del suplicante. Los dispositivos cliente no están configurados para validar estrictamente el certificado digital del servidor RADIUS. Cuando el AP no autorizado presentó un certificado fraudulento, los dispositivos cliente confiaron a ciegas en él, establecieron el túnel TLS con el atacante y transmitieron el intercambio de autenticación MSCHAPv2. El atacante puede descifrar esto de forma fuera de línea. La solución es triple: (1) aplicar una validación estricta del certificado del servidor mediante directivas de grupo o perfiles MDM en todos los dispositivos cliente; (2) especificar el nombre de dominio exacto del servidor RADIUS esperado en la configuración del suplicante para evitar la aceptación de certificados de otros dominios; (3) desplegar un sistema de detección de intromisiones inalámbricas (WIDS) para detectar puntos de acceso no autorizados y alertar sobre ellos.

Q3. Un proveedor de atención médica está actualizando su red para dar soporte a estaciones de trabajo de enfermería móviles que acceden a historiales de pacientes. Estas estaciones de trabajo son propiedad de la empresa, están estrictamente gestionadas por TI a través de Microsoft Intune y el entorno debe cumplir con las regulaciones de protección de datos sanitarios. ¿Deberían desplegar PEAP o EAP-TLS?

Sugerencia: Evalúe el entorno regulatorio, el nivel de control del dispositivo y la sensibilidad de los datos a los que se accede.

Ver respuesta modelo

Despliegue EAP-TLS sin dudarlo. El entorno sanitario requiere un cumplimiento estricto y la máxima seguridad contra el robo de credenciales - una contraseña comprometida en una red sanitaria puede exponer historiales de pacientes y acarrear sanciones regulatorias importantes bajo el GDPR y otros requisitos específicos del sector sobre protección de datos. Dado que los dispositivos son propiedad de la empresa y están estrictamente gestionados a través de Microsoft Intune, el despliegue de certificados de cliente es viable a nivel operativo y se puede automatizar por completo. EAP-TLS proporciona la autenticación mutua necesaria para garantizar que solo los dispositivos autorizados y gestionados por la empresa puedan acceder a la red clínica. Además, EAP-TLS simplifica las auditorías de cumplimiento - los auditores que revisen la arquitectura de red verán un sistema de autenticación sin contraseñas basado en certificados que es intrínsecamente más defendible que las alternativas basadas en contraseñas.

Preguntas frecuentes

¿Es EAP-TLS más seguro que PEAP?

Sí. EAP-TLS autentica ambas partes mediante certificados, por lo que no hay contraseña que pueda sufrir phishing, adivinarse o capturarse desde un punto de acceso no autorizado. PEAP protege una contraseña dentro de un túnel cifrado. Su seguridad depende de que cada dispositivo valide el certificado del servidor. Bien configurado, PEAP es aceptable para dispositivos personales. Para dispositivos corporativos, terminales de pago y equipos clínicos, EAP-TLS elimina toda una categoría de ataques contra credenciales.

¿Exige PCI DSS el uso de EAP-TLS para redes inalámbricas?

No. PCI DSS v4.0 no especifica un método EAP. Exige criptografía sólida en redes inalámbricas que transporten datos de titulares de tarjetas y comprobaciones trimestrales de puntos de acceso no autorizados según el requisito 11.2.1. También establece controles de contraseñas allá donde se utilicen. EAP-TLS deja las contraseñas de WiFi fuera del alcance de los dispositivos afectados, lo que acorta la aportación de evidencias. PEAP también puede cumplir con la normativa si la validación del servidor y la política de contraseñas se aplican y documentan.

¿Podemos pasar de PEAP a EAP-TLS sin tiempo de inactividad?

Sí. Un único servicio RADIUS puede aceptar ambos métodos con el mismo nombre de red. Cada dispositivo utiliza el método que especifique su perfil. Emita certificados e impulse el nuevo perfil EAP-TLS a través de su MDM; a continuación, supervise los registros de RADIUS a medida que los dispositivos realicen la transición. Cuando ningún dispositivo gestionado continúe autenticándose con PEAP, elimine sus perfiles PEAP. Conserve PEAP únicamente para los dispositivos personales que no pueda inscribir.

¿Necesitamos un MDM para ejecutar EAP-TLS?

Para más de un puñado de dispositivos, sí en la práctica. Cada dispositivo necesita un certificado, una CA de confianza y un perfil de WiFi. Cada certificado también debe renovarse antes de que caduque. Un MDM como Microsoft Intune automatiza esto mediante SCEP o un protocolo de inscripción similar. Sin él, una herramienta de incorporación puede instalar certificados en dispositivos personales, pero la instalación manual no resulta escalable más allá de una fase piloto.

¿Cuánto cuesta EAP-TLS en comparación con PEAP?

Ninguno de los dos protocolos tiene coste de licencia. La diferencia reside en la infraestructura y el tiempo del personal. PEAP requiere un servicio RADIUS, un certificado de servidor y un directorio que probablemente ya tenga en funcionamiento. EAP-TLS añade una PKI (en la nube o en las instalaciones) y un MDM para entregar y renovar certificados. Si ya paga por un MDM, el coste adicional es principalmente la PKI. A cambio, los restablecimientos de contraseñas de WiFi y los bloqueos por rotación desaparecen.

¿Funcionará Purple con los puntos de acceso que ya tenemos?

Sí. Purple 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. Todos ellos admiten 802.1X con un servidor RADIUS externo. Sus puntos de acceso no limitan la elección entre EAP-TLS y PEAP. No hace falta sustituir nada: Purple se integra sobre la red que ya utiliza hoy.

¿Deberían los invitados utilizar EAP-TLS o PEAP?

No. Ambos protocolos asumen que el usuario es conocido o que el dispositivo está gestionado, algo que no ocurre con los visitantes de hoteles, estadios o estaciones. Utilice un Captive Portal para la aceptación de condiciones y términos de uso. Utilice OpenRoaming, desarrollado sobre Passpoint, para que los dispositivos habituales se conecten automáticamente mediante un enlace cifrado. El WiFi para invitados de Purple cubre ambas opciones, y el plan Connect incluye un proveedor de identidad para OpenRoaming.

¿Sigue siendo seguro utilizar PEAP en 2026?

Sí, dentro de ciertos límites. PEAP con validación de certificado de servidor bloqueada y contraseñas de directorio robustas sigue siendo una opción razonable para dispositivos personales. Su función se está reduciendo en Windows, donde Credential Guard bloquea las credenciales MSCHAPv2 guardadas. Microsoft recomienda la autenticación basada en certificados. Planifique EAP-TLS para cada dispositivo Windows gestionado y mantenga PEAP para los dispositivos que no controle.

Fuentes

  1. IETF RFC 5216: The EAP-TLS Authentication Protocol
  2. IETF RFC 9190: EAP-TLS 1.3
  3. IETF RFC 3580: IEEE 802.1X RADIUS Usage Guidelines
  4. Microsoft Security Advisory 2743314
  5. Microsoft Learn: Credential Guard overview
  6. PCI Security Standards Council document library (PCI DSS v4.0)
  7. CA/Browser Forum
  8. IBM Cost of a Data Breach Report

Continúe leyendo esta serie

Microsoft Cloud PKI para WiFi: despliegue de certificados EAP-TLS con Intune y Microsoft Entra ID

Podrá decidir si Microsoft Cloud PKI, una entidad de certificación (CA) raíz en la nube o su propia CA (BYOCA) se adapta mejor a su infraestructura. A continuación, podrá desplegar certificados WiFi EAP-TLS en dispositivos gestionados por Intune sin necesidad de NDES. La guía también cubre cómo hacer que RADIUS confíe en la cadena, revocar certificados a través de la CRL y solucionar los ocho fallos más comunes.

Leer la guía →

Configuración de 802.1X en Juniper Mist con cloud RADIUS

Podrá configurar una WLAN WPA2 o WPA3-Enterprise en Juniper Mist que se autentique contra cloud RADIUS, decidir entre UDP RADIUS, RadSec y un proxy Mist Edge, y mapear atributos RADIUS a VLANs dinámicas. También sabrá exactamente en qué punto falló una autenticación gracias al cronograma de información sobre clientes de Mist y a Marvis.

Leer la guía →

Resolución de problemas de 802.1X en iOS y macOS: una lista de verificación de despliegue para Intune, Jamf y Microsoft Entra ID

Utilice esta lista de verificación para diagnosticar por qué los iPhones, iPads y Macs fallan al conectar con 802.1X en Intune o Jamf Pro. Cada fallo se asocia a una de estas cuatro causas: confianza en el servidor, certificado de identidad, modo macOS o ámbito de grupo de Microsoft Entra ID. Confirmará la causa mediante los registros de eapolclient y RADIUS, aplicará la solución y organizará las futuras rotaciones de certificados.

Leer la guía →

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con operadores de recintos, responsables de TI e ingenieros de redes en 80 000 espacios. Reserve una llamada de 20 minutos y le mostraremos cómo lo han solucionado otros profesionales como usted.