How a passkey works
A passkey replaces a shared secret with a key pair. Microsoft's support FAQ describes it this way: your device generates a private key and a public key, the private key stays on your device, and the public key is registered with the site. At sign-in, your device signs a challenge from the site, and the site checks the signature with the public key.
Google's developer documentation adds that the site stores only the public key. An attacker can't derive the private key from the data on the server.
Where passkeys beat passwords
Phishing resistance is the big one. Microsoft's FAQ says a passkey is tied to the specific domain it was created for. A passkey created for netflix.com can only be used with netflix.com. A lookalike page can fool you, but your device won't hand it a valid response.
Reuse and credential stuffing disappear. Microsoft's Windows documentation notes that passkeys are unique to each website or application, which prevents reuse. There is no string you can type into the wrong site.
Server breaches matter less. A stolen database of public keys has no login value. The FIDO Alliance says password database breaches no longer pose a threat, because there are no passwords to steal. That doesn't mean breaches stop mattering for other data.
| Threat | Password | Passkey |
|---|---|---|
| Fake login page | Can be typed in and stolen | Domain-bound, so the device won't respond |
| Reuse across sites | Common | Not possible |
| Server database breach | Hashes can be cracked | Only public keys exposed |
| Guessing or brute force | Depends on strength | Not applicable |
Biometrics: what actually happens
The TechRadar piece reassures readers that fingerprints and face scans stay local. That's correct. The FIDO Alliance says biometric processing stays on the device and is never sent to a remote server. The server only sees an assurance that the biometric check succeeded. Microsoft's Windows documentation says the same, that biometric information remains on the user's device and isn't transmitted across the network or to the service.
Two refinements:
- Biometrics aren't required. Google's documentation lists a PIN or pattern as alternatives to fingerprint or face. The biometric is just one way to authorize use of the key.
- Microsoft counts passkeys as multi-factor. Its FAQ describes something you have (the device) plus something you are or know (biometrics or PIN). The FIDO Alliance adds a caveat. This applies if the relying party requests user verification.
Where the simple story gets complicated
The article says the private key "stays securely locked on your device." That's true for device-bound passkeys. It isn't the whole picture for synced ones.
Microsoft's Entra documentation explains that a synced passkey's private key is created by hardware security on the local device and encrypted. The encrypted key is then synced and stored in a cloud passkey provider, such as iCloud Keychain or Google Password Manager. The FIDO Alliance calls both synced and device-bound passkeys phishing-resistant but distinguishes the two models.
The practical result is a shift in what you need to protect:
- Device-bound (Windows Hello, a hardware security key): the credential is not exportable. If the device is gone, so is the passkey, unless you registered others.
- Synced (iCloud Keychain, Google Password Manager, third-party managers): the credential survives losing a device. The account that holds the sync becomes the key worth guarding. Third-party commentary makes the same point. One security explainer says an attacker who can authorize a new device may be able to pull your synced passkeys onto it.
- For regulated or high-assurance settings: Microsoft's Entra guidance says that for administrators and highly privileged users, device-bound options such as FIDO2 security keys or passkeys in Microsoft Authenticator are the better fit. It also notes that synced passkeys don't support attestation. One third-party comparison reports NIST treats synced passkeys as AAL2 rather than AAL3, which is worth checking against NIST's own guidance if you work in compliance.
The stolen-phone scenario
TechRadar warns that a thief who has your device and knows your PIN could potentially reach your passkey-protected accounts. That's a fair concern. The weak point is the unlock method, and a short PIN that's been shoulder-surfed is a real exposure. But it's narrower than "all accounts, automatically". It requires physical possession plus the unlock secret, or compromise of the provider account.
That is a different threat model from a password that anyone on the internet can phish or stuff. One vendor blog says attacks on passkeys don't scale because the attacker must physically have the device and the user verification method. That's a vendor view, but it matches the logic of the design.
Two practical habits follow:
- Use a strong device PIN or passcode, not 1234.
- Protect your Apple, Google or Microsoft account with strong MFA, since it may hold your synced passkeys.
Passkeys don't close every door
Passkeys protect the sign-in step. They don't automatically fix:
- Fallback methods. One analysis notes most services leave password login enabled alongside passkeys, so an account stays phishable until that path is removed. Weak recovery flows, such as SMS or security questions, can be a way around a strong credential.
- Session theft. If an attacker steals a session after you've logged in, the passkey wasn't involved.
- Implementation flaws. How-To Geek reported research dubbed "Pass-ta-key" that works only on Windows and, by the looks of it, only if passkeys are managed by Google Password Manager in Chrome. The same piece concludes this isn't a flaw in passkeys themselves. It does show that where the passkey is stored matters.
Lock-in and moving between ecosystems
TechRadar says moving between iPhone and Android can be a headache and suggests you might be locked out unless you've exported your passkeys. I wouldn't repeat that as a universal rule. Portability is real but still maturing. One enterprise explainer says the FIDO Alliance's Credential Exchange Protocol aims to fix this, but full interoperability isn't yet standard.
The FIDO Alliance describes several workarounds:
- Use a cross-platform credential manager, such as 1Password or Dashlane. Setting it up on the new device makes your passkeys available there.
- Use a FIDO security key, which works on any new device.
- If you still have the old device, use its passkey to sign in on the new one, then create a new passkey with the new device's provider.
Microsoft's guidance for replacing a device is similar. If your passkeys were stored on the old device, add new ones, then remove the old ones. If they were in a synced credential manager, you can just sign in to that manager. Phone-to-laptop sign-in through a QR code needs Bluetooth and internet access on both devices. Microsoft's FAQ says a proximity check ensures a remote attacker can't use it from far away.
What Windows users and admins should know
- Native management: Microsoft says Windows 11, version 22H2 with KB5030310 provides a native passkey management experience, though passkeys can be used on all supported Windows client versions. Microsoft's FAQ says the latest passkey features need Windows 11.
- Where to manage them: In Windows 11, view and delete locally saved passkeys under Settings > Accounts > Passkeys. Advanced options let you turn passkey services on or off and configure third-party managers.
- Privacy consent: Starting in Windows 11 version 24H2, users are prompted for consent before apps can access passkeys. If you decline, passkey sign-in won't work for that app until you allow it under Settings > Privacy & security > Passkey access.
- Don't strand yourself: Microsoft warns that removing your last security info puts a personal account into a 30-day restricted state. Add a replacement sign-in method before deleting an old passkey. For work or school accounts, delete the passkey in your Security info page and where it's saved, such as Windows Hello.
- Enterprise choices: Admins can enable synced passkeys via a Passkey (FIDO2) profile in Entra authentication methods, with Authentication Policy Administrator rights. Microsoft's own figures for its consumer accounts claim 99% successful registration and a 3-second sign-in versus 69 seconds for password plus traditional MFA. Those are Microsoft's numbers, so treat them as vendor data.
- Bluetooth-restricted environments: Microsoft documents a way to permit passkey cross-device sign-in while limiting Bluetooth to FIDO2 authenticators, using Bluetooth and device installation policies in Intune.
- Policy limits: Microsoft says some passkey options may be disabled by an IT admin or are unavailable on organization-managed devices.
Bottom line
Passkeys are stronger than passwords against phishing, reuse and server-side credential theft, which covers the most common ways accounts get taken over. They are an upgrade, not a magic wand.
A sensible plan:
- Turn on passkeys for email, banking, Microsoft, Google, Apple and code-hosting accounts first.
- Know whether each one is device-bound or synced.
- Lock down the device unlock and the provider account.
- Register a second passkey or recovery method before you retire a device.
- Where the service allows it, remove the old password and weak recovery options.
If you can't do that last step, you've added a strong front door but left the old window open.