En conversaciones enterprise, «passwordless», «MFA» y «passkeys» a menudo se tratan como sinónimos. Esa confusión lleva a expectativas equivocadas, despliegues frágiles y brechas de seguridad que aparecen durante la respuesta a incidentes.

El objetivo de este artículo es precisar los términos, vincularlos a modelos de amenaza reales y destacar los errores que los equipos repiten cuando despliegan autenticación moderna.

Un mapa rápido de definiciones

MFA (autenticación multifactor) describe una categoría: usar dos o más factores distintos (algo que sabes, tienes o eres). MFA puede ser fuerte o débil según cómo se implemente.

Passkeys son una implementación de cara al usuario de credenciales FIDO2/WebAuthn. Normalmente se basan en una clave privada vinculada al dispositivo y pueden sincronizarse entre dispositivos según la plataforma.

Autenticación passwordless es un resultado y una arquitectura: el usuario puede autenticarse sin contraseña, normalmente usando criptografía de clave pública y protocolos resistentes al phishing.

Se solapan, pero no son lo mismo.

Qué garantiza realmente cada término (y qué no)

MFA no significa automáticamente “resistente al phishing”

Muchos despliegues de MFA siguen basándose en métodos que los atacantes pueden saltarse: SMS, códigos OTP y aprobaciones push que pueden sufrir ataques de fatiga. CISA señala explícitamente que algunas formas de MFA son vulnerables al «push bombing», y recomienda enfoques resistentes al phishing.

Así que la pregunta correcta no es «¿Tenemos MFA?» Es: «¿Tenemos autenticación resistente al phishing para accesos de alto riesgo?»

Las passkeys mejoran la seguridad, pero no son un programa enterprise completo

Las passkeys suelen usar WebAuthn, que crea credenciales acotadas a un relying party y mediadas por el user agent, ayudando a reducir reutilización de credenciales entre orígenes.

Eso es un gran paso adelante. Pero en empresas también hay que resolver:

• Dispositivos compartidos y kioscos
• Recuperación de cuenta sin vías débiles de reset
• Contratistas y personal temporal
• Evidencia regulada y auditabilidad
• Operaciones privilegiadas y reglas de step-up

Las passkeys ayudan, pero no definen todo el ciclo de vida.

Passwordless es más amplio que passkeys

Muchos despliegues passwordless usan passkeys. Pero passwordless también puede incluir:

• Llaves de seguridad hardware en niveles de aseguramiento tipo AAL3
• Tarjetas inteligentes (PIV/CAC)
• Credenciales vinculadas al dispositivo con verificación adicional de intención

La distinción importante es que passwordless es una estrategia. Las passkeys son un bloque de construcción común.

Una lente de modelo de amenazas: cuándo se rompe cada enfoque

A continuación tienes una forma práctica de comparar los tres según los tipos de ataques que se espera que resistan.

Phishing de credenciales y AiTM

• Contraseñas: muy vulnerables
• MFA (SMS/OTP/push): a menudo sigue siendo phisheable o atacable por fatiga
• Passkeys / WebAuthn: diseñadas para reducir phishing y suplantación del verificador mediante scoping por origen y relying party
• Passwordless (resistente al phishing): más fuerte cuando se basa en autenticadores resistentes al phishing y políticas claras de step-up

Replay y credential stuffing

• Contraseñas: se reutilizan y se reejecutan a escala
• Códigos OTP: pueden reejecutarse durante phishing en tiempo real
• Passkeys: no crean secretos compartidos reutilizables, reduciendo riesgo de stuffing
• Passwordless: suele reducir superficies de replay cuando se implementa como challenge-response

Fatiga push e ingeniería social

• MFA push: vulnerable a prompts repetidos y confusión del usuario
• Passkeys: eliminan el workflow de aprobación que explota la fatiga
• Passwordless: aun así requiere UX cuidadosa y controles fuertes de recuperación, o los atacantes se moverán a recovery y helpdesk

En qué se equivocan los equipos en despliegues enterprise

Error 1: Tratar el «rollout de passkeys» como toda la estrategia

Los equipos despliegan passkeys para unas pocas apps y asumen que el trabajo está hecho. Luego llega la realidad:

• Apps legacy que no soportan autenticación moderna
• Brechas en acceso desde dispositivos compartidos
• Onboarding incompleto para contratistas
• Procedimientos de recuperación inconsistentes

Solución: define tu ciclo de vida de autenticación y las vías de excepción antes de escalar.

Error 2: Medir éxito por adopción, no por reducción de riesgo

Una adopción alta puede seguir dejando el acceso de alto riesgo protegido por factores débiles. Las guías de NIST enfatizan opciones resistentes al phishing en niveles de aseguramiento altos y exigen autenticadores resistentes al phishing en AAL3.

Solución: mide cobertura de autenticación resistente al phishing para apps de alto riesgo, roles privilegiados y operaciones sensibles.

Error 3: Dejar recovery como «reset links y tickets»

Los atacantes siguen el camino más débil. Si recovery depende de enlaces de reset, bandejas compartidas o verificación inconsistente de identidad en helpdesk, se convierte en la nueva superficie de ataque.

Solución: diseña recovery como parte de primer nivel del programa, con evidencia sólida, rate limits y trazas de auditoría.

Error 4: Asumir que «MFA en todas partes» equivale a «seguro»

“MFA en todas partes” puede seguir significando SMS más contraseña. Eso no es lo mismo que autenticación resistente al phishing.

Solución: clasifica tus métodos MFA por nivel de resistencia y elimina los métodos más débiles para acceso de alto riesgo.

Una guía práctica de decisión

Úsala como punto de partida:

• Si necesitas reducir exposición de contraseñas rápido: empieza con passkeys para workforce SSO y apps clave.
• Si necesitas alto aseguramiento para acceso privilegiado y entornos regulados: impón autenticadores resistentes al phishing y políticas de step-up alineadas con niveles de aseguramiento.
• Si necesitas una estrategia duradera: trata passwordless como un programa de ciclo de vida que incluye patrones para dispositivos compartidos, recovery y evidencia de auditoría.