What a Passkey Actually Protects
This chapter focuses on the passkey authentication ceremony itself: how a relying party’s challenge reaches the authenticator, how the authenticator proves control without sending a reusable secret, and which security properties follow from that exchange. The goal is not to treat “passkey” as a magic word, but to give readers a precise model they can use later when asking whether recovery and fallback preserve the same protection.
From registration to a signed assertion
A passkey login is easiest to understand as a conversation among four participants. The relying party is the service the subscriber wants to use. The browser or client carries messages between that service and the authenticator. The authenticator holds or accesses the credential and performs the cryptographic operation. The subscriber supplies the local action that permits the operation, such as a PIN, biometric verification, or another explicit interaction.
The conversation begins before the first login, during registration. The relying party asks the browser to create a public-key credential for a particular service identity. The authenticator generates a public/private key pair. The relying party receives the public key and stores it with the account. The private key is used by the authenticator when it later signs a challenge; it is not sent to the relying party as part of an ordinary authentication response.
This arrangement gives the service something it can verify without giving it a password-like secret that can be replayed elsewhere. The public key is not a credential that a claimant can type into another site. It is the verification half of the pair. The authenticator retains the ability to produce a valid signature, while the relying party retains the information needed to check that signature.
At login, the relying party creates a fresh challenge and passes authentication options to the browser. A challenge is a random, transaction-specific value. It tells the authenticator that this request belongs to this attempt, rather than being a copy of an earlier conversation. The browser presents the request to an appropriate authenticator, including the identity of the relying party. With a discoverable passkey, the authenticator or credential manager can select a credential associated with that service instead of requiring the user to type a username and secret.
The authenticator then asks for whatever local action its configuration requires. This may be a PIN, a biometric check, or another activation step. The important point is not that one particular biometric is inherently the security property. The local action unlocks or authorizes use of the authenticator; the relying party ultimately verifies the signed result. NIST treats local user verification as relevant to whether a cryptographic authenticator can be treated as multi-factor, and treats an explicit response as relevant to authentication intent.
After the local check, the authenticator performs a private-key operation over the challenge and the relevant authentication context. It returns a signed assertion and associated verification data to the browser, which sends the response to the relying party. The relying party checks the signature with the stored public key. It also checks that the response belongs to the current challenge and to the intended relying party. If those checks succeed, the service creates an authenticated session.
The sequence can be represented without treating the browser as the owner of the credential:
Each participant has a different responsibility. The browser transports and mediates the request, but it does not turn the private key into a password. The authenticator produces the proof, but it does not decide what account privileges the relying party will grant. The relying party verifies the response, but it does not see the private key or the subscriber’s local biometric characteristic as a reusable login secret. The subscriber supplies the action that authorizes the transaction, but does not manually carry a signed value from one site to another.
Registration establishes the relationship that authentication later checks. The relying party chooses the service identity and receives a public key associated with the subscriber’s account. The authenticator keeps the corresponding private-key capability. At login, the relying party is not asking the browser to return a stored password; it is asking whether the authenticator associated with this account will sign a new, service-specific request. That distinction is why a passkey login remains meaningful even when a user does not remember which device originally created the credential.
Credential discovery also explains why the experience can feel simpler than the underlying protocol. A discoverable credential can be selected by the authenticator or credential manager for the relying party, so the user may see a prompt rather than a username-and-password form. The simplified interface does not eliminate the service identity or the challenge. It hides those inputs from the user while the browser and authenticator carry them through the exchange. A convenient prompt is therefore the visible surface of a more constrained message flow, not a replacement for that flow.
The model has a useful initial condition and a clear termination condition. It starts with a credential already bound to an account and a relying party generating a current challenge. It ends when the relying party has verified the assertion and created a session. If the credential is not available, the challenge is stale, the relying-party identity does not match, or the required local action is absent, the normal passkey path should not produce a successful assertion. Those failures are not bugs to be hidden by changing the words on the screen; they are signals that a different branch of the account lifecycle may be needed.
Four properties, four boundaries
The ordinary ceremony is often described with one broad phrase—“phishing-resistant authentication”—but several properties are doing different jobs. Keeping them separate makes it easier to see what a passkey does protect and what it does not.
Verifier-name binding blocks the ordinary phishing relay
A phishing site usually wants to become a fraudulent verifier. It presents a convincing page, persuades the claimant to authenticate, and relays the result to the real service. A password is vulnerable to this because the same value can be entered into the real site after the phisher has learned it. A manually entered one-time code can also be relayed while it is still valid.
WebAuthn addresses this through verifier-name binding. The authenticator associates the credential with the authenticated identity of the relying party. When a lookalike domain asks for an assertion, the request does not match the credential’s intended service identity. The authenticator therefore does not simply sign the challenge as if it came from the real site. NIST defines phishing resistance in terms of preventing disclosure of a usable secret or authenticator output to an impostor without relying on the claimant’s vigilance. In that definition, the protection comes from the protocol binding, not from expecting the user to identify every deceptive page.
This does not mean that a fraudulent site becomes harmless. It may still deceive a user, steal information entered into its own forms, or attempt other attacks. It means that the particular WebAuthn assertion is not supposed to become a transferable password for the impostor. The claim is specific: the protocol resists the impostor-verifier attack for the authentication method that actually uses verifier-name binding.
A fresh challenge blocks replay of an old response
Phishing resistance and replay resistance are related but not identical. Suppose an attacker records a valid assertion from an earlier login. If the relying party accepted that same response indefinitely, the attacker could reuse it even without learning the private key. A fresh challenge prevents that. The authenticator signs the value supplied for the current transaction, and the relying party rejects a response that does not contain the expected challenge.
The challenge is therefore a mediator between the user’s request and the service’s decision. The relying party creates it; the authenticator incorporates it into the signed response; the relying party checks it again. The signature proves control of the credential, while the challenge proves that the response was generated for this particular attempt. A signature without freshness would not provide the same replay protection.
This boundary also explains why a database full of public keys is not equivalent to a database full of passwords. The public key lets the relying party verify a response, but it does not by itself let an attacker generate a new response. A stolen old response still has to match the current challenge, and a copied public key cannot produce the missing private-key operation. These protections reduce the value of two common kinds of stolen material, but they do not make the whole account immune to every compromise.
Freshness is not the same as secrecy, either. The challenge may be visible to the browser and the authenticator; its purpose is to make the response specific to the current transaction. The private key is what must remain protected for the signature to be useful. The relying party also has to validate the expected challenge and the relying-party identity rather than merely checking that some mathematically valid signature arrived. A protocol property exists only when the parties that own the relevant state enforce the check.
This matters in a relay scenario. An attacker may try to place a person between the browser and the real service, or may try to reuse messages from a different moment. A valid signature from the right authenticator is not enough if it is detached from the service identity or accepted outside the challenge for which it was created. Conversely, once the relying party has accepted the assertion and created a session, later threats may target the session or the account lifecycle rather than the original cryptographic exchange. The passkey ceremony narrows important attack paths; it does not make every later state transition cryptographically identical to login.
Authentication intent limits silent use
A credential can be technically valid while being used without the subscriber’s knowledge. Malware on an endpoint, for example, might try to trigger authentication while the user is doing something else. Authentication intent addresses that problem by requiring the claimant to respond explicitly to each authentication or reauthentication request. Depending on the authenticator, the response may be a button press, a deliberate local activation, or entry of an activation factor.
User verification and authentication intent overlap in ordinary passkey experiences, but they are not the same concept. A PIN or biometric can unlock an authenticator, while an explicit action can demonstrate that the claimant intended this particular transaction. NIST cautions that a biometric capture does not always establish intent by itself: a camera may see a face while the device is being used for another purpose. In such a case, an additional explicit mechanism is needed.
The practical question is not whether a product advertises biometrics. It is what the verifier can establish about the event. NIST’s WebAuthn guidance uses the User Verified flag to indicate that the authenticator locally verified the user. If that flag is not present, an agency must treat the authenticator as single-factor for the relevant decision and obtain another factor when the assurance level requires it. A relying party should not silently convert an unverified cryptographic signature into a claim of multi-factor authentication.
The flag also illustrates the difference between an authenticator’s capability and a particular transaction. An authenticator may be capable of local verification, but the verifier still has to inspect the response and apply the policy for the assurance level being requested. Likewise, an authenticator that can be synchronized is not necessarily one that has already been synchronized. These distinctions will matter when the credential is used on another device: the normal signature may look familiar while the account’s assumptions about where the key exists have changed.
These properties stop at the edge of the ceremony
The four ideas—private-key proof, verifier-name binding, challenge freshness, and user intent—describe the normal authentication exchange. They do not automatically describe an email link, a texted recovery code, a support-agent decision, a password reset, or an identity-provider recovery process that sits beside it. NIST explicitly excludes manually entered OTP and out-of-band outputs from its definition of phishing-resistant authentication because an impostor can relay the entered value to the real verifier.
That boundary is the reason a passkey can be both genuinely strong and incomplete as an account-control design. During the preferred ceremony, the service can verify a fresh, origin-bound assertion without receiving a reusable password. If the user loses access to the authenticator, the service has to accept some other evidence or leave the account inaccessible. The alternative may be carefully designed, but it is a separate protocol with separate failure modes.
The same distinction applies to synchronization. During authentication, the authenticator performs the private-key operation locally and returns an assertion. But a syncable passkey may have a key that was backed up and transferred through a sync fabric before that login occurred. The local ceremony can retain its verifier binding and challenge freshness while the account’s larger trust boundary includes the systems that protect the synced key. The fact that the front-door exchange remains strong does not erase the lifecycle decision that made the credential available on another device.
The safest conclusion is therefore precise rather than absolute. A passkey can protect the normal login against impostor verifiers, old-response replay, and some forms of silent use. It can prevent the relying party from needing a reusable password. It cannot, from the ceremony alone, prove that every method of restoring account access has the same properties. To understand that larger question, the next step is to follow the credential after it leaves the single-device mental model: how it is bound, synchronized, and joined by additional authenticators.