Escenario
Las estadísticas sobre ciberataques indican que, uno de cada cinco que se llevan a cabo de forma exitosa, se han iniciado con una credencial robada.
Ésto no implica ninguna vulnerabilidad del mecanismo de contraseñas, es un problema de comportamiento en el uso y gestión de las mismas. Una contraseña de veinte caracteres aleatorios, generada por un gestor, única por servicio y protegida con un segundo factor TOTP, es técnicamente sólida hoy y lo seguirá siendo a futuro, incluyendo el horizonte de la computación cuántica. El problema es que ésta última práctica, tan sólo es aplicada por una parte muy minoritaria de usuarios.
Las passkeys no vienen a demostrar que la contraseña está rota; vienen a proponer una alternativa para quienes nunca llegarán a gestionarlas correctamente. Y con matices importantes: una passkey mal gestionada puede ser bastante más peligrosa que una contraseña bien gestionada.
El verdadero problema con las contraseñas
El concepto de contraseña no está fallando. Lo hacen los hábitos con los que la mayoría de usuarios las viene utilizando, siendo ésta distinción, la que acaba por marcar la diferencia. Incorporar un gestor de contraseñas (herramientas maduras, auditadas y en muchos casos gratuitas) transforma de forma inmediata una gestión deficiente en una práctica robusta: contraseñas únicas, aleatorias y largas para cada servicio, protegidas con TOTP en lugar de SMS. No es necesario cambiar de dispositivo, no depende de que el servicio soporte ningún estándar nuevo y funciona perfectamente en cualquier página web. Pasar de una nula o mala gestión de nuestras contraseñas a otra de correcta es, en términos prácticos, más rápido y accesible que la transición a passkeys.
Los datos del Verizon Data Breach Investigations Report de 2025, que analizó más de 22.000 incidentes, documentan con precisión dónde está el problema real: el uso de credenciales comprometidas fue el vector de acceso inicial en el 22% de las brechas analizadas; el 88% de los ataques contra aplicaciones web básicas implicó credenciales robadas; y en la zona media, solo el 49% de las contraseñas de un mismo usuario eran distintas entre sí. Estos números visibilizan el problema real con las contraseñas:
Una reutilización masiva sumada a una ausencia de gestión.
El proceso de probar credenciales robadas en otros servicios de forma automatizada se conoce como credential stuffing, y tiene una escala difícil de visualizar: el porcentaje diario mediano de intentos de credential stuffing representó el 19% de todos los intentos de autenticación analizados en registros de proveedores SSO. Casi uno de cada cinco inicios de sesión es un ataque.
Vale la pena señalar también los límites del segundo factor por SMS (distinto del TOTP basado en aplicación). El SIM swapping, el prompt bombing y los ataques AiTM (Adversary-in-the-Middle) permiten interceptar o eludir los códigos enviados por mensaje. En 2025, reguladores de distintos países comenzaron a prohibir el OTP por SMS en servicios financieros, reconociendo lo que la comunidad de seguridad advertía desde hace años. El problema, sin embargo, no es el segundo factor en sí, sino esa implementación concreta y frágil.
Las passkeys proponen eliminar de raíz el secreto compartido. Pero conviene no olvidar un dato que se tiende a minimizar: debido a su baja penetración (solo el 48% de los cien sitios más visitados del mundo las soportan), cualquier usuario que adopte passkeys va a necesitar igualmente un gestor de contraseñas para el resto de servicios. La passkey no sustituye al gestor; se añade a él. Y si no se ha previsto un plan de contingencia (un segundo dispositivo registrado, o las propias passkeys almacenadas en algún gestor):
Perder el acceso al dispositivo principal puede significar perder el acceso a los servicios.
Fundamentos de una passkey
Una passkey es una credencial de autenticación basada en criptografía asimétrica de clave pública. En lugar de un secreto que el usuario memoriza y el servidor almacena (contraseña), una passkey genera un par de claves matemáticamente vinculadas: una pública y una privada.
Cuando el usuario se registra en un servicio, su dispositivo genera dicho par. La clave pública se envía al servidor (el Relying Party en la terminología FIDO2) y se almacena allí. La clave privada nunca abandona el dispositivo: reside protegida en un enclave seguro (Secure Enclave de Apple, Titan M de Google, TPM en Windows), inaccesible incluso para el sistema operativo. Cuando el usuario quiere autenticarse, el servidor envía un desafío criptográfico. El dispositivo lo firma con la clave privada (operación que requiere desbloquear el dispositivo mediante biometría o PIN) y devuelve la firma. El servidor verifica la firma con la clave pública. Si coincide, el acceso se concede. En ningún momento se transmite ningún secreto.
El estándar que hace posible todo esto es FIDO2/WebAuthn, desarrollado por la FIDO Alliance con el respaldo de Google, Apple, Microsoft y centenares de organizaciones. Su elemento diferencial más importante es el enlace de origen (origin binding): la clave se genera para un dominio concreto y solo puede usarse en ese dominio. Una passkey creada para alt43.es no puede ser invocada desde alt43.donut.es, aunque el sitio sea visualmente idéntico. El phishing clásico queda neutralizado por diseño.
Existen dos tipos de passkey con distintos perfiles de seguridad:
- Passkeys sincronizadas: se almacenan cifradas en la nube del proveedor del dispositivo (iCloud Keychain, Google Password Manager, Microsoft Authenticator) y se sincronizan entre dispositivos del mismo ecosistema. Maximizan la comodidad y facilitan la recuperación de cuenta.
- Passkeys ligadas al dispositivo: la clave privada reside exclusivamente en un token hardware (YubiKey, tarjeta inteligente). No puede exportarse ni copiarse. Ofrecen mayor garantía de seguridad, pero mucha menor flexibilidad.
Ventajas de seguridad documentadas
Los datos de adopción revelan una diferencia de rendimiento notable frente a las contraseñas. Las passkeys alcanzan una tasa de éxito de inicio de sesión del 93%, frente al 63% de los métodos de autenticación tradicionales. Google informa de que los inicios de sesión con passkey tienen cuatro veces más éxito que con contraseña. TikTok registra una tasa de éxito del 97% con autenticación mediante passkey.
La resistencia al phishing es estructural, no una característica adicional, al no existir secreto que interceptar y al estar la credencial ligada criptográficamente al dominio legítimo, los ataques de phishing convencionales dejan de funcionar. El credential stuffing también queda eliminado al no haber contraseña que introducir.
La adopción va camino -muy lento- de alcanzar la masa crítica necesaria. El 75% de los consumidores globales conoce ya las passkeys, y se ha duplicados número de sitios web «importantes» que ya lo están ofreciendo como de inicio de sesión, más del doble que en 2022. En mayo de 2025, Microsoft convirtió las passkeys en el método de inicio de sesión predeterminado para todas las cuentas nuevas, decisión que impulsó un crecimiento del 120%. Las autenticaciones de Google crecieron un 352% desde que convirtió las passkeys en la opción predeterminada para cuentas personales a finales de 2023. En total, más de mil millones de personas han activado al menos una passkey.
El impacto en los resultados también es significativo. Las primeras organizaciones que adoptaron passkeys informan de un 30% más de tasa de éxito en los inicios de sesión, una reducción del 73% en el tiempo de autenticación y hasta un 81% menos de incidentes de soporte relacionados con contraseñas.
Riesgos y limitaciones
Las passkeys resuelven problemas estructurales del modelo de contraseña, pero más que eliminar la superficie de ataque; la desplazan. De ahí la necesidad de identificar claramente todos los riesgos que conllevan para tratar de minimizarlos.
Dispositivo comprometido o desbloqueado sin consentimiento
La clave privada está protegida por la propia seguridad del terminal móvil, pero si el dispositivo está desbloqueado (o si el atacante tiene acceso físico y conoce el PIN de desbloqueo) podrá utilizar la autenticación. Un dispositivo robado con la pantalla desbloqueada concede acceso a todas las passkeys almacenadas en él. Este vector es especialmente relevante en contextos de violencia o acceso coercitivo. Investigadores de Cornell presentaron en la conferencia USENIX Security 2025 un análisis de 19 servicios con soporte de passkeys que identificó siete formas distintas de abuso en contextos de violencia interpersonal, desde añadir una huella dactilar adicional en un dispositivo compartido hasta clonar una passkey mediante AirDrop o sincronización en la nube.
Secuestro del flujo WebAuthn en el navegador
Investigaciones de SquareX demostraron en el evento DEF CON 33 que, mediante extensiones de navegador maliciosas o la inyección de scripts, un atacante puede interceptar y falsificar el proceso de registro de passkeys, obteniendo acceso a cuentas sin poseer el dispositivo legítimo ni la biometría del usuario. El ataque funciona porque toda la comunicación entre el servidor y el dispositivo del usuario se enruta a través del navegador:
Las passkeys funcionan bajo la premisa de que el navegador del usuario es seguro.
Chrome documenta una API de extensión (webAuthenticationProxy) que puede interceptar los métodos navigator.credentials.create y navigator.credentials.get, diseñada para escritorio remoto, pero que demuestra que una extensión con los permisos adecuados puede filtrarse dentro del flujo WebAuthn.
Passkeys sincronizadas y fraude de sincronización
La sincronización en la nube (el mecanismo que hace las passkeys cómodas para el usuario medio) traslada la confianza a la cuenta del proveedor. Los investigadores de Prove han documentado una tendencia creciente en el fraude de sincronización. Los atacantes comprometen la cuenta raíz del sistema (iCloud, Google Account, etcétera) y, una vez que obtienen tanto las credenciales como la capacidad de interceptar el número de teléfono de la víctima, pueden propagar las ya passkeys sincronizadas a un dispositivo no autorizado. El acceso persiste aunque la víctima recupere el control de su número de teléfono, hasta que el dispositivo atacante no sea explícitamente eliminado de la cuenta. Los kits AiTM pueden forzar degradaciones de autenticación (authentication fallback) que eluden completamente los mecanismos de autenticación robusta cuando el servicio todavía acepta contraseña o SMS como alternativa.
Secuestro de sesión
Según varios reportes, durante los últimos meses se está intensificando los intentos de apropiación sobre sesiones de usuarios (session hijacking). El procedimiento se sustenta sobre una cookie de sesión activa y un navegador web que permita perfiles de navegación aislados, un atacante puede suplantar a un usuario independientemente de si éste se autenticó con contraseña, MFA o passkey. Si la sesión robada pertenece a un sistema corporativo, una única cookie puede abrir el acceso a más de doscientas aplicaciones. Las passkeys eliminan el riesgo en el momento de la autenticación, pero no protegen sesiones posteriores.
Riesgos y problemas en los procesos de recuperación de cuentas
El mayor de los problemas se inicia cuando perdemos el acceso a nuestro teléfono móvil. La recuperación de cuenta y el servicio de atención al cliente son en la práctica los puntos de control reales que persiguen los atacantes persiguen; si logran superar el proceso de verificación de identidad, pueden autorizar un nuevo dispositivo bajo su control para que el ecosistema sincronice automáticamente las passkeys almacenadas.
Medidas a tomar
- Activar passkeys donde estén disponibles: la reducción de superficie de ataque es inmediata incluso con passkeys sincronizadas.
- Usar passkeys ligadas al dispositivo (hardware tokens FIDO2) para cuentas críticas: acceso corporativo, gestores de contraseñas, correo principal.
- Revisar y limpiar extensiones de navegador: limitar los permisos al mínimo necesario; las extensiones son el vector de ataque más subestimado en el flujo WebAuthn.
- Proteger la cuenta principal del ecosistema (Apple ID, Google Account, Microsoft Account) con autenticación fuerte e independiente, nunca mediante SMS.
- Endurecer los procesos de recuperación de cuenta: exigir que la verificación de identidad, antes de que se registre una nueva passkeys, sea mediante un método resistente al phishing.
- Gestionar activamente las sesiones activas: revocar cookies de larga duración y activar detección de anomalías de sesión donde esté disponible.
Dudas razonables
El «entusiasmo» con el que se promociona el uso de passkeys desde muchos sectores tecnológicos, suele omitir problemas y riesgos a los que tendríamos que enfrentarnos como usuarios en la vida real.
Pierdo o me roban el teléfono. ¿Qué ocurre?
La respuesta depende de cómo se hayan configurado las passkeys. Si el usuario activó la sincronización en la nube (iCloud Keychain, Google Password Manager), las passkeys estarán disponibles en cualquier otro dispositivo vinculado al mismo ecosistema en cuanto se inicie sesión en él. En ese caso, la pérdida del teléfono no implica pérdida de acceso.
El problema llega cuando no se cumple ninguna de esas condiciones:
- Passkey ligada al dispositivo sin sincronización activa.
- Dispositivo único.
- Sin copia de seguridad activada.
En cualquiera de éstos escenarios, la recuperación del servicio depende exclusivamente de los métodos que haya implementado el propio proveedor:
- Enlace por correo electrónico.
- Código SMS.
- Contacto directo con el soporte.
Es decir, volvemos nuevamente a depender del eslabón más débil que es precisamente lo que se trataba de evitar con la utilización de las passkeys. A ésto habría que sumarle que tanto que Apple como Google no sincronizan passkeys entre sí. Con lo cual, cambiar de iPhone a Android – o viceversa- nos obligará a registrar de nuevo todas y cada una de nuestras credenciales.
La solución más evidente es también la mas compleja: registrar la passkey en dos dispositivos distintos y aseguramos que la cuenta principal (Apple ID, Google Account, Microsoft etcétera) tenga activada 2FA meditante un método robusto.
¿Qué ocurre si no tengo el teléfono a mano?
Los principales proveedores permiten autenticación entre dispositivos, por ejemplo, iniciar sesión en un ordenador sin passkey registrada valiéndonos del teléfono móvil como autenticador:
- El ordenador muestra un código QR.
- El usuario lo escanea con el móvil, verifica su identidad mediante biometría y el teléfono firma criptográficamente el acceso.
- El Bluetooth no transmite ninguna credencial; su único papel es confirmar que ambos dispositivos están físicamente en el mismo lugar, impidiendo que un atacante remoto use su propio teléfono para firmar en nuestro nombre.
Sin embargo, si no disponemos de ningún dispositivo con la passkey almacenada, volvemos al estadio original; depender de los métodos de recuperación tradicionales que haya habilitado el proveedor.
La autenticación sin dispositivo sigue siendo un punto muerto en la experiencia de usuario, y que cada servicio puede llegar a resolver de manera distinta.
¿Funcionan las passkeys con las extensiones de navegador de los gestores de contraseñas (Bitwarden y Proton Pass)?
Pongo éstos dos casos por estar entre los más populares y utilizarlos personalmente.
La respuesta que he encontrado vendría a decir: Sí, pero con matices.
Según su propia documentación, tanto Bitwarden como Proton Pass soportan el almacenamiento y uso de passkeys a través de sus extensiones de navegador. En noviembre de 2025, Bitwarden amplió el soporte de inicio de sesión con passkey a navegadores basados en Chromium (Chrome, Edge y Brave), mediante la extensión WebAuthn PRF para combinar autenticación y descifrado de nuestra bóveda mediante una única acción. El matiz aparece con que la funcionalidad está en fase beta y no cubre Firefox por el momento.
Proton Pass sí ofrece soporte de passkeys en sus extensiones tanto para Chrome como para Safari y Firefox.
A todo ésto, en el caso de Bitwarden, hay otro detalle técnico importante: la funcionalidad completa (autenticación más descifrado de la bóveda sin contraseña maestra) requiere que la passkey utilizada implemente la extensión PRF del estándar WebAuthn. Las passkeys que no la soporten, permiten autenticarse pero siguen necesitando la contraseña maestra para descifrar la bóveda. El soporte de PRF varía según el servicio, por lo que la experiencia, al menos de momento, dista de ser uniforme.
¿Puedo transferir mis passkeys de un gestor de contraseñas a otro?
A fecha de éste artículo: No.
Al contrario que sucede con las contraseñas estándar, en el caso de las passkeys:
La clave privada está ligada criptográficamente al proveedor que la generó y no puede exportarse en texto plano sin romper la garantía de seguridad.
La solución estándar está en desarrollo; consiste en el par de especificaciones CXP/CXF (Credential Exchange Protocol y Credential Exchange Format) de la FIDO Alliance, elaboradas con la participación de Apple, Google, Microsoft, 1Password, Bitwarden y Dashlane, entre otros. El formato CXF fue aprobado como propuesta unificada en agosto de 2025. El protocolo CXP, que define el mecanismo de transferencia cifrada extremo a extremo, sigue siendo un borrador de trabajo, con una publicación formal prevista para 2026. iOS 26 de Apple es la primera plataforma en implementar CXP, y Bitwarden fue el primer gestor de terceros en sumarse a esa integración.
Por tanto y a fecha de hoy; cambiar de gestor de contraseñas, supone volver a registrar manualmente las passkeys en cada uno de los servicios que las utilice.
¿Qué ocurre con los personas mayores acostumbradas a las contraseñas?
El paso de utilizar contraseñas a passkeys no es baladí. Supone un cambio conceptual profundo: pasar de «algo que sabes» (la contraseña memorizada) a «algo que tienes» (terminal móvil).
«La resistencia a la tecnología en personas mayores no responde solo a limitaciones técnicas, sino a barreras sicológicas e identitarias. La baja autoeficacia percibida ante una interfaz desconocida genera ansiedad tecnológica, que a su vez amplifica la percepción de riesgo y refuerza el rechazo.»
A esto cabría sumar lo ya citado en cuanto a diferentes experiencias de usuario; lo que funciona de un modo en Chrome puede presentarse de forma diferente en Safari o en una aplicación móvil.
El problema real no es tanto que las personas mayores no puedan adoptar las passkeys, como que, ante la dificultad del proceso, acaben por utilizar la contraseña como «respaldo» permanente. Lo que eliminaría todo el valor que aportan las primeras.
Conclusiones
Hay práctica unanimidad en que las passkeys representan el avance más significativo en autenticación desde la introducción del 2FA.
Pero problemas ante situaciones como:
- Recuperación de cuenta.
- Sincronización entre dispositivos.
- Portabilidad entre gestores.
- Experiencia de usuario heterogénea.
No considero que las conviertan en un reemplazo de las contraseñas tradicionales. Al menos de forma completa.