MFA resistente al phishing: FIDO2, passkeys y CISA

La MFA resistente al phishing es el único tipo de autenticación multifactor que un atacante no puede interponer ni relayar en tiempo real. El problema es que muchas empresas creen tener MFA cuando en realidad tienen MFA phishable: códigos de un solo uso (OTP) por SMS o app, y notificaciones push. Todos esos factores se roban o se retransmiten con un kit de phishing moderno, y por eso los ataques adversary-in-the-middle (AitM) han convertido el segundo factor en un trámite más que el atacante recoge de camino. Esta guía explica dónde está el fallo, qué significa que un método sea resistente al phishing, cuáles cumplen ese requisito (FIDO2/WebAuthn, passkeys y PIV/smart cards) y cómo se alinean con la guía de CISA y los niveles AAL de NIST 800-63.

Lo esencial sobre MFA resistente al phishing

• El OTP y el push no son resistentes al phishing: un proxy inverso los relaya y roba la cookie de sesión ya autenticada.
• Un método resiste el phishing cuando la autenticación queda vinculada criptográficamente al origen legítimo y usa reto-respuesta sin secreto compartido.
• Los métodos que sí cumplen son FIDO2/WebAuthn (llaves de seguridad y passkeys) y la autenticación por certificado PIV/smart card.
• CISA recomienda FIDO/WebAuthn y PKI; NIST SP 800-63B las exige (resistencia a la suplantación del verificador) para el nivel AAL3.

Por qué tu MFA sigue siendo phishable: el ataque AitM

El ataque que ha dejado obsoleto al MFA tradicional no rompe criptografía ni explota un CVE del servidor: se coloca en medio. En un ataque adversary-in-the-middle (AitM), también llamado evil twin, el atacante levanta un proxy inverso que sirve una copia perfecta de la página real de login (Microsoft 365, Okta, Google) porque en realidad reenvía cada petición al servidor legítimo. La víctima teclea su usuario y contraseña, el proxy los relaya, el servidor pide el segundo factor, la víctima introduce el OTP o aprueba el push, y el proxy también lo relaya. Cuando el login se completa, el servidor devuelve una cookie de sesión ya autenticada y el atacante se la queda: a partir de ahí controla la sesión sin volver a pasar por el MFA.

Las herramientas que lo automatizan son públicas y cada vez más comunes en campañas reales: Evilginx2 (proxy inverso con phishlets por plataforma), Modlishka, Muraena y suites de phishing-as-a-service como EvilProxy, Tycoon 2FA o Mamba 2FA, alquiladas por suscripción. El denominador común: el segundo factor viaja por el canal del atacante, así que da igual lo robusto que sea el OTP, se retransmite intacto.

Dos vectores clásicos completan el cuadro. El MFA fatigue (push bombing) lanza decenas de notificaciones push hasta que la víctima, harta o confundida, aprueba una: fue la técnica de la brecha de Uber en 2022 y del grupo 0ktapus/Scattered Spider. El SIM swapping duplica la tarjeta SIM ante la operadora para recibir los OTP por SMS, motivo por el que NIST desaconseja el SMS desde hace años.

El number matching (teclear en la app un número que muestra la pantalla) mitiga el push bombing, pero no protege frente a AitM, porque en un proxy inverso el número también se relaya. Es una curita, no una cura. Para el mapa completo de variantes de engaño, incluido el evil twin, revisa tipos de phishing y cómo evitar el phishing.

Qué es la MFA resistente al phishing

La MFA resistente al phishing es aquella en la que el proceso de autenticación está diseñado para que ningún intermediario pueda reutilizar la prueba de identidad, ni siquiera capturándola en tránsito. Se apoya en tres propiedades que el OTP y el push no tienen:

1. Vinculación al origen (origin binding). El autenticador comprueba el dominio que solicita la autenticación. Si la petición llega de micr0soft-login.com en vez de login.microsoftonline.com, la firma no se genera: el usuario no puede equivocarse de sitio aunque quiera.
2. Criptografía asimétrica sin secreto compartido. No viaja ninguna contraseña ni código. El dispositivo guarda una clave privada que nunca sale de él y firma un reto del servidor, que solo conoce la clave pública, inútil para un atacante.
3. Reto-respuesta ligado a la sesión. Cada autenticación firma un desafío único, así que no se puede grabar y reproducir después.

En terminología de NIST esto se llama resistencia a la suplantación del verificador (verifier impersonation resistance): el autenticador se niega a operar contra un verificador falso. Es el mismo principio que hace que una passkey sea más segura que una contraseña y que sostiene cualquier arquitectura Zero Trust seria, donde la identidad es el nuevo perímetro.

Métodos de MFA resistente al phishing

Solo dos familias de tecnología cumplen hoy el requisito de resistencia al phishing. El resto son mejores que nada, pero phishables.

FIDO2/WebAuthn: llaves de seguridad y passkeys

FIDO2 es el estándar abierto de la FIDO Alliance, compuesto por la API WebAuthn del navegador (estandarizada por el W3C) y el protocolo CTAP2 hacia el autenticador. Sobre él se construyen dos formas de uso:

• Llaves de seguridad físicas (device-bound): dispositivos como YubiKey, Feitian o Google Titan que guardan la clave privada en un chip que no la exporta jamás. Máxima garantía, ideales para cuentas privilegiadas.
• Passkeys: credenciales FIDO2 descubribles, vinculadas al dispositivo (TPM del portátil o Secure Enclave del móvil) o sincronizadas en la nube del proveedor (iCloud Keychain, Google Password Manager, gestores de contraseñas). Las sincronizadas dependen de la seguridad de esa cuenta de sincronización, pero siguen siendo resistentes al phishing porque la vinculación al origen se mantiene.

Para el detalle técnico de cómo WebAuthn y CTAP construyen todo esto, tienes la guía dedicada a qué es FIDO2.

PIV y smart cards (autenticación por certificado)

La autenticación basada en PKI usa un certificado digital almacenado en una tarjeta inteligente o token: PIV (estándar del Gobierno de EE. UU., FIPS 201), la CAC militar o cualquier smart card corporativa. El usuario demuestra la posesión de la clave privada mediante reto-respuesta. Es resistente al phishing por el mismo motivo que FIDO2 y encaja en organizaciones que ya operan una infraestructura de clave pública, a cambio de un coste operativo mayor (lectores y gestión de certificados).

En entornos Microsoft, Windows Hello for Business logra el mismo resultado con un par de claves asimétricas ancladas al TPM del equipo y desbloqueadas por biometría o PIN local, una vía de despliegue natural en parques con Entra ID.

Lo que NO cuenta como resistente al phishing

Guía CISA sobre MFA resistente al phishing

CISA (la agencia de ciberseguridad de EE. UU.) publicó la ficha Implementing Phishing-Resistant MFA, que fija con claridad el criterio de referencia que hoy citan reguladores y auditores. Sus puntos clave:

• Reconoce dos tipos: el basado en FIDO/WebAuthn (incluidas las passkeys) y el basado en PKI (PIV). Son los dos únicos que recomienda como objetivo.
• Advierte de forma explícita de que las apps de OTP, el push y el SMS no son resistentes al phishing, aunque sigan siendo mejores que solo contraseña.
• Propone el number matching como medida provisional para quien aún no puede migrar, dejando claro que es un paso intermedio, no la meta.

Este criterio no vive aislado. La Orden Ejecutiva 14028 y la estrategia Zero Trust de la OMB (memorando M-22-09) obligan a las agencias federales de EE. UU. a usar MFA resistente al phishing, y el Zero Trust Maturity Model de CISA la sitúa en el nivel avanzado del pilar de identidad. Que un requisito sea ya obligatorio para el Gobierno estadounidense anticipa hacia dónde se moverán los marcos europeos (NIS2, ENS, DORA).

Alineación con NIST SP 800-63

La norma NIST SP 800-63B define los niveles de garantía del autenticador (AAL):

• AAL2: exige MFA, pero admite factores phishables como TOTP. Es el mínimo para la mayoría de servicios.
• AAL3: exige un autenticador criptográfico basado en hardware y resistencia a la suplantación del verificador, es decir, phishing-resistant de facto. FIDO2 con llave física y PIV son los caminos típicos a AAL3.

La revisión más reciente de la familia 800-63 incorpora la resistencia al phishing como propiedad explícita y añade orientación específica para autenticadores sincronizables (passkeys en la nube). En la práctica: si tu objetivo es AAL3 o proteger identidades críticas, necesitas FIDO2 o PKI, no hay atajo.

Autenticación resistente al phishing en la práctica

Llegar a la autenticación resistente al phishing en una empresa real es un proyecto por fases, no un interruptor:

1. Empieza por los privilegiados. Administradores de dominio, cuentas cloud con permisos altos y accesos críticos: el objetivo prioritario del atacante y el mejor retorno inmediato. Aquí encaja la disciplina de gestión de identidades y accesos (IAM).
2. Reparte llaves físicas o registra passkeys y exige el método resistente al phishing en el acceso condicional.
3. Elimina los fallbacks. El error más común es habilitar FIDO2 y dejar el TOTP como respaldo: el atacante fuerza un downgrade al método débil y anula el trabajo. En cuentas críticas, retira los factores phishables.
4. Jubila protocolos legacy (autenticación básica, IMAP/POP heredados) que saltan el MFA moderno.
5. Planifica la recuperación de cuenta, el verdadero talón de Aquiles: un re-registro seguro que no reintroduzca un canal phishable.
6. Extiende al resto de la plantilla con passkeys, midiendo cobertura y ataques bloqueados.

Un matiz importante: la MFA resistente al phishing detiene el robo de credenciales, pero no el robo de la cookie de sesión ya emitida mediante malware infostealer en el endpoint. Por eso conviene complementarla con sesiones vinculadas al dispositivo, tokens de vida corta y monitorización, la misma lógica que frena el credential stuffing por el lado del reuso de contraseñas. Y si no sabes si tu MFA aguantaría un AitM real, la vía más honesta es probarlo: en una evaluación de ciberseguridad ofensiva simulamos una campaña de phishing con proxy inverso controlada y medimos qué factores resisten y cuáles caen antes de que lo haga un atacante.

Preguntas frecuentes

¿El OTP de mi app autenticadora es resistente al phishing?

No. Un código TOTP de Google o Microsoft Authenticator es mucho mejor que el SMS, pero se relaya en un ataque adversary-in-the-middle: el proxy inverso captura el código que tecleas y la cookie de sesión resultante. Solo FIDO2/WebAuthn y PKI (PIV) se consideran resistentes al phishing.

¿Las passkeys son verdaderamente resistentes al phishing?

Sí. Las passkeys son credenciales FIDO2 y heredan la vinculación al origen: el autenticador se niega a firmar para un dominio que no sea el legítimo. Las sincronizadas dependen además de la seguridad de la cuenta de sincronización, pero mantienen la resistencia; las llaves físicas device-bound ofrecen la garantía más alta para cuentas privilegiadas.

¿Qué dice CISA sobre la MFA resistente al phishing?

CISA reconoce dos formas: FIDO/WebAuthn (incluidas las passkeys) y PKI (PIV). Recomienda migrar a ellas, señala que OTP, push y SMS no son resistentes al phishing y propone el number matching solo como mitigación provisional durante la transición.

¿Necesito llegar a AAL3 de NIST?

Depende del riesgo. AAL2 (MFA, incluso phishable) basta para muchos servicios, pero para identidades privilegiadas o datos críticos el nivel AAL3 de NIST SP 800-63B exige un autenticador hardware con resistencia a la suplantación del verificador: en la práctica, FIDO2 con llave física o PKI.

¿El number matching resuelve el problema?

No del todo. Detiene el MFA fatigue porque obliga a introducir un número que ve el usuario, pero no protege frente a AitM, ya que en un proxy inverso ese número también se relaya. Es una mejora útil, no un sustituto de la MFA resistente al phishing.

Recursos relacionados

• Qué es FIDO2: MFA resistente a phishing y passkeys
• Passkey vs contraseña: cuál es más segura en 2026
• Tipos de phishing: spear, BEC, vishing, smishing y AitM
• Cómo evitar el phishing: guía práctica para empresas
• Qué es IAM: gestión de identidades y accesos
• Qué es Zero Trust: arquitectura, principios e implementación

MFA resistente al phishing con Secra

En Secra ayudamos a organizaciones B2B a cerrar el hueco entre "tenemos MFA" y "nuestro MFA resiste un ataque real". Combinamos evaluación ofensiva (campañas de phishing con proxy inverso controlado para medir qué factores caen) con diseño de despliegue: priorización de cuentas privilegiadas, elección entre llaves FIDO2 y passkeys, y eliminación de fallbacks phishables.

Si quieres saber si tu autenticación aguantaría un AitM antes de que lo pruebe un atacante, contacta con Secra y agendamos una sesión inicial sin compromiso.