Los passkeys se vendieron como el final de las contraseñas robadas: nada que memorizar, nada que reutilizar y nada que un sitio de phishing pueda capturar. La criptografía que los sostiene sigue siendo sólida. Lo que falló la primera semana de agosto de 2026 no fue esa criptografía, sino todo el ecosistema que la rodea.
En cuestión de días, tres equipos de investigación independientes demostraron por separado cómo eludir el inicio de sesión con passkey sin romper el cifrado. Ninguno atacó el par de claves. Los tres se centraron en la infraestructura que lo envuelve: el registro de eventos de Windows, la sincronización de Google y el almacén de claves de Windows Hello. El resumen más ordenado de los tres trabajos lo publicó The Hacker News. Para quien defiende una organización el mensaje es claro: un passkey sigue protegiendo frente al phishing clásico, pero deja de ser una garantía en cuanto el equipo del usuario ya está comprometido. Y las tres técnicas parten precisamente de ese escenario.
En la empresa de ciberseguridad Hard2bit seguimos de cerca esta línea de investigación porque marca el desplazamiento real del riesgo de identidad: del robo de credenciales al abuso de la sesión y del dispositivo. Conviene entender qué demostró cada equipo antes de extraer conclusiones sobre la arquitectura.
Tres investigaciones, una misma conclusión
Los tres trabajos se divulgaron con pocos días de diferencia y coinciden en el diagnóstico: el problema no está en el estándar FIDO2, sino en la forma en que cada plataforma implementa el registro, la recuperación y la confianza del dispositivo. Cada equipo eligió un frente distinto.
Unit 42: recuperar la llave maestra de los passkeys sincronizados
El equipo de Palo Alto Networks Unit 42 describió tres variantes —Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key— contra los passkeys que Google Password Manager sincroniza en Chrome sobre Windows. Las tres parten de malware que ya se ejecuta en el equipo de la víctima, sin necesidad de elevar privilegios a administrador.
La primera variante abusa del sistema de identidad de dispositivo de Chrome para obtener las firmas necesarias y actuar como un cliente legítimo de Google, sin un nuevo desbloqueo ni interacción del usuario. Unit 42 demostró la técnica contra eBay a pesar de que el sitio exigía verificación de usuario; tras el aviso, eBay modificó la forma en que valida ese indicador, según recoge The Hacker News.
La variante más grave, Golden Pass-ta-key, apunta al Security Domain Secret: una clave maestra de 32 bytes que descifra todos los passkeys sincronizados de una cuenta. Unit 42 la localizó primero expuesta en el registro interno de Chrome; Google la retiró de esa traza tras el aviso, aunque los investigadores señalan que sigue apareciendo de forma transitoria en la memoria del proceso de Chrome durante el reregistro. Y persiste por un motivo rotundo: en la implementación actual no existe forma de rotar ni revocar ese secreto una vez robado. Todo el contexto técnico está en el análisis técnico de Unit 42.
SpecterOps: una firma que Windows guardó en claro
El investigador Michael Grafnetter presentó en Black Hat USA 2026 el trabajo Pass-the-Passkey de SpecterOps. SpecterOps describió cómo Windows almacenaba en texto claro las firmas previas de YubiKey, en una ubicación accesible para usuarios autenticados sin privilegios, incluidos los remotos. Encadenando esas firmas con debilidades en la validación de passkeys de Microsoft Entra ID era posible suplantar a usuarios privilegiados pese a una política que exigía MFA resistente al phishing.
El fallo de Windows se sigue como CVE-2026-34348, una divulgación de información en el servicio de registro de eventos con una puntuación de 6,5 según el fabricante y con actualización de seguridad publicada. El matiz importante es que el atacante no extrae la clave privada del autenticador, sino que reutiliza una firma ya generada que Windows conservó. Microsoft aplicó mitigaciones y, según SpecterOps, sus actualizaciones de julio de 2026 dejaron esas firmas inservibles para reproducción, por lo que la cadena completa se considera cerrada. Queda abierta una vía de diseño: SpecterOps señala que Entra sigue usando tokens JWT como reto de WebAuthn en lugar de valores aleatorios de un solo uso, y no ata ese reto a la cookie de sesión.
Dirk-jan Mollema: usar Windows Hello sin pedir el PIN
El investigador independiente Dirk-jan Mollema se centró en Windows Hello for Business. En la mayoría de equipos modernos la clave que lo respalda reside en el módulo TPM y no se puede exportar. Su hallazgo es que un proceso de bajo privilegio dentro de una sesión ya iniciada puede usar esa clave —sin generar un nuevo aviso de PIN o biometría— para firmar como si fuera una credencial FIDO2 frente a Entra ID.
La explotación es posible por cómo funciona el reto de WebAuthn de Entra: es válido durante cinco minutos y no está atado a una sesión, a un usuario ni a una organización (el tenant). Un atacante puede solicitarlo en su propia máquina, firmarlo en el equipo de la víctima y devolver la aserción, superando así políticas de acceso condicional que exigen autenticación resistente al phishing. El token resultante puede carecer del identificador de dispositivo, lo que abre la puerta a registrar un equipo nuevo y obtener un Primary Refresh Token para mantener el acceso.
La aportación útil para el defensor es la señal de detección que publicó Mollema: buscar en los registros de inicio de sesión aquellas autenticaciones con método Windows Hello for Business cuyo identificador de dispositivo llegue vacío. Se trata de un evento poco habitual en condiciones normales, por lo que sirve como primer filtro, complementado con la vigilancia de registros de dispositivo inesperados.
¿Qué ha cambiado respecto a hace un año?
Hace doce meses el discurso dominante era casi unánime: los passkeys eliminan clases enteras de ataque y sustituyen a la contraseña y al segundo factor tradicional. Sigue siendo cierto frente al phishing clásico. Lo que ha cambiado es que la adopción ha crecido lo suficiente como para que los atacantes dejen de mirar el protocolo y empiecen a mirar la implementación: la sincronización entre dispositivos, la recuperación de cuenta, la confianza del equipo y los rastros que el sistema operativo deja por el camino.
El interés se explica por la escala de adopción. Como recoge Malwarebytes citando a la FIDO Alliance, a finales de 2024 unos 800 millones de cuentas de Google ya usaban passkeys. Y Microsoft acelera el movimiento: según su documentación de Entra, desde el 1 de septiembre de 2026 los usuarios habilitados para SMS o voz pasan automáticamente a poder registrar passkeys, y la entrega de SMS y voz se retira el 1 de febrero de 2027. Cuantas más cuentas dependan de este mecanismo, más rentable resulta atacar su implementación.
Qué implica para tu arquitectura de defensa
El punto en común de las tres investigaciones es también el más difícil de asumir: todas parten de un endpoint o una sesión ya comprometidos. Eso no las hace menos relevantes. Las convierte en una prueba de qué contiene y qué no contiene un passkey una vez que el atacante ya está dentro. Y la respuesta es que contiene bastante menos de lo que sugiere la etiqueta de resistente al phishing.
La consecuencia práctica es tratar el almacén de passkeys, los flujos de recuperación y la memoria del navegador como zona sensible de credenciales, con la misma vigilancia que se aplica a un gestor de secretos. Ahí el EDR y el threat hunting (caza proactiva de amenazas) siguen siendo la primera línea: si el malware no llega a ejecutarse, ninguna de estas técnicas arranca.
Para quien opera identidad en Microsoft 365, el patrón enlaza con los ataques que ya veníamos analizando: el secuestro de sesión con robo de token y AiTM y el registro fraudulento de passkey por vishing. El hilo conductor es siempre el mismo: la identidad no se rompe por la fuerza, se hereda a través de una sesión o un dispositivo de confianza.
Qué sigue valiendo y qué supuesto ha caducado
Lo que sigue valiendo: frente a sitios de phishing clásicos y frente a la reutilización de contraseñas, el passkey continúa siendo la mejor opción disponible, y así debe comunicarse. Las llaves de seguridad hardware, con credencial ligada al dispositivo y sin sincronización, reducen la exposición del caso de Unit 42, porque la clave privada no entra en el sistema de sincronización ni en la memoria del navegador de la misma forma. Y existe una medida barata que cierra la brecha de la verificación de usuario: que cada servicio compruebe de verdad el indicador de usuario verificado en la respuesta, y no se limite a pedirlo en la petición.
Lo que ha caducado es el supuesto de que passkey equivale a resistente al phishing y, por tanto, a problema resuelto. Ese atajo mental deja fuera la sincronización, la recuperación, el diseño del reto de autenticación y lo que ocurre tras el compromiso del endpoint. Un reto basado en JWT que no se ata a la sesión, o un secreto maestro que no se puede rotar, son decisiones de implementación que la etiqueta del estándar no cubre.
Para las organizaciones sujetas a NIS2 o DORA, la lectura es directa: ambos marcos esperan MFA resistente al phishing y control de identidades, pero estas investigaciones demuestran que el control no termina al elegir passkey. Continúa en el bastionado del endpoint, en el gobierno de las identidades no humanas y los tokens, en el mínimo privilegio y en la detección de sesiones anómalas. Es el enfoque de defensa por capas que aplicamos en los proyectos de seguridad de Microsoft 365 de Hard2bit.
¿Y ahora?
Ninguno de estos tres trabajos es motivo para retirar los passkeys; esa sería la conclusión equivocada. La prueba de fuego no es si el passkey resiste, sino si tu organización sabría distinguir un inicio de sesión legítimo de otro firmado por malware desde una sesión secuestrada. La señal que publicó Mollema —una autenticación con Windows Hello sin identificador de dispositivo— es un buen lugar por donde empezar a mirar.
Este artículo resume investigación pública de Unit 42, SpecterOps y Dirk-jan Mollema divulgada en agosto de 2026, con la información disponible en esa fecha. Las medidas de detección y bastionado citadas deben validarse en un entorno de pruebas antes de aplicarse en producción. Ninguna mención implica un fallo de seguridad sin corregir en los productos citados: Google, Microsoft y eBay aplicaron cambios tras las divulgaciones. Las atribuciones y el alcance pueden evolucionar a medida que avance la investigación.
