When Quantum Computers Challenge Passkeys – Part 1

Passkeys are one of the most important developments on the path toward phishing-resistant, passwordless authentication. For users, they make authentication easier and more secure. Technically, they are based on the FIDO2 ecosystem — and therefore on standards and protocols such as WebAuthn and CTAP.

But the long-term security of passwordless authentication also depends on how well its cryptographic foundations can be prepared for the post-quantum era. This is where things become interesting: migrating to Post-Quantum Cryptography (PQC) is not only about replacing individual signature algorithms. It affects the interaction between WebAuthn, CTAP, authenticators, relying parties, and public-key infrastructure.

Over the past few years, FIDO2 has become widely established across browsers, operating systems, hardware security keys, and cloud platforms. By using asymmetric cryptography instead of passwords, FIDO2 reduces major risks such as phishing, credential theft, and credential reuse.

At the same time, progress in quantum computing creates a long-term challenge. Algorithms such as RSA and elliptic curve cryptography (ECC), which are used in several parts of the FIDO ecosystem, are considered vulnerable to sufficiently powerful quantum computers. This raises an important question: How can FIDO be migrated toward Post-Quantum Cryptography – technically, organizationally, and across the wider ecosystem?

At its core, the FIDO2 ecosystem consists of four major components.

• The relying party is the online service or application that a user wants to authenticate to.

• The client is typically the operating system or browser that handles communication via WebAuthn and CTAP, the Client-to-Authenticator Protocol.

• The authenticator is the device or application that generates and stores the private authentication key. Implementations range from hardware security keys to platform authenticators.

• Finally, the FIDO Metadata Service (MDS) is a service operated by the FIDO Alliance. It provides information about authenticator models and related certificates. This allows a relying party to verify whether an authenticator is genuine and trustworthy.

The ecosystem is built around two central protocols. WebAuthn, a W3C specification, defines how the relying party communicates with the client to create or use credentials. CTAP, specified by the FIDO Alliance, defines how the client communicates with the authenticator. Depending on the implementation, the authenticator may be connected through different transports, such as USB HID, NFC, or BLE.

During registration, the relying party sends a challenge and additional metadata to the client. The authenticator then generates a new asymmetric key pair that is specific to the relying party and the user ID. It returns the public key together with information about the authenticator.

This response is signed with an attestation key, which can be verified against a certificate from the Metadata Service. Additional information from the MDS allows the relying party to evaluate the trustworthiness of the device, for example based on its certification level.

During authentication, the relying party again provides a challenge. The authenticator signs this challenge together with additional information, such as whether the user was verified. The signature is created using the private key generated during registration. In this way, the authenticator proves that it still holds the matching credential and that user verification was successfully performed.

One reason FIDO2 is phishing-resistant is that requests to create or use a credential include a hash of the relying party ID. This RP ID is typically the domain of a web service. The authenticator binds the credential to this RP ID hash and prevents other origins from using it.

That is why passkeys are so effective against phishing: the credential is not simply a secret that can be entered on any website. It is cryptographically bound to the correct relying party.

From a user perspective, FIDO2 looks simple: a security key or platform authenticator replaces the password with local user verification. Technically, however, public-key cryptography is deeply embedded in several parts of the ecosystem.

Every credential generated during registration consists of a public and a private key. Today, these are typically based on elliptic curve algorithms such as ECDSA P-256 or Ed25519.

A request to create a credential always contains a list of allowed algorithms. The response then includes the algorithm identifier selected for that credential.

Conceptually, this is one of the easier components to migrate. In theory, the signature algorithm can be replaced by a post-quantum-secure alternative as soon as the relevant identifiers are registered. In this case, the relying party and authenticator mainly need to support a common PQC algorithm. The client translates between CTAP and WebAuthn, but does not need to understand or implement the algorithm itself.

In practice, however, there are still significant challenges. Post-quantum algorithms usually come with much larger key and signature sizes. For resource-constrained devices such as hardware security keys, this can create memory or performance issues. It can also lead to problems with message size limitations in underlying protocols, such as CTAP-HID.

This is an important theme in the PQC migration of FIDO2: changing an algorithm may look straightforward in principle, but real-world implementation details matter.

Passkeys have made FIDO2 visible to a much broader audience. They are the solution many people now associate with passwordless authentication.

But behind the convenient user experience is a complex ecosystem built on public-key cryptography. Preparing this ecosystem for the post-quantum era requires a closer look at the areas where cryptography is not only used for credentials, but also for trust chains, secure channels, PIN verification, metadata, and certification.

In part two of this blog series, I will take a closer look at these more complex parts of the migration: attestation infrastructure, secure channels, PIN protocols, ecosystem coordination, and practical ways to demonstrate PQC-enabled FIDO.