Several tools in our environment are making passkeys the default or mandatory alternative to passwords and traditional MFA. The sign-in flow asks for an email address and then prompts the user to approve a passkey, sometimes through a password manager that syncs passkeys between devices.
I'm struggling to understand how this qualifies as two-factor authentication. My understanding was that MFA combines at least two of something you know, something you have, or something you are. In some implementations, the passkey seems to amount to trusting the computer or password-manager vault. If a user leaves their computer unlocked, or their laptop is stolen while unlocked, someone nearby might be able to enter the email address and approve the passkey without needing the user's phone or a separate code.
With TOTP, the attacker generally still needs access to the user's phone and its unlock protection. That seems stronger against an unattended workstation. Are passkeys actually providing two factors, or are some implementations merely treating a device as trusted? How should device-bound and synchronized passkeys be evaluated, and what policies should be used to reduce walk-up or stolen-device risks?
3 Answers
Device-bound and synchronized passkeys should not be treated as identical. A device-bound credential stays tied to one authenticator, such as a hardware key or a platform secure enclave. A synchronized passkey can be restored on other approved devices through a password-manager or operating-system account, which improves recovery and usability but broadens the protection and recovery requirements.
For higher-risk administrators, hardware security keys with a PIN and touch requirement are a strong option. For ordinary users, platform passkeys can still be a major improvement over passwords and TOTP because they resist phishing, password reuse, SIM swapping, and MFA-code theft. The organization should define recovery procedures, require user verification where appropriate, and avoid leaving the password manager permanently unlocked.
Passkeys are not login cookies. They use public-key cryptography, with the private key held by a device, hardware security module, secure enclave, or password manager. During authentication, the service sends a challenge and the passkey signs it; the private key is never sent to the site. Because the credential is bound to the legitimate website, a phishing site cannot normally use it to authenticate to the real one.
A passkey is generally used with user verification, such as a device PIN, password, fingerprint, or face recognition. In that setup, the factors are possession of the device or credential and verification of the user. A hardware security key can provide an especially clear separation: the key is required, and its PIN or touch policy can be enforced.
The unattended-computer example is a real security problem, but it is not unique to passkeys. If someone can use an already-unlocked workstation, an active browser session, or an unlocked password manager, they may be able to access applications without performing MFA again. TOTP does not necessarily solve that if the attacker can use an already-authenticated session or obtain the code through the workstation.
The mitigations are endpoint and session controls: enforce automatic screen locking, require password-manager reauthentication before passkey use, use short session lifetimes for sensitive applications, require step-up authentication for privileged actions, and remotely revoke credentials when a device is lost. Passkeys reduce phishing and credential theft; they do not replace physical-security and session-management controls.
For an insider who deliberately waits for an unlocked workstation, a separate phone-based TOTP can be harder to use because the phone may be with the user. That is a different threat model from phishing, though, and should be addressed with workstation-locking policy and reauthentication requirements rather than assuming TOTP is universally safer.
The important qualification is configuration. Some flows require only user presence, while others require user verification. Organizations should verify which mode their identity provider and password manager are using rather than assuming every passkey deployment has the same protections.