La trampa de la MFA describe un problema que muchas organizaciones están empezando a notar: la autenticación multifactor (MFA) funciona muy bien… y aun así puede llevar a una falsa sensación de seguridad sobre “quién” está realmente detrás de una cuenta. El control ha ganado tanto protagonismo que, en la práctica, se ha convertido en un atajo mental: si el usuario pasó los requisitos, entonces la identidad quedó verificada.
El inconveniente es que “pasó la MFA” no equivale necesariamente a “es la persona correcta” ni a “la identidad se mantiene confiable durante toda la sesión”. Cuando los procesos alrededor de la autenticación fallan, un atacante puede aprovecharlos sin romper la lógica del sistema.
Por qué la autenticación no es lo mismo que identidad
La autenticación demuestra que alguien controla los factores asociados a una cuenta. Es decir, confirma que la persona o el agente que intenta entrar tiene acceso a los autenticadores registrados (por ejemplo, un token, un método de segundo factor o credenciales). En cambio, la verificación de identidad (o identity proofing) busca responder si esa persona corresponde a la identidad real que dice representar.
Estas dos cosas se complementan, pero no se sustituyen. Si una organización confunde ambas, puede terminar tratando la autenticación como una prueba completa del mundo real. Y cuando el atacante ataca el proceso equivocado, la MFA puede salir “bien” mientras la identidad sigue siendo incorrecta.
Cómo un atacante puede “pasar” la MFA y seguir siendo el impostor
El escenario típico no requiere que el atacante “rompa” la MFA en el sentido clásico. En lugar de eso, apunta a los procesos que rodean la autenticación: inscripción, recuperación de cuenta, mesa de ayuda, registro de dispositivos y gestión de sesiones.
Imagina que un atacante realiza ingeniería social para que la mesa de ayuda reinicie la MFA de un empleado. Si luego inscribe un dispositivo bajo su control, el próximo inicio de sesión puede cumplir todos los requisitos: las credenciales existen, el segundo factor se completa con éxito y el sistema “aprueba” la autenticación. Sin embargo, lo que falla es la garantía sobre la identidad: el acceso lo obtuvo un impostor.
En otras palabras: la autenticación puede funcionar exactamente como fue diseñada, mientras la “prueba de identidad” asociada al proceso de inscripción o recuperación no se verificó con suficiente solidez.
Cuando el modelo de ataque está dentro de la autenticación
Muchas organizaciones visualizan al atacante como alguien intentando atravesar una barrera externa: “entrar aunque tenga MFA”. Pero la realidad cambia: con métodos como phishing, ingeniería social, intercambio de SIM (SIM swapping), robo de sesión o ataques de recuperación, el atacante puede lograr que el proceso de autenticación termine con un “éxito” real.
La parte incómoda es que no siempre hay un fracaso evidente del control. Incluso cuando se despliegan variantes resistentes al phishing, persiste el riesgo de identidad, porque la confianza depende de cómo se vinculó el autenticador a la identidad original, cómo puede reemplazarse y qué ocurre durante la recuperación.
Es frecuente que una organización proteja bien la “puerta principal” del acceso, pero deje una “entrada lateral” menos controlada. Si esa entrada se relaciona con cambios de autenticador, restauraciones o gestiones internas, el atacante puede aprovechar la debilidad sin tocar la MFA en su esencia.
La trampa de la MFA como confusión de categorías: no es detección de amenazas
Existe otra confusión común: asumir que una MFA exitosa también equivale a detección de amenazas sobre esa identidad. Pero son preguntas distintas.
- Autenticación: ¿quién controla los autenticadores necesarios en este momento?
- Detección de amenazas a la identidad: ¿qué está ocurriendo con esa identidad después del inicio de sesión?
Es perfectamente posible que el usuario se autentique correctamente a las 8:02 a. m. y que, minutos después, alguien robe la sesión. Con esa sesión comprometida, el atacante podría escalar privilegios o acceder a datos sensibles que el empleado nunca tocó antes. El evento de MFA fue exitoso, pero ofreció poca garantía sobre la legitimidad de lo que pasó a continuación.
La identidad es dinámica. Una identidad confiable en el login puede volverse riesgosa rápidamente si la sesión se ve comprometida o si se producen eventos de recuperación o cambio de contexto.
Tres preguntas que una organización debería separar
Para reducir las zonas ciegas, conviene distinguir tres interrogantes que suelen mezclarse:
- ¿Quién es esta persona? Aquí entra la verificación de identidad, es decir, el nivel de confianza sobre el vínculo entre la persona y la identidad reclamada.
- ¿Esta persona puede demostrar control de los autenticadores requeridos? Esta es la pregunta que responde la autenticación. La MFA es especialmente valiosa para este punto.
- ¿Esta identidad se mantiene comportándose de forma legítima? Esto lo aborda la detección/monitoreo de amenazas a la identidad, usando señales y comportamiento a lo largo del tiempo.
Estas funciones no se reemplazan entre sí. Son controles complementarios: si se confunden, la organización cree que está respondiendo tres preguntas con una sola.
Gestionar la confianza como un ciclo, no como un “sí o no”
Una forma práctica de salir de la trampa de la MFA es tratar la confianza de identidad como algo con etapas y actualizaciones. En lugar de un estado binario (“pasó MFA, entonces todo está bien”), la confianza debe evolucionar según el momento y el riesgo.
En la etapa de inscripción, la organización establece confianza sobre qué identidad corresponde a una persona específica. En la autenticación, se establece confianza sobre el control de los autenticadores. Y después del login, deberían entrar señales nuevas que permitan revisar la confianza en función de eventos y comportamientos.
Entre esas señales se pueden incluir cambios de dispositivo, accesos inusuales, escalamiento de privilegios y eventos vinculados a recuperación. Si la interacción es de alto riesgo, puede ser necesario reestablecer el nivel de confianza. Eso aplica, por ejemplo, a restablecer credenciales, inscribir un nuevo autenticador o conceder acceso administrativo.
En resumen: establecer, autenticar y monitorear la confianza cuando el riesgo lo justifica.
El “trabajo” de la MFA y sus límites claros
Reconocer límites no resta valor a la MFA. De hecho, fortalece su utilidad al colocarla donde corresponde: la MFA cumple un rol crítico en demostrar control de factores. El problema aparece cuando se le pide que responda preguntas para las que no fue diseñada.
La MFA no puede, por sí sola, determinar si un atacante manipuló la recuperación de cuenta, si la inscripción del autenticador se hizo tras una verificación adecuada de identidad, o si una sesión autenticada fue luego secuestrada. Tampoco sustituye a la detección de amenazas posterior al acceso.
Por eso conviene recordar la distinción:
- Verificación de identidad: define quién eres.
- Autenticación/MFA: define si puedes demostrar control de los autenticadores necesarios.
- Detección de amenazas a la identidad: define si esa identidad sigue siendo confiable con el tiempo.
Cuando se confunden estos roles, la organización corre el riesgo de autenticar con seguridad… al atacante que intentaba mantener afuera.
Recomendaciones para evitar la trampa de la MFA
Para reducir la probabilidad de caer en la trampa de la MFA, las medidas deberían enfocarse en los puntos donde la confianza se rompe: procesos de inscripción y recuperación, decisiones de soporte y el monitoreo posterior al inicio de sesión.
- Fortalece la verificación en restablecimientos de MFA, inscripción de nuevos autenticadores y reemplazos de dispositivos.
- Revisa la seguridad de la mesa de ayuda, especialmente cuando interviene en cambios de autenticación y procesos de recuperación.
- Aplica controles sobre cambios de contexto: si hay señales de riesgo (dispositivo distinto, privilegios nuevos, accesos raros), ajusta el nivel de confianza.
- Integra detección posterior al login para identificar secuestro de sesión o comportamientos que no encajan con el patrón del usuario.
- Reevalúa la autenticación en interacciones de alto riesgo, en lugar de asumir que un MFA reciente garantiza todo lo que ocurrirá después.
Conclusión
La trampa de la MFA no consiste en que la MFA falle, sino en que las organizaciones la tratan como una prueba universal. Cuando se confunde autenticación con verificación de identidad, o cuando se asume que MFA también detecta amenazas posteriores, aparecen brechas que un atacante puede explotar mediante procesos de recuperación, cambios de autenticador y manipulación de sesiones.
La respuesta no es abandonar la MFA, sino usarla correctamente: como demostración de control, combinándola con verificación de identidad y monitoreo continuo para construir confianza a lo largo del tiempo.
