Passkey vs contraseña: cuál es más segura en 2026

En el debate passkey vs contraseña la conclusión técnica es clara: la passkey elimina de raíz las cuatro formas de robo de credenciales que hunden a la contraseña (phishing, credential stuffing, brechas con reutilización y keyloggers), a cambio de introducir un problema nuevo, la recuperación de cuenta. No es una mejora marginal ni una moda de fabricantes: es un cambio de modelo criptográfico, de un secreto compartido que viaja a una clave privada que nunca sale del dispositivo. Esta guía compara ambos enfoques cara a cara, explica cómo funcionan por dentro y aterriza qué significa la migración en una empresa real durante 2026.

Veredicto en 30 segundos

La lectura rápida: en las amenazas que dominan las estadísticas de account takeover, la passkey gana con claridad. Donde la contraseña sigue siendo más simple es en la recuperación, y ahí es donde se juega la migración.

Cómo funciona cada modelo

La diferencia no está en la longitud ni en la complejidad de lo que teclea el usuario, sino en dónde vive el secreto y quién puede reproducirlo.

La contraseña: un secreto compartido

Una contraseña es un secreto compartido entre dos partes. El usuario elige una cadena, el servidor guarda una versión derivada (idealmente un hash con sal usando bcrypt, scrypt o Argon2id) y, en cada inicio de sesión, el usuario vuelve a transmitir el secreto sobre TLS para que el servidor lo rehashee y compare.

El problema estructural es que ese secreto existe, como mínimo, en dos sitios: la memoria (o el gestor) del usuario y la base de datos del servidor. Cualquiera que lo intercepte lo puede reproducir. Una página de phishing lo captura al teclearlo, un keylogger lo registra, y una brecha de la base de datos entrega los hashes para craqueo offline. La contraseña es replayable por diseño: quien la conoce, entra.

La passkey: criptografía de clave pública (FIDO2/WebAuthn)

Una passkey es una implementación de FIDO2, el estándar que combina dos piezas: WebAuthn (la API del navegador y del servidor, especificada por el W3C) y CTAP2 (el protocolo entre el cliente y el authenticator, definido por la FIDO Alliance).

En el registro, el authenticator (el enclave seguro del móvil, un TPM o una llave física) genera un par de claves asimétricas, típicamente ECDSA sobre la curva P-256 (ES256). La clave privada nunca abandona el authenticator. El servidor solo recibe y almacena la clave pública, un identificador de credencial y el AAGUID del dispositivo.

En cada login, el servidor envía un reto aleatorio (challenge). El authenticator lo firma con la clave privada, pero solo después de una verificación local de usuario (biometría o PIN, que no se transmite nunca). La firma se vincula al RP ID, es decir, al origen: una passkey registrada para accounts.ejemplo.com no firmará un reto presentado desde accounts-ejemplo.evil.com. No hay secreto compartido, no hay token reproducible y no queda nada valioso que robar en el servidor. La base criptográfica es la misma que sostiene los certificados digitales, explicada en detalle en qué es PKI.

Modelo de amenaza cara a cara

Aquí es donde la comparación deja de ser teórica. Estas son las cuatro amenazas que concentran la mayoría de compromisos de credenciales y cómo responde cada modelo.

Phishing y ataques adversary-in-the-middle. La contraseña pierde: el usuario la teclea en una réplica del portal legítimo y el atacante la reenvía. Frente a proxies de phishing modernos como Evilginx, que roban también el token de sesión, ni siquiera el MFA por OTP salva. La passkey gana: la vinculación al origen hace que el navegador se niegue a usar la credencial en el dominio equivocado, y la firma nunca es válida para el sitio del atacante. Es el único control que neutraliza el AiTM de forma estructural, no probabilística. Los distintos vectores están desglosados en tipos de phishing.

Credential stuffing y reutilización. La contraseña pierde: como el usuario repite la misma cadena en varios servicios, un par filtrado en una brecha abre puertas en otras plataformas. La passkey gana: cada relación genera un par de claves único e independiente, no hay nada que reutilizar ni ninguna contraseña que probar en masa. Este ataque, detallado en qué es credential stuffing, simplemente se queda sin combustible.

Brechas de base de datos. La contraseña pierde: aunque los hashes estén bien salados, se craquean offline con GPU y diccionarios, sobre todo las cadenas débiles. La passkey gana: lo único que el atacante extrae del servidor es una clave pública, matemáticamente inservible para suplantar al usuario.

Keyloggers e infostealers. La contraseña pierde: se captura en la pulsación o directamente del almacén del navegador. La passkey gana en el caso device-bound, porque no se teclea nada y la clave privada no es exportable. Con un matiz honesto: las passkeys sincronizadas se guardan en un llavero en la nube, así que su seguridad depende también de la robustez de esa cuenta.

Lo que la passkey no resuelve

Ser riguroso obliga a nombrar los flancos que la passkey introduce o no cierra:

• Pérdida de dispositivo y recuperación. Si la passkey está vinculada al dispositivo y pierdes la llave física, necesitas un authenticator de respaldo. Si está sincronizada, la recuperación depende de tu cuenta de iCloud o de Google, que se convierte en el nuevo eslabón más débil.
• Aplicaciones y protocolos legacy. SSH, VPN antiguas, sistemas sin soporte WebAuthn o algunas apps nativas siguen necesitando alternativas. La cobertura no es universal en 2026.
• Degradación por el fallback. Si mantienes la contraseña como método de reserva, el atacante ataca ese camino (la recuperación de cuenta o el "usar contraseña en su lugar"). La resistencia al phishing solo es tan fuerte como el factor más débil que sigas permitiendo.
• Portabilidad entre ecosistemas. Las passkeys sincronizan dentro de un ecosistema. Moverlas entre Apple, Google y Microsoft mejora con el Credential Exchange Protocol de la FIDO Alliance, pero todavía no es transparente.

La realidad de la migración empresarial en 2026

Ninguna organización pasa de contraseña a passkey de un día para otro. El estado realista es híbrido y conviene diseñarlo con criterio.

Passkeys sincronizadas vs vinculadas al dispositivo

Sincronizadas (multi-dispositivo). Mejor experiencia de usuario y adopción más rápida, con un nivel de garantía de consumidor. La clave privada la custodia el proveedor del llavero (Apple, Google, Microsoft). Encajan bien para el grueso de la plantilla con SSO y una garantía media.

Vinculadas al dispositivo (device-bound). Máxima garantía. Son las llaves FIDO2 físicas (YubiKey, Titan) o authenticators de plataforma sin exportación. Se exigen para cuentas privilegiadas, administración y mandatos de MFA resistente al phishing. Se gobiernan con enterprise attestation y listas de AAGUID permitidos, de modo que solo los authenticators aprobados puedan registrarse. Alcanzan AAL3 según NIST SP 800-63B.

Passkey-first con fallback a contraseña

El patrón que funciona en 2026 es passkey-first: se ofrece la passkey como método por defecto y se conserva un fallback controlado durante la transición. Las decisiones que marcan la diferencia:

• Eliminar el OTP por SMS cuanto antes (vulnerable a SIM swap) y priorizar la passkey sobre cualquier segundo factor tecleado.
• Endurecer la recuperación de cuenta, porque pasa a ser el objetivo real del atacante. El help desk que resetea credenciales por teléfono es hoy el vector más explotado.
• Aplicar políticas de authentication strength en el IdP (Microsoft Entra ID, Okta FastPass, Google Workspace, Ping) para exigir passkey en las aplicaciones sensibles vía conditional access.
• Monitorizar los intentos de degradación al método más débil como señal de ataque.

Esta lógica encaja de lleno con el principio de identidad como perímetro que desarrollamos en qué es Zero Trust y con el stack descrito en qué es IAM. La passkey no sustituye a una estrategia de identidad: es su capa de autenticación más fuerte.

Preguntas frecuentes

¿Son las passkeys más seguras que las contraseñas?

Sí, de forma inequívoca frente a las cuatro amenazas dominantes: phishing, credential stuffing, brechas con reutilización y keyloggers. La contraseña es un secreto reproducible; la passkey es una firma criptográfica no reproducible y vinculada al origen. La única dimensión donde la contraseña es más simple es la recuperación, y por eso ese flujo debe diseñarse con especial cuidado al migrar.

¿Se puede hacer phishing a una passkey?

La aserción en sí no se puede phishear: la vinculación al origen impide que un proxy adversary-in-the-middle reutilice la firma, porque queda ligada al dominio del atacante. Lo que sigue siendo atacable es el entorno alrededor: el método de reserva, la recuperación de cuenta o la ingeniería social contra el help desk. El phishing no desaparece, se desplaza hacia el eslabón más débil que dejes habilitado.

¿Las passkeys reemplazan a las contraseñas?

La dirección del sector apunta a que sí a medio plazo, pero durante años convivirán ambos modelos. Los fallbacks, las aplicaciones legacy sin WebAuthn y los flujos de recuperación mantendrán la contraseña presente en las organizaciones. Una cuenta ya migrada a passkey deja de ser vulnerable a los ataques de reutilización, aunque el sistema en su conjunto todavía dependa de cómo gestiones lo que queda por detrás.

¿Qué pasa si pierdo el dispositivo con mis passkeys?

Depende del tipo. Con passkeys sincronizadas, recuperas el acceso desde otro dispositivo del mismo ecosistema tras autenticarte en tu cuenta de nube, que por eso conviene proteger con su propio MFA fuerte. Con passkeys vinculadas al dispositivo, la buena práctica es registrar un segundo authenticator de respaldo desde el primer día, porque no hay copia recuperable de la clave privada.

¿Elijo passkey sincronizada o vinculada al dispositivo?

Depende del nivel de garantía que necesite el activo. Para el grueso de la plantilla, la passkey sincronizada ofrece el mejor equilibrio entre seguridad y adopción. Para administradores, accesos privilegiados o entornos regulados que exigen AAL3, la passkey vinculada al dispositivo con llave física es la opción correcta, gobernada por attestation y listas de AAGUID aprobados.

Recursos relacionados

• Qué es credential stuffing: el ataque que la passkey deja sin combustible al eliminar el secreto reutilizable.
• Qué es IAM: el stack de identidad donde encaja la autenticación sin contraseña.
• Tipos de phishing: los vectores que la vinculación al origen neutraliza de raíz.
• Cómo evitar el phishing: controles complementarios para el factor humano y los flujos de reserva.
• Qué es PKI: la base criptográfica de clave pública sobre la que se apoyan FIDO2 y WebAuthn.

Passkeys y contraseñas con Secra

En Secra ayudamos a diseñar el roadmap de migración a passkeys y autenticación sin contraseña sin romper la operación: auditoría del estado actual del login, definición de políticas passkey-first con fallback controlado, endurecimiento de la recuperación de cuenta (el nuevo objetivo real) y validación mediante pruebas de account takeover dentro de proyectos Red Team. Si tu organización evalúa pasar de contraseña a passkey, revisa nuestros servicios de ciberseguridad gestionada o escríbenos desde contacto y estructuramos la transición contigo.