MFA adaptativa: por qué romper las reglas fijas
«MFA está activo» no es un estado final. Los segundos factores estáticos fallan ante fatiga de prompts, secuestro de sesión y procesos auxiliares. La MFA adaptativa regula el riesgo por inicio de sesión y alivia justo donde las reglas genéricas generan ruido.
Lo más importante en resumen
- El riesgo decide el factor. Dispositivo, ubicación, comportamiento y valor del recurso determinan el step-up – no un genérico «siempre push».
- Factores resistentes al phishing primero. Passkeys/FIDO donde sea posible; SMS y prompts push agotadores solo como transición.
- Blindar los procesos auxiliares. Los restablecimientos del helpdesk y el break-glass suelen ser el camino más débil – no el botón de acceso.
Relacionado:¿Qué es un Passkey? Definición y estándares / Passkeys en la empresa: el fin de la contraseña
Dónde falla la MFA estándar
¿Qué es la Adaptive MFA? La Adaptive MFA (autenticación multifactor basada en riesgos) decide, según señales como dispositivo, red, comportamiento y valor del recurso, si se exige un factor adicional y cuál: hasta el bloqueo o solo passwordless, en lugar de reglas rígidas de push para todos.
Muchas organizaciones han «desplegado» MFA: push de la app o SMS en todas las cuentas, casilla marcada en la lista de cumplimiento. Atacantes y la realidad explotan los huecos de alrededor. Los ataques de fatiga bombardean a los usuarios con peticiones push hasta que alguien confirma. Las cookies de sesión y el robo de tokens eluden el segundo factor tras el inicio de sesión. El social engineering en el helpdesk restablece el factor sin verificar al titular de la cuenta.
La Adaptive MFA plantea la decisión clave: ¿cuándo basta la confianza en el dispositivo, cuándo es obligatorio un step-up resistente al phishing y cuándo se bloquea el acceso de forma contundente?
Definición · Adaptive MFA
Autenticación multifactor basada en riesgos: las señales (dispositivo, red, comportamiento, recurso, identidad) determinan si se exige un factor adicional y cuál – hasta el bloqueo o solo passwordless.
Señales que de verdad deberían gobernar
Mínimo práctico: dispositivo administrado vs. desconocido, accesos geo y de red atípicos, viaje imposible, nuevos navegadores/UA, acceso a apps privilegiadas (portales de administración, sistemas financieros, admin de identidad) y tipo de identidad (persona, servicio, break-glass).
Login de bajo riesgo desde dispositivo administrado en la red corporativa a una app no crítica: la menor fricción posible (passkey o sesión SSO). Alto riesgo: nueva ubicación, dispositivo privado, acceso a admin de Entra/AD – step-up resistente al phishing o Deny. Así baja la fatiga, porque no cada login de pedido de café dispara un push.
Ordenar los factores por resistencia
Las passkeys y las llaves de seguridad FIDO2 son el estado objetivo para grupos privilegiados y amplios, cuando hardware y SO lo permiten. TOTP supera al SMS, pero es phisheable. El push sin number matching es propenso a fatiga; con number matching mejora, pero no es resistente al phishing. SMS y llamada de voz siguen siendo un último recurso – y deben salir de las rutas privilegiadas.
La MFA adaptativa sin hoja de ruta de factores acaba en «sigue siendo SMS, solo menos a menudo». La política debe imponer la vía de mejora: apps críticas solo con método resistente.
| Escenario | Señal | Reacción |
|---|---|---|
| Día a día | Dispositivo gestionado, red conocida | Passkey/SSO, poca fricción |
| Viaje / nuevo | País nuevo, dispositivo nuevo | Step-up FIDO/Passkey |
| Privilegiado | Portal de admin IAM/nube | Solo phishing-resistente, CAE si aplica |
| Abuso | Viaje imposible, anomalía de token | Bloqueo + alerta SOC |
Fuente: esquema práctico SecurityToday (Conditional Access / autenticación basada en riesgo)
La mitad olvidada: recuperación y operación
Las reglas adaptativas sirven de poco si el helpdesk restablece el segundo factor por teléfono en cuanto alguien dice «IT». La recuperación exige identidad sólida, el principio de cuatro ojos en cuentas privilegiadas y logging. Cuentas break-glass: documentadas offline, resistentes a MFA, con alerta al usarse y pruebas periódicas.
Checklist de implementación
- ✓Niveles de app: privilegiado / normal / bajo riesgo con reglas de autenticación claras
- ✓Piloto Passkey/FIDO para admins y luego despliegue amplio
- ✓Fatiga de push: number matching o cambio a factores resistentes
- ✓Reset del helpdesk y break-glass con cuatro ojos y alertas
La MFA adaptativa es operación, no un tic de proyecto. Métricas: proporción de logins resistentes al phishing, incidentes de fatiga, logins de alto riesgo exitosos vs. bloqueados, tiempo hasta el alta de step-up. Así, «MFA activada» se convierte en una capa de control gestionable.
En la práctica conviene un corte a 90 días: primero cuentas privilegiadas a Passkey o FIDO, luego apps de alto riesgo con step-up, después el resto con menos ruido. Métricas mensuales en el informe de seguridad: proporción de logins resistentes al phishing, intentos de alto riesgo bloqueados, incidentes de reset del helpdesk. Así la casilla MFA pasa a ser una capa de control gestionable que reduce la fatiga y hace visible el abuso real.
Preguntas frecuentes
Cada pregunta está cerrada. Un toque abre la respuesta.
¿Es la MFA adaptativa lo mismo que Conditional Access?
Conditional Access suele ser la herramienta de políticas. La MFA adaptativa es el objetivo: elección de factores según el riesgo. En la práctica, ambas se solapan mucho.
¿Podemos desactivar el SMS de inmediato?
En cuentas privilegiadas, sí debe aspirarse a ello. En el resto: transición con inscripción de passkeys y excepciones solo con límite temporal.
¿Protege el number matching frente a todos los ataques MFA?
Reduce el abuso por fatiga, pero no sustituye factores resistentes al phishing ni protege frente al robo de tokens tras el inicio de sesión.
¿Qué primero: passkeys o reglas adaptativas?
Ambos en paralelo: factores resistentes para administradores, reglas adaptativas frente al ruido y a los inicios de sesión de alto riesgo. Orden: primero las cuentas privilegiadas.
¿Cómo mido el éxito?
Porcentaje de autenticaciones resistentes al phishing, inicios de sesión de alto riesgo bloqueados, incidencias de restablecimiento en el helpdesk y quejas de usuarios por fatiga – mensualmente en el informe de seguridad.
Recomendaciones de la redacción
Recomendación¿Qué es un passkey? Definición, funcionamiento y estándaresRecomendaciónPasskeys en la empresa: el fin de la contraseñaRecomendaciónMFA adaptativa en la auditoría NIS2: cuándo la política sirve como prueba
Más de la red MBF Media
cloudmagazinEl giro de Copilot: primero había que sumar a las personasMyBusinessFutureMás ritmo en el back office: cómo los bancos logran controlar por fin sus procesos intensivos en documentosDigital ChiefsKimi frena las suscripciones: 7 comprobaciones para el capex de IA
