La autenticación multifactor se ha convertido en una pieza básica de cualquier estrategia de ciberseguridad moderna. Ya no basta con una contraseña medianamente decente: con el volumen de filtraciones, el phishing cada vez más sofisticado y la automatización de ataques, apoyarse solo en “lo que sabes” es casi como dejar la puerta de casa entornada.
En los últimos años han aparecido nuevos métodos de autenticación, guías de organismos como PCI SSC y estándares como FIDO2 o WebAuthn que han cambiado por completo el panorama. El resultado es que hoy existen muchas formas distintas de verificar la identidad de un usuario, con niveles de seguridad y comodidad muy diferentes. La cuestión ya no es solo activar MFA, sino elegir bien qué combinación de factores utilizar en función del riesgo, del contexto y del tipo de servicio.
Fundamentos de identificación, autenticación y autorización
Antes de comparar métodos merece la pena recordar que autenticarse no es lo mismo que identificarse ni que autorizarse, aunque en la práctica todo forme parte del mismo flujo de acceso.
En primer lugar, la identificación es simplemente asignar una identidad única a una persona, sistema o cuenta: un nombre de usuario, un número de empleado, un certificado, etc. Es el “¿quién eres?” sin comprobar todavía que de verdad lo seas.
La autenticación es el proceso de verificar que esa identidad es válida. Para ello, el sistema te pide que presentes uno o varios factores de autenticación que solo tú deberías conocer, tener o ser. Si ese check sale bien, el sistema da por buena la identidad.
Por último, la autorización define a qué puede acceder realmente ese usuario una vez autenticado: qué aplicaciones ve, qué datos puede consultar, si puede administrar otros usuarios, etc. Se puede complementar con herramientas que permiten saber quién tiene acceso a tus ficheros y así auditar permisos y comparticiones.
La gestión coherente de estos tres elementos forma lo que se conoce como Identity and Access Management (IAM), y en marcos como PCI DSS se revisa a fondo en requisitos específicos de control de acceso. En entornos Windows esto suele gestionarse con el Editor de políticas de grupo.
Factores de autenticación: algo que sabes, tienes o eres
Todo sistema de autenticación moderno gira en torno a tres grandes familias de factores, que se pueden combinar para construir esquemas de doble o multifactor:
Por un lado está “algo que sabes” (something you know): contraseñas, PIN, frases de paso o preguntas de seguridad. Su gran ventaja es que son fáciles de desplegar y muy familiares para cualquier usuario, pero también son el objetivo preferido de los atacantes, ya sea mediante fuerza bruta, phishing, fuga de bases de datos o relleno de credenciales.
En segundo lugar encontramos “algo que tienes” (something you have): un móvil al que se envía un SMS, una app de autenticación, una tarjeta inteligente, un token físico o una llave FIDO. Aquí el atacante necesitaría robar o clonar ese elemento para poder pasar el filtro, lo que en teoría eleva notablemente la seguridad.
La tercera categoría es “algo que eres” (something you are), es decir, factores biométricos como huella dactilar, reconocimiento facial, iris o incluso características de comportamiento (forma de teclear, de caminar, patrones de voz). Son muy cómodos y difíciles de replicar, pero plantean retos serios de privacidad y de gestión: no puedes “cambiar de huella” fácilmente si se ve comprometida.
Además, cada vez ganan peso los factores contextuales o de comportamiento, a veces agrupados como “algo que haces” o “algo que ocurre a tu alrededor”: ubicación, dispositivo desde el que te conectas, horario habitual, IP conocida, etc. Por sí solos no suelen considerarse factores “fuertes”, pero son la base de la autenticación adaptativa basada en riesgos.
Contraseñas, PIN y autenticación basada en conocimiento
La llamada autenticación basada en conocimiento (KBA) es el modelo tradicional: introduces un usuario y contraseña, o respondes una pregunta como “¿en qué ciudad naciste?”. Es baratísimo de implementar, está soportado por cualquier plataforma y los usuarios ya saben cómo funciona.
El problema es que, en la práctica, las contraseñas se reutilizan de forma masiva entre servicios y suelen ser débiles. Distintos estudios indican que un porcentaje enorme de personas usa la misma clave en decenas de sitios, de modo que basta con que una sola web tenga una brecha para que el resto de cuentas queden en riesgo mediante ataques de relleno de credenciales.
Las preguntas de seguridad tradicionales son incluso peores: muchas respuestas se pueden encontrar rebuscando un poco en redes sociales o en fuentes públicas, y otras se adivinan con relativa facilidad. Por eso, hoy se recomienda limitarlas a casos muy concretos o sustituirlas por otros mecanismos de recuperación.
Los PINs son un caso particular interesante. Sobre el papel, un PIN de 4 dígitos tiene muy poca entropía y no alcanzaría los requisitos de complejidad que solemos pedir a las contraseñas. Sin embargo, las guías recientes de PCI SSC aclaran que un PIN puede aceptarse como factor “algo que sabes” siempre que se combine con controles adicionales como bloqueos tras varios intentos fallidos, tiempos de espera progresivos y almacenamiento seguro.
Cuando no es posible blindar ese PIN con medidas antifuerza bruta, entonces debe cumplir los mismos criterios que una contraseña robusta: longitud mínima suficientemente alta, prohibición de patrones triviales, historial, etc. De lo contrario, se convierte en un punto débil fácil de explotar.
Códigos de un solo uso: SMS, correo electrónico y listas pregeneradas
Uno de los métodos más extendidos de MFA sigue siendo el uso de códigos de un solo uso (OTP) enviados por distintos canales o impresos previamente. Es un segundo factor muy simple de entender para el usuario y que muchos servicios ofrecen de forma predeterminada.
En el caso del OTP por SMS o llamada de voz, el funcionamiento es directo: tras introducir usuario y contraseña, el sistema envía un código de varios dígitos al número registrado. El usuario lo introduce y, si coincide, se concede el acceso. En esencia, se verifica que sigues teniendo control sobre ese número de teléfono.
También podemos encontrar OTPs enviados por correo electrónico, algo menos habitual pero todavía presente. Aquí el riesgo es evidente: si la contraseña de tu correo es la misma que la de la cuenta que intentas proteger, la seguridad adicional se evapora porque el atacante puede entrar primero en tu buzón y leer tranquilamente el código.
Un enfoque más clásico es el de las listas de códigos pregenerados, que algunos bancos entregan impresas o que ciertos servicios (como grandes plataformas online) permiten descargar para recuperación de cuenta. Cada código se usa una sola vez y el siguiente intento debe recurrir a otro de la lista.
Estas listas son bastante seguras frente a ataques de interceptación porque se generan y entregan en momentos muy puntuales. El punto crítico es el almacenamiento: si guardas la hoja en un cajón sin llave o haces una foto y la dejas en la galería sin cifrar, cualquiera que tenga acceso físico a tus cosas podría secuestrar tus cuentas o tus fondos.
Para gestionar bien estas listas conviene almacenarlas en un lugar físico seguro o en un contenedor digital cifrado, como las notas seguras de un gestor de contraseñas. Aun así, tienen un problema de escalabilidad claro: si haces muchas operaciones o tienes muchas cuentas, se agotan rápido y se vuelven difíciles de manejar, por lo que cada vez se usan menos como método principal y más como mecanismo de emergencia.
Aplicaciones de autenticación y TOTP
Las últimas guías y la experiencia práctica coinciden en que las aplicaciones de autenticación basadas en códigos temporales (TOTP) ofrecen una relación muy buena entre seguridad y comodidad, por eso se recomiendan como opción “por defecto” cuando sea posible.
El principio es sencillo: durante el alta del segundo factor, el servicio y tu app de autenticación comparten una clave secreta (normalmente escaneando un código QR). A partir de ahí, tanto la app como el servidor van generando el mismo código de 6 u 8 dígitos cada 30 segundos sin necesidad de conexión, gracias a un algoritmo estándar.
Herramientas como Google Authenticator, Microsoft Authenticator, Authy, Aegis o Duo Mobile permiten registrar múltiples cuentas y tener todos tus códigos centralizados. Algunas incluyen copia de seguridad cifrada en la nube o sincronización entre dispositivos, algo muy práctico pero que debe configurarse con cabeza para no introducir nuevos riesgos.
Existen también gestores de contraseñas que integran TOTP (1Password, Bitwarden, Dashlane y otros). En estos casos, el mismo producto almacena la contraseña y genera el código temporal, lo que hace el inicio de sesión extremadamente cómodo. Sin embargo, desde el punto de vista purista de seguridad, pierdes parte de la independencia entre factores, ya que ambos se concentran en un solo punto de fallo.
En cualquier caso, frente a SMS o correo, los TOTP tienen claras ventajas: no dependen de la red móvil ni del operador, son menos sensibles a ataques de SIM swapping, funcionan sin cobertura y no exponen el código en canales fácilmente interceptables.
Biometría: huella, rostro, voz y otros rasgos
La autenticación biométrica ha dejado de ser ciencia ficción para convertirse en parte del día a día: casi cualquier smartphone actual permite desbloquearse con huella o cara, y muchos portátiles integran lectores de huellas o cámaras compatibles con reconocimiento facial seguro.
La biometría se apoya en características físicas o de comportamiento difíciles de replicar: huellas dactilares, rasgos faciales, iris, voz, dinámica de tecleo, forma de andar, etc. Desde el punto de vista del usuario es comodísima porque evita tener que recordar nada y reduce la fricción en el acceso.
Sin embargo, hay matices importantes. Lo primero es que los datos biométricos son intrínsecamente sensibles: no puedes “revocar” tu cara o tus dedos si se ven comprometidos, y además sirven no solo para autenticar sino para identificarte civilmente. Eso implica que su captura, almacenamiento y tratamiento deben hacerse con un nivel de protección muy alto.
Por ese motivo, la mayoría de arquitecturas modernas limitan la biometría a procesos de autenticación local en el propio dispositivo. Por ejemplo, cuando usas Face ID o un lector de huella, los datos se guardan y procesan en un enclave seguro del teléfono y no se envían al servicio remoto. Lo que viaja es un “sí” o “no” del sistema operativo diciendo que el usuario legítimo ha desbloqueado el dispositivo.
En el caso de la autenticación biométrica remota pura, el servicio que recibe esos datos tiene que confiar implícitamente en el fabricante del dispositivo o en el proveedor del sistema, algo que pocas organizaciones están dispuestas a hacer salvo en ecosistemas muy cerrados. Un ejemplo destacado es el de Apple, que controla extremo a extremo hardware y software y ofrece mecanismos como Face ID integrados con claves de acceso.
Aunque tiene inconvenientes, la biometría aporta una ventaja clave: reduce drásticamente la fricción. Un usuario que desbloquea el móvil con el dedo o la cara cientos de veces al día está mucho más dispuesto a aceptar MFA si esa es la “molestia” adicional que tiene que asumir, en lugar de teclear contraseñas kilométricas en cada acceso.
Ubicación, contexto y autenticación basada en riesgos (RBA)
Más allá de los factores clásicos, muchos sistemas modernos aplican autenticación basada en riesgos (Risk-Based Authentication, RBA), ajustando dinámicamente las exigencias en función de lo que observan en tiempo real.
En esencia, el sistema analiza variables contextuales como la ubicación, el dispositivo, la IP, el horario o el patrón de uso. Si alguien intenta entrar desde el mismo portátil de siempre, en el horario habitual y desde la red de la oficina, el riesgo se considera bajo y quizá no se le pida nada extra más allá de la contraseña o la sesión de SSO.
En cambio, si se detecta un inicio de sesión desde otro país, a una hora extraña o desde un equipo no reconocido, el motor de riesgos puede elevar el nivel de exigencia y requerir un segundo factor adicional, como un OTP, una aprobación en app o un chequeo biométrico.
Este enfoque tiene la gran ventaja de equilibrar seguridad y usabilidad: no castiga al usuario con pasos innecesarios cuando todo cuadra, pero eleva la guardia cuando algo chirría. Para bancos, grandes plataformas online o empresas con miles de empleados es ya casi un estándar.
Su principal pega es que no es trivial de diseñar ni de ajustar. Si se calibran mal los umbrales de riesgo, puede acabar pidiendo MFA de forma constante a usuarios legítimos o, en el extremo opuesto, dejar pasar comportamientos sospechosos. Aquí la analítica avanzada y, cada vez más, la inteligencia artificial juegan un papel clave en la detección de anomalías y patrones raros.
Autenticación multifactor: multi-factor vs multi-step
Cuando combinamos dos o más factores distintos hablamos de autenticación multifactor (MFA). La idea es que, incluso si un atacante consigue romper uno de los factores (por ejemplo, la contraseña), siga teniendo que superar un segundo filtro independiente (como un OTP o una llave física).
Desde el punto de vista de cumplimiento, marcos como PCI DSS conectan el concepto de MFA con requisitos muy concretos: acceso remoto a redes internas, entrada en entornos de datos de tarjetas, cuentas con privilegios elevados, etc. En estos casos, ya no se admite depender solo de usuario y contraseña.
Durante años hubo bastante lío con la diferencia entre autenticación “multi-step” y MFA válida a efectos de PCI. En guías antiguas se exigía que todos los factores se evaluaran sin que el usuario recibiera feedback parcial, es decir, que no se le dijera si la contraseña estaba bien antes de pedir el segundo factor.
Las versiones más recientes de la guía aclaran el criterio: es aceptable que se indique el éxito de un factor antes de solicitar el siguiente, siempre que el acceso no se conceda hasta que todos se hayan verificado correctamente. Eso significa que flujos como “primero contraseña, luego OTP” son conformes, aunque se confirme al usuario que su contraseña es válida.
Aun así, se mantiene como buena práctica reducir ese feedback granular: o bien no revelar la validez de ningún factor hasta que se hayan presentado todos, o bien autenticar primero con un factor de sesión única (OTP, llave resistente a phishing) antes de validar otros factores estáticos como la contraseña.
Llaves de hardware FIDO U2F / FIDO2 y passkeys
Frente a los problemas de phishing y ataques “man-in-the-middle” de muchos métodos tradicionales, han surgido soluciones como las llaves de seguridad FIDO U2F/FIDO2, popularizadas por dispositivos como YubiKey, Google Titan o modelos de Feitian y SoloKeys.
Estas llaves implementan criptografía de clave pública y, durante el registro, generan una clave única asociada a cada servicio. Cuando vuelves a autenticarte, el servidor envía un reto que la llave solo firma si el dominio y el contexto coinciden con los registrados. Si alguien intenta engañarte con una web falsa, la llave detecta que no es el sitio legítimo y no firma nada. Muchas plataformas usan TPM 2.0 para proteger las claves asociadas al dispositivo.
Así, este tipo de autenticación no solo verifica al usuario, sino que también verifica al propio servicio, ofreciendo una resistencia muy alta frente a phishing, ataques de replay y de relay. Por eso muchas organizaciones las consideran el estándar de oro para proteger cuentas críticas, credenciales administrativas o accesos al correo corporativo.
Desde el punto de vista del usuario, el proceso es sorprendentemente simple: conectar la llave al puerto USB o acercarla por NFC al móvil, tocar el sensor capacitivo y listo. Detrás hay criptografía compleja, pero el gesto es más fácil que teclear un OTP.
Sobre esta misma base, la FIDO Alliance ha impulsado las claves de acceso o passkeys, que llevan la idea un paso más allá al reemplazar directamente las contraseñas. La clave privada se almacena en el dispositivo (o se sincroniza de forma cifrada a través de la nube del proveedor) y el usuario se autentica desbloqueando ese dispositivo con biometría o PIN.
Las passkeys siguen siendo multifactor por diseño, ya que combinan algo que tienes (el dispositivo) con algo que eres o sabes (biometría o PIN), pero eliminan la contraseña clásica de la ecuación. Cada vez más servicios importantes están empezando a ofrecerlas, aunque el ecosistema sigue algo fragmentado y cada plataforma implementa matices diferentes.
SSO, autenticación basada en token y certificados digitales
En entornos corporativos es habitual combinar estos factores con mecanismos como el Single Sign-On (SSO), que permite iniciar sesión una sola vez contra un proveedor de identidad de confianza (por ejemplo, Azure AD, Okta, Google Workspace) y acceder a múltiples aplicaciones sin repetir credenciales continuamente.
En estos esquemas, el proveedor de identidad emite tokens de seguridad (como JWT) tras una autenticación inicial fuerte (idealmente con MFA). Esos tokens se presentan a las aplicaciones integradas para demostrar quién eres sin necesidad de volver a preguntar la contraseña en cada salto.
La autenticación basada en token reduce la carga en los servidores y facilita arquitecturas sin estado muy utilizadas en APIs y aplicaciones modernas. Eso sí, la gestión de expiración, renovación y revocación de tokens debe estar muy bien diseñada para evitar que un token robado se convierta en un pase ilimitado.
Otro método muy sólido, sobre todo en redes internas y accesos a VPNs, es la autenticación basada en certificados digitales. En lugar de una contraseña, el usuario presenta un certificado emitido por una autoridad de certificación corporativa, y el servidor verifica criptográficamente su validez.
Este enfoque es extremadamente robusto frente a muchos ataques comunes, pero implica mantener una infraestructura de clave pública (PKI) bien gobernada: emisión, renovación, revocación, políticas de uso, gestión de dispositivos, etc. Por eso suele reservarse para entornos de alta seguridad donde compensa el esfuerzo.
Gestión de sesiones y Zero Trust
Una vez superado el proceso de autenticación inicial, casi todos los sistemas establecen una sesión que representa la relación de confianza entre el usuario y el servicio. En lugar de pedir MFA a cada clic —algo inviable—, se reutiliza esa sesión para autorizar peticiones posteriores.
Esto hace que muchos atacantes se centren en robar o secuestrar sesiones activas mediante cookies, tokens o mecanismos similares, en lugar de tratar de saltarse directamente la autenticación multifactor. Por eso es tan importante complementar MFA con buenas prácticas de gestión de sesión.
Entre las recomendaciones habituales encontramos vincular las sesiones a usuarios y dispositivos concretos para que no puedan reutilizarse desde equipos distintos, aplicar timeouts de inactividad razonables, forzar reautenticación MFA en operaciones especialmente sensibles y usar siempre canales cifrados como TLS.
Todos estos elementos encajan muy bien con el enfoque de Zero Trust Architecture (ZTA), en el que no se asume confianza implícita solo por estar “dentro” de la red corporativa. Cada petición relevante se evalúa en función del contexto, del estado del dispositivo y de la identidad, reduciendo el impacto de una eventual sesión comprometida.
Comparativa práctica de métodos MFA y recomendaciones
Con todo lo anterior sobre la mesa, es razonable preguntarse qué métodos de autenticación multifactor son mejores y cómo elegir la combinación adecuada para cada caso de uso sin volver loco al usuario.
Si ordenamos los factores de más débiles a más robustos, podemos situar en la parte baja SMS, correo electrónico y preguntas de seguridad. Cumplen con el requisito formal de “algo que tienes/sabes”, pero son muy vulnerables a SIM swapping, reenvíos, phishing y reutilización de contraseñas.
En un escalón intermedio están las aplicaciones TOTP, los tokens físicos sencillos y ciertos métodos biométricos bien implementados. Ofrecen un buen equilibrio entre seguridad y usabilidad, y son la recomendación estándar para proteger la mayoría de cuentas personales y muchas cuentas corporativas.
Por encima encontramos las llaves FIDO U2F/FIDO2 y las passkeys resistentes a phishing, que combinan criptografía robusta, vinculación al dominio y autenticación asociada al dispositivo. Para cuentas de alto valor —finanzas, administración de sistemas, acceso a paneles críticos— son el método preferente.
A partir de aquí, la elección de un negocio concreto debe considerar qué tipo de datos protege, qué fricción pueden tolerar sus usuarios y qué presupuesto tiene para desplegar y mantener la infraestructura. La mayoría de organizaciones terminan combinando varios enfoques: MFA fuerte para accesos sensibles, SSO para comodidad en el día a día, RBA para equilibrar seguridad y experiencia.
En cualquier escenario, hay consensos claros: activar MFA siempre que sea posible, priorizar métodos resistentes a phishing cuando el riesgo lo justifique, proteger muy bien la recuperación de cuentas, por ejemplo recuperar acceso a Windows, y formar a los usuarios para que entiendan por qué se les pide ese “segundo paso” y cómo detectar intentos de fraude.
En un entorno donde la suplantación de identidad copa gran parte de los incidentes, reforzar la autenticación con los métodos adecuados permite reducir drásticamente las posibilidades de compromiso de cuentas sin renunciar a una experiencia de uso razonable, y se ha convertido en un requisito básico tanto para usuarios individuales como para cualquier organización que quiera tomarse la seguridad mínimamente en serio.
