Qué es una passkey: login sin contraseña

Una passkey es una credencial de acceso sin contraseña que sustituye tu clave por un par de claves criptográficas: una clave privada que nunca sale de tu dispositivo y una clave pública que guarda el servicio. En lugar de escribir un secreto que viaja por la red y que alguien puede robar, tu teléfono o tu portátil demuestran quién eres firmando un reto criptográfico que solo desbloqueas con tu huella, tu rostro o un PIN local. Las passkeys son la implementación práctica del estándar abierto de la FIDO Alliance y el W3C, y en 2026 son el método de inicio de sesión que Apple, Google y Microsoft ofrecen por defecto en cientos de servicios.

Esta guía es la referencia de definición: explica qué es una passkey, cómo funciona por dentro, en qué se diferencian las passkeys de plataforma y las de hardware, cuándo elegir una credencial sincronizada o anclada al dispositivo y cómo abordar una migración empresarial sin quedarte atrapado en la recuperación de cuentas. La comparación amenaza por amenaza frente a la contraseña la tratamos aparte, en passkey vs contraseña.

Lo esencial sobre las passkeys

• Una passkey es una credencial descubrible FIDO2/WebAuthn: un par de claves ligado a un único servicio, con la clave privada custodiada en hardware seguro.
• No hay secreto compartido: el servidor solo guarda la clave pública, así que una brecha de su base de datos no filtra nada reutilizable.
• Es resistente a phishing porque la credencial está ligada al dominio (origen) y no firma para un sitio suplantado.
• Existen passkeys sincronizadas (cómodas, replicadas en la nube) y ancladas al dispositivo (device-bound, sin sincronización, máxima garantía).
• Encaja con NIS2, ISO 27001 A.5.17, ENS y los niveles AAL de NIST SP 800-63B, y es la forma de MFA resistente a phishing que CISA señala como estándar de referencia (FIDO/WebAuthn).

Qué es una passkey

Una passkey es una credencial de autenticación basada en criptografía de clave pública que reemplaza a la contraseña. Técnicamente es una credencial descubrible (discoverable credential, antes llamada resident key) del estándar WebAuthn, que forma parte del marco FIDO2. Cuando te registras en un servicio con una passkey, tu autenticador (el teléfono, el portátil o una llave física) genera un par de claves único para ese servicio. La clave privada se queda protegida por hardware seguro (el Secure Enclave de Apple, un TPM 2.0 en Windows, StrongBox o el Titan M2 en Android, o el elemento seguro de una llave), y la clave pública se envía al servidor asociada a tu cuenta.

La diferencia esencial con una contraseña es que no existe un secreto que el usuario pueda leer, escribir o pegar. La passkey no se "sabe": se usa, y solo se activa tras una verificación de usuario local (biometría o PIN) que desbloquea la clave privada para una operación concreta. Por eso una passkey no se puede reutilizar en otro sitio, no se puede filtrar en una brecha y no se puede teclear en una web falsa.

Una passkey no es un gestor de contraseñas

Es una confusión habitual. Un gestor de contraseñas guarda secretos que siguen siendo contraseñas: se autocompletan, pero viajan al servidor y pueden acabar en una web de phishing. Una passkey no tiene ningún secreto que enviar. Muchos gestores modernos (1Password, Bitwarden, Dashlane) actúan hoy como proveedores de passkeys mediante las APIs de plataforma, pero lo que almacenan ya no es una cadena de texto reutilizable, sino una clave privada que solo produce firmas ligadas a un origen.

Cómo funciona una passkey

Una passkey opera en dos ceremonias del protocolo WebAuthn, ambas disparadas por el navegador o el sistema operativo a través de la Web Authentication API.

En el registro, la aplicación web invoca navigator.credentials.create(). El autenticador genera el par de claves para el identificador del servicio (rpId, normalmente el dominio), guarda la clave privada y devuelve la clave pública junto con un identificador de credencial. A partir de ese momento el servicio ya no necesita almacenar ningún secreto tuyo.

En la autenticación, la aplicación llama a navigator.credentials.get() con un reto (challenge) aleatorio. El autenticador te pide la verificación (huella, rostro o PIN), firma el reto con la clave privada y devuelve la firma. El servidor la valida con la clave pública que guardó. Nunca circula un secreto reutilizable por la red. Si quieres el detalle del protocolo, de WebAuthn y de CTAP, lo desarrollamos en la guía de FIDO2.

El elemento crítico es el anclaje al origen: el navegador solo permite usar la passkey en el dominio para el que se creó. Aunque caigas en un dominio parecido, el autenticador no firmará, y la credencial no sirve para nada fuera de su servicio legítimo. Ese anclaje es lo que hace de la passkey un factor resistente a phishing en el sentido que describe la ficha de CISA sobre MFA resistente a phishing, y es la razón por la que un proxy de phishing no obtiene nada reutilizable. Cómo se traduce esa propiedad en cada tipo de ataque (phishing AiTM, credential stuffing, brechas, keyloggers) frente a la contraseña y a la MFA por código lo desglosamos en el modelo de amenaza cara a cara de passkey vs contraseña.

Passkeys de plataforma frente a passkeys de hardware

No todas las passkeys son iguales. La distinción práctica más importante es dónde vive la clave privada y si se sincroniza.

Passkeys de plataforma (sincronizadas). Las que crea el sistema operativo y replica en la nube del proveedor: iCloud Keychain en el ecosistema Apple, el Gestor de contraseñas de Google en Android y Chrome, o Windows Hello, además de los gestores de terceros ya citados. Se sincronizan entre tus dispositivos, así que sobreviven a la pérdida o el cambio de un equipo. Su seguridad depende de la cuenta de nube que las custodia.

Passkeys de hardware (device-bound). Las que residen en una llave física de seguridad (YubiKey 5, Google Titan, Feitian, Token2) y nunca abandonan el elemento seguro del dispositivo. No se sincronizan, así que exigen respaldo físico, pero son inmunes al compromiso del proveedor de nube y al malware del puesto.

Para iniciar sesión en un equipo distinto del que guarda la passkey existe el transporte híbrido (hybrid transport, definido en la especificación CTAP 2.2 de la FIDO Alliance y conocido antes como caBLE): escaneas un código QR con el móvil y una comprobación de proximidad por Bluetooth confirma que ambos dispositivos están cerca. Así el teléfono autentica un login del portátil sin exponer la clave.

Sync frente a device-bound: qué elegir

El criterio de decisión es la criticidad. Para la plantilla general, las passkeys sincronizadas de plataforma ofrecen una mejora enorme sobre la contraseña con una fricción mínima. Para administradores, cuentas privilegiadas y entornos regulados, la recomendación sigue siendo hardware device-bound, alineado con el nivel AAL3 de NIST SP 800-63B. La revisión 4 de NIST SP 800-63B dedica un apéndice a los autenticadores sincronizables (syncable authenticators) y los admite como opción válida en AAL2 siempre que se cumplan sus condiciones sobre custodia de la clave, cifrado de la sincronización y control del proveedor, un matiz que conviene documentar en tu política de acceso.

Adopción de passkeys en 2026

En 2026 las passkeys han dejado de ser una promesa. Apple, Google y Microsoft las ofrecen como método por defecto en el alta de cuentas, y el autocompletado de passkeys (la interfaz condicional, con mediation: 'conditional') hace que aparezcan directamente en el campo de acceso, sin que el usuario tenga que recordar nada. Muchos servicios ya permiten la passkey como único factor, retirando la contraseña por completo.

La pieza que faltaba, la portabilidad entre ecosistemas, también ha madurado: la FIDO Alliance publicó las especificaciones Credential Exchange, el Credential Exchange Protocol (CXP) y el Credential Exchange Format (CXF), que permiten mover passkeys entre gestores de forma cifrada y estándar, sin quedar atrapado en un único proveedor. Es un cambio relevante para la adopción empresarial, porque elimina el miedo al bloqueo tecnológico.

El punto débil: la recuperación

Si un usuario pierde su único autenticador y el único camino de vuelta es un SMS o una pregunta de seguridad, has reintroducido justo el vector que las passkeys venían a eliminar. La recuperación debe diseñarse antes del despliegue: registro obligatorio de dos autenticadores por usuario, llaves de respaldo custodiadas y, para casos límite, un proceso asistido por el service desk con verificación de identidad reforzada, nunca un simple correo de restablecimiento.

Migración empresarial: passkey primero, contraseña como fallback

Una migración a passkeys se apoya en tu proveedor de identidad (Microsoft Entra ID, Okta, Ping o Google Workspace soportan WebAuthn de forma nativa) y encaja en tu gestión de identidades y accesos como política, no como reingeniería. Un roadmap realista:

1. Piloto con cuentas privilegiadas usando passkeys device-bound en llave física. Son el objetivo más valioso.
2. Passkeys de plataforma para el grueso de la plantilla, con acceso condicional que exija un factor resistente a phishing en los recursos sensibles.
3. Retirada progresiva de factores débiles: primero el SMS, luego el TOTP cuando la cobertura de passkeys sea suficiente. Una MFA fuerte que convive con un SMS de respaldo baja al nivel del eslabón más débil.
4. Recuperación resuelta de antemano, con doble autenticador y proceso asistido.

Este enfoque encaja con la verificación fuerte de una arquitectura Zero Trust, y satisface exigencias de NIS2, el ENS, ISO 27001 A.5.17 y la autenticación reforzada (SCA) de PSD2. La passkey no es solo mejor seguridad: en muchos marcos es ya la forma más limpia de demostrar cumplimiento.

Preguntas frecuentes

¿Cómo funciona una passkey?

Una passkey funciona con dos claves. Al registrarte, tu dispositivo genera un par de claves para ese servicio: guarda la clave privada en hardware seguro y envía la clave pública al servidor. Al iniciar sesión, el servidor manda un reto aleatorio, tu dispositivo lo firma con la clave privada tras verificar tu huella, rostro o PIN, y el servidor valida la firma con la clave pública. Nunca se transmite un secreto reutilizable.

¿Son seguras las passkeys?

Sí. Al no existir un secreto compartido y estar la credencial ligada al dominio, ni un ataque de intermediario ni una web falsa consiguen algo usable, y el servidor solo custodia claves públicas. El riesgo residual se traslada al dispositivo y, en las passkeys sincronizadas, a la cuenta de nube que las replica, que conviene proteger con su propia autenticación fuerte. La comparación detallada frente a la contraseña, amenaza por amenaza, está en passkey vs contraseña.

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

Depende del tipo. Una passkey sincronizada se recupera en cuanto inicias sesión en otro dispositivo con tu cuenta de nube, porque estaba replicada. Una passkey device-bound en llave física no se sincroniza, así que necesitas una llave de respaldo registrada de antemano. Por eso la buena práctica es registrar siempre dos autenticadores por usuario.

¿Mejor passkey de plataforma o llave física?

Para el uso diario de la mayoría, la passkey de plataforma sincronizada es suficiente y muy cómoda. Para administradores, cuentas privilegiadas y entornos regulados, la llave física device-bound es la recomendación, porque no depende de ninguna cuenta de nube y alcanza el nivel de garantía más alto. Muchas organizaciones combinan ambas según la criticidad del acceso.

Fuentes

• FIDO Passkeys: Passwordless Authentication | FIDO Alliance: definición oficial de passkey como credencial descubrible FIDO2/WebAuthn y sus variantes sincronizada y device-bound.
• Web Authentication API | MDN: referencia de las ceremonias de registro y autenticación (navigator.credentials.create() y get()) que usa una passkey.
• SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management | NIST CSRC: niveles AAL y tratamiento de los autenticadores sincronizables que se citan en el post.
• Implementing Phishing-Resistant MFA | CISA: ficha oficial que sitúa FIDO/WebAuthn como el estándar de referencia de MFA resistente al phishing.

Recursos relacionados

• Qué es FIDO2: MFA resistente a phishing y passkeys: el detalle del protocolo (WebAuthn y CTAP) sobre el que se construye la passkey.
• Passkey vs contraseña: veredicto y modelo de amenaza cara a cara: la comparación amenaza por amenaza que este post deja fuera a propósito.
• Qué es MFA: autenticación multifactor: el marco general en el que la passkey sustituye a los factores débiles.
• MFA resistente al phishing: qué exige y cómo desplegarla: los requisitos de despliegue que una migración a passkeys debe cumplir.
• Qué es IAM: gestión de identidades y accesos: dónde encaja la política de passkeys dentro del proveedor de identidad.

Conclusión

La decisión que condiciona todo el despliegue no es sincronizada frente a device-bound, sino cómo se recupera una cuenta cuando el usuario pierde su autenticador: si el camino de vuelta es un SMS o un correo de restablecimiento, se ha reintroducido el vector que la passkey eliminaba. Conviene medir el porcentaje de usuarios con dos autenticadores registrados, el porcentaje de accesos privilegiados que exigen un factor resistente al phishing y cuántas aplicaciones del inventario siguen sin aceptar WebAuthn. El error habitual es mantener el SMS o el TOTP como respaldo permanente, lo que rebaja toda la cadena al nivel del eslabón más débil. Si quieres revisar ese punto de partida en tu entorno, puedes hacerlo a través de contacto o de los servicios de consultoría GRC.