Fatiga de MFA explicada: por qué falla la autenticación por push (y qué usar en su lugar)
El MFA por push se popularizó porque es simple: los usuarios tocan “Aprobar” y siguen. Esa simplicidad también es su debilidad. Los prompts push convierten la autenticación en una decisión humana bajo interrupción y presión, algo que los atacantes pueden manipular a escala.
Los ataques de fatiga de MFA, también conocidos como “prompt bombing” o “push bombing”, explotan un comportamiento predecible: cuando los usuarios reciben prompts repetidos, algunos acabarán aprobando uno para que pare, o aprobarán bajo estrés y confusión. Esto no es un caso extremo raro. Es un resultado natural de cómo se usa el MFA por push en organizaciones reales.
Este artículo explica cómo funciona la fatiga de MFA, por qué tiene éxito y qué pueden hacer los equipos empresariales en su lugar.
Relacionado: Tipos de MFA para empresas: qué funciona, qué falla y cómo recuperar el acceso de forma segura
¿Qué es la fatiga de MFA (prompt bombing)?
La fatiga de MFA es un patrón de ataque en el que un adversario provoca prompts push repetidos para una cuenta objetivo hasta que el usuario aprueba uno. Normalmente, el atacante ya ha obtenido:
- Un nombre de usuario (a menudo un email).
- Una contraseña u otra credencial de primer paso.
- La capacidad de iniciar repetidamente intentos de inicio de sesión.
El objetivo del atacante no es “romper” el MFA. Es conseguir una única aprobación humana.
Por qué el MFA por push es vulnerable por diseño
El MFA por push es vulnerable porque depende de:
- La atención del usuario en el momento adecuado.
- Que el usuario entienda el contexto.
- Que el usuario tenga la voluntad de rechazar y reportar.
- Controles de política consistentes que limiten prompts repetidos.
En la práctica, estas suposiciones fallan:
- Los usuarios están ocupados o distraídos.
- Los prompts llegan de noche o durante reuniones.
- Los usuarios asumen “IT está probando algo”.
- Los prompts repetidos normalizan el comportamiento de aprobar.
- Las vías de reporte no están claras o son lentas.
El MFA por push deja de ser un control de seguridad y se convierte en un “problema de formación al usuario”, y la formación no escala frente a la automatización.
Cómo ejecutan los atacantes los ataques de fatiga de MFA
Un flujo típico es este:
- El atacante obtiene una contraseña (phishing, reutilización, datos de una brecha).
- El atacante intenta iniciar sesión repetidamente, generando prompts push.
- El usuario recibe múltiples prompts y acaba aprobando uno.
- El atacante entra en la sesión y escala acceso o roba tokens.
- El atacante puede añadir un nuevo factor, establecer persistencia o provocar cambios en recuperación.
Por eso un “MFA fuerte” puede seguir fallando si el segundo factor es un prompt que se puede spamear.
Señales de que eres vulnerable
Muchas organizaciones descubren la vulnerabilidad solo después de un incidente. Puedes detectar riesgo antes si observas:
- Alto volumen de prompts push por usuario.
- Prompts repetidos concentrados en ventanas cortas de tiempo.
- Aprobaciones después de múltiples rechazos.
- Aprobaciones desde geografías inusuales o contextos de dispositivo extraños.
- Alto volumen de tickets al helpdesk por confusión con MFA.
- Usuarios que reportan “prompts aleatorios” sin un camino de respuesta claro.
Si ves estos patrones, el MFA por push ya se está poniendo a prueba o lo estará pronto.
Qué hacer en su lugar: alternativas de nivel empresarial
No tienes por qué abandonar el MFA por push de la noche a la mañana, pero sí deberías alejar el acceso de alto riesgo de los prompts de aprobación como control principal.
1) Prioriza MFA resistente al phishing para accesos de alto riesgo
Los autenticadores resistentes al phishing reducen la capacidad del atacante de convertir el login en una decisión de aprobación que se puede spamear. Desplazan la autenticación hacia prueba criptográfica y presencia del usuario.
2) Usa autenticación reforzada para acciones sensibles, no prompts constantes
Si tu programa depende de prompts push en cada login, la fatiga es inevitable. Un modelo mejor es:
- Baja fricción para sesiones normales y de bajo riesgo.
- Autenticación reforzada para operaciones privilegiadas y eventos de alto riesgo.
- Factores más robustos para accesos de Nivel 0 y Nivel 1.
3) Refuerza las políticas alrededor de prompts push (si tienes que mantenerlos)
Si el MFA por push sigue en tu stack, aplica controles que reduzcan spam y confusión:
- Limitar por tasa los prompts repetidos.
- Bloquear intentos repetidos tras pocos rechazos.
- Exigir number matching (cuando esté disponible).
- Requerir contexto adicional en prompts de alto riesgo.
- Activar alertas ante patrones de prompt bombing.
Estos controles reducen el abuso, pero no eliminan la debilidad de fondo: el control sigue siendo una aprobación humana bajo interrupción.
4) Arregla recuperación y registro de factores para que la fatiga no derive en persistencia
Tras un éxito en fatiga por push, los atacantes suelen intentar ganar persistencia cambiando factores o abusando de la recuperación.
Por eso la recuperación debe tratarse como una superficie de control de alto riesgo, con evidencias claras, límites de tasa y trazas de auditoría.
Cómo passwordless cambia la ecuación de la fatiga
La autenticación passwordless puede reducir la dependencia de prompts push eliminando la contraseña y sustituyendo el flujo principal por prueba criptográfica. Eso no evita automáticamente todos los compromisos, pero reduce el número de situaciones en las que un atacante puede provocar repetidamente prompts de “aprobar/denegar” como barrera principal.
Conclusión: el MFA por push es un control frágil a escala
La fatiga de MFA no es solo un problema del usuario. Es un problema de diseño. El MFA por push convierte la autenticación en un flujo de aprobaciones que se puede spamear, y los atacantes lo explotan a escala.
Si buscas resiliencia, mueve el acceso de alto riesgo hacia métodos resistentes al phishing, usa la autenticación reforzada con criterio, monitoriza patrones de prompts y asegúrate de que recuperación y registro no puedan abusarse tras un único error de aprobación.