MFA adaptable en Entra, Okta y Duo: cómo los equipos de seguridad pueden alinear su implementación en 2026 con NIS2
8 min. de lectura
La MFA adaptativa en 2026 es menos una cuestión de tecnología que una cuestión de evidencia. Desde que la ley de transposición de NIS2 en Alemania entró en vigor sin período transitorio, los equipos de seguridad no solo deben demostrar que disponen de autenticación multifactor. Deben demostrar que saben qué riesgos mitigan con ella. Eso implica que los umbrales de decisión estén documentados. Entra Conditional Access, Okta Adaptive MFA, Duo Risk-Based y Ping Identity ofrecen las funciones necesarias. Aun así, el despliegue fracasa con frecuencia en la brecha entre la funcionalidad y la evidencia.
Lo más importante en resumen
- NIS2 exige MFA, pero no especifica parámetros. El artículo 21 requiere autenticación multifactor y deja los umbrales y las excepciones a criterio de cada organización. La obligación de documentación es concreta; el marco técnico, deliberadamente amplio.
- La elección entre Entra, Okta, Duo y Ping depende del stack. Quien ya utiliza Microsoft 365 en profundidad suele decantarse por Entra Conditional Access. Para entornos multi-IdP, Okta sigue siendo la plataforma más flexible; Duo es la opción natural en contextos Cisco, y Ping Identity destaca en el segmento enterprise.
- La fatiga de MFA es el problema operativo central. Los ataques de push bombing y number matching están en aumento. Sin calibración de umbrales ni formación de usuarios, la MFA adaptativa pierde el efecto que debería tener.
RelacionadoInfostealers en 2026: cómo las cookies de sesión eluden la MFA / Identity sprawl en la pyme: configuraciones AD más nube
El artículo 21 de NIS2 como marco para la MFA adaptativa
La ley alemana de transposición de NIS2 está en vigor desde el 6 de diciembre de 2025, sin período transitorio. El registro ante el BSI era obligatorio hasta el 6 de marzo de 2026. El artículo 21 de la directiva enumera diez ámbitos en los que las organizaciones deben acreditar medidas, entre ellos políticas de acceso, seguridad de la cadena de suministro y, de forma explícita, autenticación multifactor. La redacción de la directiva es deliberadamente abierta: la MFA debe implementarse de forma «adecuada», sin que la UE ni el BSI fijen umbrales mínimos concretos.
Esta apertura se convierte en un problema durante las auditorías cuando las organizaciones declaran tener MFA activada pero carecen de documentación sobre la lógica de umbrales. Un auditor no pregunta si la MFA está habilitada. Pregunta en qué condiciones se exige un segundo factor, qué excepciones están configuradas, cómo están protegidos los accesos de emergencia y qué registros permiten rastrear la decisión de una política de acceso condicional. Los equipos de seguridad que han tratado la MFA como un asunto de casilla de verificación se encuentran ahora a la defensiva.
Las cuatro grandes plataformas IAM en comparación con MFA adaptativo
Microsoft Entra Conditional Access es la opción obvia en organizaciones con Microsoft 365, ya que el motor de políticas está integrado directamente en la pila de identidades y utiliza señales como riesgo de inicio de sesión, riesgo de usuario y cumplimiento del dispositivo procedentes de Microsoft Defender for Identity. Los umbrales pueden configurarse de forma granular por grupo y aplicación. El esfuerzo principal radica en la asignación precisa de políticas a grupos de usuarios y en la documentación de la lógica de decisión. Quien no mantenga un buen orden en sus políticas, al cabo de dos años se encontrará con un caos de cientos de reglas solapadas, donde nadie sabrá cuál se aplica realmente.
Okta Adaptive MFA se posiciona como plataforma multi-IdP y destaca cuando convergen varias fuentes de identidad (Active Directory, G Suite, sistemas de RRHH). Su motor de puntuación de riesgo utiliza huellas digitales del dispositivo, reputación de red y patrones de comportamiento. Para empresas que no están profundamente inmersas en Microsoft, Okta suele ser la primera opción. Su precio es superior al de Entra, pero ofrece mayor flexibilidad.
Duo Security, ahora parte de Cisco, está muy extendido en pymes y en empresas con infraestructura Cisco. Sus funciones basadas en riesgo están muy desarrolladas, y la integración con Cisco ISE y Umbrella ahorra dinero y tiempo si ya se ha invertido previamente en esta tecnología. Ping Identity tiene un papel más relevante en el segmento enterprise, con integraciones B2B complejas, Customer Identity Access Management y identidades federadas, más allá del entorno tradicional de pymes. Las cuatro plataformas comparten funciones básicas, pero difieren notablemente en la profundidad de integración con pilas tecnológicas existentes.
En la práctica, muchas veces no es la matriz de funciones la que decide, sino el soporte para aplicaciones heredadas. Muchas pymes alemanas disponen de aplicaciones que no entienden ni SAML ni OpenID Connect. La autenticación basada en cabeceras, el proxy RADIUS o los accesos SSH con certificados son estándar en este contexto. Duo y Ping ofrecen más profundidad en este campo; Entra ha ido reduciendo distancias en los últimos 18 meses gracias a Entra Application Proxy y Entra ID Governance. Okta cubre este aspecto mediante Access Gateway. La evaluación de estos casos específicos debería formar parte de la fase de selección, pues de lo contrario el despliegue puede fracasar cuando no se consiga integrar el sistema central de gestión de stocks o una aplicación especializada.
La licencia es el segundo aspecto que varía en la comparación. Microsoft Entra Conditional Access está incluido en Entra ID P1 y P2, siendo P2 el que activa las políticas de riesgo mediante Identity Protection. Okta factura por usuario con distintos paquetes para MFA, MFA adaptativo y gestión del ciclo de vida. Duo dispone de un modelo escalonado claro, con Duo Essentials, Advantage y Premier. Ping, en el entorno enterprise, suele situarse en un rango de precios más alto, aunque ofrece opciones de personalización más profundas. Quien busque un precio de referencia debe comparar siempre la configuración concreta, no los precios de lista por usuario.
Por qué la fatiga MFA es el riesgo número uno en los despliegues
El éxito de un despliegue productivo de MFA adaptativo no depende del motor de políticas, sino de la experiencia de usuario. Los ataques de *push bombing*, en los que los atacantes generan repetidamente solicitudes MFA hasta que el usuario las confirma por costumbre, se han convertido en 2025 en parte del manual estándar. La respuesta de los proveedores es el *number matching*, que obliga al usuario a introducir un número mostrado en la app autenticadora. Microsoft lo ha activado por defecto, mientras que Duo y Okta ofrecen variantes. Quien no imponga el *number matching* deja la puerta abierta.
Qué desencadena la fatiga MFA
- Solicitudes *push* sin contexto (sin nombre de app ni geolocalización)
- Umbrales demasiado bajos que activan la verificación en cada inicio de sesión
- Falta de formación del usuario sobre intentos de *phishing*
- Ausencia de herramientas de *reporting* para solicitudes sospechosas
Qué mitiga los ataques de fatiga
- *Number matching* como configuración predeterminada para todos los usuarios
- Políticas basadas en riesgo que alivian la carga de dispositivos de confianza
- Botón de denuncia de *self-service* en el autenticador
- Integración con SIEM para detectar patrones de *push bombing*
El segundo punto crítico es la calibración de los umbrales. Si un sistema de MFA adaptativo exige un segundo factor en cada segundo inicio de sesión, genera fatiga en las solicitudes y soluciones alternativas. Si lo hace con demasiada poca frecuencia, pierde su efecto de seguridad. El enfoque pragmático consiste en empezar con políticas conservadoras durante los tres primeros meses y aprender, mediante telemetría, qué patrones de inicio de sesión son realmente sospechosos. Entra, Okta y Duo ofrecen paneles que muestran la frecuencia de solicitudes por usuario y nivel de riesgo.
Un aspecto frecuentemente pasado por alto es el tratamiento de las cuentas de servicio y los accesos a API. El MFA adaptativo está optimizado para inicios de sesión interactivos de usuarios. En el caso de automatizaciones, se requieren autenticaciones basadas en certificados o *tokens* temporales con rotación. Quien deje cuentas de servicio con contraseñas de larga duración sin MFA tendrá una brecha que los atacantes buscarán específicamente en 2026. La documentación de la política de cuentas de servicio forma parte de la evidencia NIS2, no solo la MFA de usuarios.
Un tercer componente que se revisa en las auditorías es el tratamiento de usuarios externos. Proveedores, colaboradores y socios obtienen regularmente acceso a sistemas internos sin estar incluidos en los procesos estándar de IAM. Entra B2B Collaboration, Okta External Identities y Ping DaVinci ofrecen funciones para proporcionar a los externos un flujo de MFA limpio. Quien obligue a los externos a usar cuentas de usuario internas no solo tendrá un problema de evidencia, sino también una superficie de ataque que ya se ha explotado en múltiples ocasiones en ataques a la cadena de suministro durante 2025.
Cómo los equipos de seguridad organizan un despliegue impecable
Un despliegue realista se desarrolla en cuatro fases, que según el tamaño de la organización pueden extenderse entre diez y veinte semanas. La primera fase es el inventario, y la última, la preparación para auditorías.
El punto más débil en un despliegue suele ser la falta de conexión con la respuesta a incidentes. Si el SIEM detecta patrones de inicio de sesión sospechosos, pero el equipo de IAM no sabe cómo poner cuentas en cuarentena rápidamente, el MFA adaptativo tiene un punto ciego. La integración entre Entra u Okta y el flujo del SOC debe incluirse en la primera fase, no al final. En concreto: Splunk, Sentinel o Elastic necesitan los registros de inicio de sesión, eventos de riesgo y cambios de políticas en un repositorio central, con alertas para patrones como diez intentos fallidos de inicio de sesión en cinco minutos o un prompt desde un país inusual. Los formatos de registro difieren entre Entra y Okta, y la normalización es una tarea que no puede delegarse al proveedor del SIEM.
Para terminar, el punto más importante: el MFA adaptativo no es un proyecto con fecha de finalización, sino una operación continua. Los umbrales cambian porque los atacantes emplean nuevas técnicas. Se integran nuevas aplicaciones y los grupos de usuarios evolucionan. Quien planifica el despliegue como un proyecto puntual, se encontrará a los dieciocho meses con una pila de IAM que ya no refleja la última amenaza. Un rol fijo para la operación de IAM y revisiones trimestrales de políticas son lo que convierte al MFA adaptativo en una evidencia productiva.
Un ejemplo práctico concreto: un fabricante de maquinaria en Sauerland inició a finales de 2025 el despliegue de Entra Conditional Access. La fase piloto duró dos semanas con un grupo de TI, incluyendo políticas intencionadamente conservadoras. En los primeros tres días se registraron 140 prompts de MFA por usuario y día, ya que un desencadenante de política reaccionaba a cada cambio entre VPN y LAN de oficina. Tras un ajuste que incorporó el estado de dispositivo conforme como señal, el número de prompts se redujo a entre 12 y 18 al día, una cifra que los usuarios aceptaron. La lección: la telemetría en la fase piloto no es una funcionalidad opcional, sino la herramienta que decide la aceptación.
Otro aspecto que surge con frecuencia en las conversaciones de auditoría es la separación entre autenticación y autorización. El MFA decide si alguien puede iniciar sesión de forma segura. Lo que puede hacer después lo regula la autorización mediante Role-Based Access Control, Privileged Access Management o acceso Just-in-Time. Muchas empresas lo mezclan, lo que lleva a la conclusión errónea de que un MFA robusto compensa una configuración de roles débil. No es así. NIS2 exige en su artículo 21 políticas de acceso explícitas. Estas políticas deben basarse en una arquitectura de roles sólida, no solo en el prompt de MFA.
Preguntas frecuentes
¿Exige NIS2 expresamente MFA adaptativo o basta con el MFA clásico?
La directiva exige un MFA «adecuado» sin parámetros concretos. Quien utilice un MFA clásico con un segundo factor robusto cumple con la obligación si la documentación está en regla. El MFA adaptativo no es obligatorio, pero en organizaciones con alta exposición al riesgo se convierte en un estándar de facto, ya que permite justificar umbrales y excepciones de manera transparente.
¿Cómo se realiza el cambio de Duo a Entra Conditional Access en entornos Microsoft 365?
Normalmente de forma paralela, no como un *big bang*. Conditional Access se aplica primero a las aplicaciones de Microsoft, mientras Duo sigue activo para sistemas Cisco y aplicaciones heredadas. Tras seis o nueve meses suele quedar claro si compensa el cambio completo o si un modelo híbrido resulta más práctico a largo plazo.
¿Qué umbrales son un buen punto de partida para el MFA adaptativo?
Un punto de partida habitual es: solicitar MFA al iniciar sesión desde un dispositivo nuevo, desde una IP de red desconocida, fuera del horario laboral o al acceder a aplicaciones sensibles. Tras tres meses, los umbrales se ajustan según la telemetría, lo que suele derivar en endurecer algunas condiciones y relajar otras.
¿Cómo gestiono las cuentas de servicio que no admiten MFA interactivo?
Las cuentas de servicio utilizan autenticación basada en certificados o identidades gestionadas, combinadas con tokens de corta duración y rotación de secretos en el *vault*. El nivel de protección no es MFA, pero sí equivalente. Documentar esta decisión es clave para que el auditor entienda la política aplicada.
¿Qué opina el BSI sobre el *number-matching* como configuración predeterminada?
El BSI recomienda el *number-matching* o procedimientos equivalentes en sus últimas directrices, aunque sin establecerlo como obligación explícita. Microsoft lo ha configurado como predeterminado en Entra Authenticator, mientras que Duo y Okta lo promueven con insistencia y lo integran de forma destacada en sus consolas de administración. Quien utilice notificaciones *push* sin *matching* debe justificar la decisión en el análisis de riesgos y registrarla en la documentación de NIS2.
Más del MBF Media Network
Fuente de la imagen de portada: Pexels / indra projects (px:27742642)
