defensiva
passkey
passwordless
FIDO2

Qué es una passkey: login sin contraseña

Qué es una passkey: credencial passwordless FIDO2/WebAuthn resistente a phishing. Cómo funciona, sync vs device-bound y migración en empresa.

Secra6 de julio de 202612 min de lectura

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 explica qué es una passkey, cómo funciona por dentro, por qué es resistente a phishing frente a la contraseña y a la MFA por SMS o código, en qué se diferencian las passkeys de plataforma y las de hardware, y cómo abordar una migración empresarial sin quedarte atrapado en la recuperación de cuentas.

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 MFA que recomiendan CISA e INCIBE.

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.

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.

Passkey frente a contraseña y MFA por código

La ventaja de una passkey no es de comodidad, es de modelo de amenaza. Estas son las cuatro formas de robo de credenciales que elimina de raíz:

  • Phishing y ataques de intermediario (AiTM). Como no hay secreto que teclear y la firma está ligada al dominio, un kit tipo Evilginx que hace de proxy no obtiene nada usable. Es la propiedad que el TOTP y el push no tienen. Puedes ampliar en cómo evitar el phishing y en los tipos de phishing.
  • Credential stuffing y reutilización de contraseñas. No hay contraseña que probar contra otros servicios. Es el vector que analizamos en credential stuffing.
  • Brechas de base de datos. El servidor solo custodia claves públicas, inútiles para un atacante.
  • Keyloggers y SIM swapping. No hay pulsaciones que capturar ni SMS que interceptar, porque la passkey no envía un código de un solo uso.

Frente a la contraseña con un segundo factor tradicional, la passkey no es un factor añadido, es un cambio de paradigma. Si quieres la comparación cara a cara con veredicto, la desarrollamos en 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 (CTAP hybrid, antes conocido 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

CriterioPasskey sincronizadaPasskey device-bound
ComodidadAlta, disponible en todos tus dispositivosRequiere llevar la llave
Pérdida de dispositivoSe recupera desde la nubeExige llave de respaldo
Superficie de riesgoLa cuenta de nube que sincronizaSolo el control físico
Nivel típicoAdecuada para el grueso de la plantillaRecomendada para cuentas privilegiadas

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. El propio NIST ya reconoce los autenticadores sincronizables (syncable authenticators) como opción válida, situándolos por lo general en AAL2, 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ó 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í, y de forma medible. Eliminan las cuatro grandes vías de robo de credenciales: phishing, credential stuffing, brechas de base de datos y keyloggers. 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. 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.

¿Las passkeys sustituyen a las contraseñas?

Esa es la dirección, pero la transición dura años. Una passkey ofrece más seguridad y mejor experiencia, y en muchos servicios ya puede ser el único método de acceso. Las contraseñas conviven por inercia de aplicaciones heredadas y por casos de recuperación. El objetivo razonable en 2026 es passkey primero donde se pueda y contraseña solo como fallback donde no haya alternativa.

¿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.

Recursos relacionados

Passkeys con Secra

En Secra ayudamos a organizaciones B2B a adoptar autenticación resistente a phishing sin romper la operación. Evaluamos tu stack de identidad, definimos el modelo de passkeys de plataforma y llaves físicas según criticidad, resolvemos la recuperación antes de que sea un problema y encajamos todo con tu marco normativo. Si tu organización quiere jubilar el SMS y el TOTP y adoptar passkeys, contacta con Secra o revisa nuestros servicios de consultoría GRC.

Sobre el autor

Equipo de Secra Solutions

Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.

Compartir artículo