Passkeys

Shepherded by the FIDO Alliance and backed by Apple, Google and Microsoft, passkeys have matured into Adopt. They are FIDO2 credentials that can replace passwords using asymmetric public-key cryptography. The private key is stored in a hardware-backed secure enclave on the user's device, protected by biometrics or a PIN, and never leaves it. Each credential is origin-bound to its relying-party domain, making passkeys structurally phishing-resistant: a lookalike site receives nothing, unlike SMS OTP or TOTP codes that a phishing proxy can intercept.

With phishing responsible for more than one third of all data breaches, this structural resistance is increasingly important. The FIDO Alliance Passkey Index 2025 reports there are over 15 billion eligible accounts globally, Google reports a 30% improvement in sign-in success rates across 800 million users and Amazon has seen sign-ins six times faster than using traditional methods. NIST SP 800-63-4 (July 2025) now classifies synced passkeys as AAL2-compliant, reversing earlier guidance, and regulators in the UAE, India and US federal agencies mandate phishing-resistant authentication for financial services and government systems.

The FIDO Credential Exchange Protocol enables secure portability of passkeys between credential managers, addressing earlier vendor lock-in concerns. Major identity providers including Auth0, Okta and Azure AD now support passkeys as a first-class feature, and implementation has been simplified from a multi-month effort to a two-sprint project. We’ve adopted passkeys internally and treat them as the default starting point for new authentication implementations. Teams should design account recovery carefully and avoid phishable fallback paths such as SMS OTP, which reintroduce the vulnerabilities passkeys eliminate. Device-bound credentials on hardware security keys remain necessary for AAL3 scenarios such as privileged access.

Impulsadas por la alianza FIDO y respaldadas por Apple, Google y Microsoft, las passkeys están cerca de alcanzar un nivel de usabilidad masivo. Al configurar un nuevo inicio de sesión con llaves de acceso, se generan un par de claves: el sitio web recibe la clave pública y el usuario mantiene la clave privada. El proceso del inicio de sesión utiliza criptografía asimétrica. El usuario demuestra que está en posesión de la clave privada, que se almacena en el dispositivo del usuario y nunca se envía al sitio web. El acceso a las llaves está protegido mediante biometría o un PIN. Las llaves de acceso pueden almacenarse y sincronizarse en los ecosistemas de las grandes tecnológicas, utilizando iCloud Keychain de Apple, Google Password Manager o Windows Hello. Para usuarios multiplataforma, el Client to Authenticator Protocol (CTAP) permite que las llaves de acceso se guarden en un dispositivo diferente al que crea la clave o la necesita para el inicio de sesión. La objeción más común al uso de las passkeys es que representan un desafío para los usuarios con menos conocimientos técnicos, lo cual creemos que es una visión contraproducente. Estos suelen ser los mismos usuarios que tienen una gestión deficiente de las contraseñas y, por lo tanto, serían los más beneficiados por métodos alternativos. En la práctica, los sistemas que usan llaves de acceso pueden recurrir a métodos de autenticación tradicionales si es necesario.

El "fin de las contraseñas" podría estar cerca, finalmente. Impulsadas por la alianza FIDO y respaldadas por Apple, Google y Microsoft, Passkeys se acerca al uso generalizado. Al configurar un nuevo inicio de sesión con Passkeys, se generan un par de claves: el sitio web recibe la clave pública y el usuario conserva la clave privada. El manejo del inicio de sesión utiliza criptografía asimétrica. El usuario demuestra que está en posesión de la clave privada, pero, a diferencia de las contraseñas, ésta nunca se envía al sitio web. En los dispositivos de los usuarios, el acceso a Passkeys está protegido mediante datos biométricos o un PIN.

Las Passkeys se pueden almacenar y sincronizar dentro de los ecosistemas de las Grandes Tecnológicas, utilizando el iCloud Keychain de Apple, el Administrador de contraseñas de Google o Windows Hello. En la mayoría de los casos, esto solo funciona con versiones recientes del sistema operativo y del navegador. En particular, el almacenamiento de passkeys en Windows Hello no es compatible con Windows 10. Afortunadamente, el Client to Authenticator Protocol (CTAP) hace posible que las Passkeys sean guardadas en un dispositivo diferente al que crea la clave o al que la necesita para iniciar sesión. Por ejemplo, un usuario crea una passkey para un sitio web en Windows 10 y la almacena en un iPhone escaneando un código QR. Debido a que la clave se sincroniza a través de iCloud, el usuario puede iniciar sesión en el sitio web desde, por ejemplo, su MacBook. Las Passkeys también se pueden almacenar en candados de hardware, y el soporte para aplicaciones nativas ha llegado a iOS y Android.

A pesar de algunos problemas de usabilidad, por ejemplo, Bluetooth debe funcionar porque la proximidad del dispositivo se verifica cuando se escanea un código QR, vale la pena considerar passkeys. Sugerimos experimentar con ellas en passkeys.io para tener una idea de su uso.