Introduction
“Why does using a passkey sometimes ask for a password and sometimes not?” Once you start using passkeys, you notice this.
On some services, just picking a passkey on the login screen completes the login without asking for anything. On other services, after you pick a passkey you are asked every time for Face ID, a fingerprint, or a PIN.
Here is the answer up front: this is neither a bug nor an implementation mistake. It is a difference in a setting that the service deliberately chooses. In this post, I will roughly explain what that difference is and why it varies from service to service, without diving into the fine details of the spec.
A Rough Look at What a Passkey Does
First, let me use an analogy to grasp what a passkey does at login time.
When you register a passkey, a key pair is created inside your phone or PC. One is a secret key, which is never handed to the service. The other is like a lock, and only this one is handed to the service.
At login, the service asks, “Do you have the key that fits this lock?” If the secret key inside your phone can answer, the login succeeds.
sequenceDiagram
participant P as Phone (secret key)
participant S as Service (lock)
Note over P,S: At registration
P->>P: Create a key pair
P->>S: Hand over only the lock
Note over P,S: At login
S->>P: Do you have the key that fits this lock?
P->>P: Answer with the secret key
P->>S: Send the response
S->>S: Check against the lock; if OK, login succeeds
The key point is that only the lock is handed to the service. There simply is no secret, like a password, that could leak from the service and be abused. Also, this exchange is designed so that it only works with the genuine service, so phishing scams that lure you to a fake site and get you to type a password do not work either. This is why passkeys are said to be secure.
”Having It” and “Being the Person” Are Different Things
Here is the main point. Look carefully at what the service was able to confirm in that flow.
The fact that the secret key answered confirms that “the registered phone is there.” But it does not tell us who is operating that phone. It could be the owner, or it could be someone else who picked up (or stole) the phone.
The house key analogy makes this clear. Anyone holding the key can enter the house, but holding the key does not mean you are the homeowner.
- Confirming possession: the registered phone (the secret key) is there
- Confirming identity: the person operating that phone is the owner
These two are different things, and the passkey mechanism treats them separately. What Face ID and PINs handle is the latter, that is, confirming “is the person operating the phone its owner?” That is why what you are asked for is not the service’s password but the same means as unlocking your phone. The logic is that whoever can unlock the phone is probably its owner.
The Real Difference: The Service Chooses Whether to Require Identity Verification
Whether to do this identity verification can be specified by the service at each login. WebAuthn, the spec that passkeys are built on, has a setting called User Verification, and the service can broadly choose from these three:
- required: always verify identity. Face ID or a PIN is requested every time
- preferred: verify identity if the device supports it. This is also the default when nothing is specified
- discouraged: skip identity verification and pass with only the confirmation that the phone is present
So the answer to the question at the start is this. A service that asks for Face ID or a PIN has chosen the setting “I want to confirm not just that the phone is there but that the owner is operating it,” while a service that asks for nothing has chosen the setting “just confirming the phone is present is enough.”
Note that phones have their own device-side circumstances too. Even if the service says it is not required, devices like the iPhone ask for Face ID or a passcode every time a passkey is used. Logins that ask for nothing are more likely to happen with security keys or in a PC browser environment.
Comparing the flows makes the difference obvious. With identity verification, it looks like this.
sequenceDiagram
participant U as You
participant P as Phone
participant S as Service
S->>P: Please verify the key (identity verification: required)
P->>U: Please provide Face ID / fingerprint / PIN
U->>P: Do the same action as unlocking
P->>S: Respond "the key is here, and it is the owner"
S->>S: Verify and login succeeds
Without identity verification, the middle step disappears entirely.
sequenceDiagram
participant U as You
participant P as Phone
participant S as Service
S->>P: Please verify the key (identity verification: not required)
P->>S: Respond "the key is here"
S->>S: Verify and login succeeds
That is the whole difference. There are not two kinds of passkeys; even with the same passkey, the experience changes depending on which level of verification the service requires.
Why the Difference? Each Service’s Circumstances
So why do choices differ from service to service? This is a trade-off between security and usability.
Making identity verification required means that even if the whole phone is stolen, no one can log in unless they break through Face ID or the PIN. In exchange, the user takes one extra step every time. Services where the damage from a breach is large, like banks and payment services, choose this. A common approach is to keep login light and insert identity verification only right before important operations like transfers or setting changes.
On the other hand, skipping identity verification gives you the comfort of logging in with a single tap. In exchange, if the phone or security key is physically taken, that alone lets someone log in. That said, phishing resistance, which is a strength of passkeys, is preserved even without identity verification, so it remains strong against attacks over the network. For services with small damage, or when used as the second step of two-factor authentication combined with a password, this trade-off becomes reasonable.
In summary, services choose their setting based on judgments like these.
- The bigger what you are protecting (money, personal information), the more toward requiring identity verification
- The more a service is used daily, the more toward reducing friction
- If the only threat you worry about is attackers over the network, skipping is fine. If you also worry about phone theft, do identity verification
Summary
- What is confirmed at passkey login has two stages: “you possess the registered device” and “the person operating it is you”
- Face ID and PINs are the latter identity verification; what you enter is not the service’s password but the means of unlocking the device
- Whether to require identity verification is chosen by the service as a setting, and this is the real nature of “a passkey that needs a PIN” versus “one that does not”
- A service that requires it leans toward safety, one that does not leans toward comfort, and both behave exactly as the spec allows
Now you understand why the initial behavior when using a passkey differs by site.
References
