Why passkey creation is the new weak point
Passkeys close a lot of phishing risk at login, but they also move pressure to enrollment. The hard part is simple: if an attacker gets into an account once through a weaker path like a password, SMS OTP, or a recovery flow, they may not need to steal anything. They can just register their own passkey.
That changes the cleanup model. A stolen password is a copied secret, so a reset invalidates it. An attacker-created passkey is different: it is a new authenticator bound to the account, with a private key the attacker controls. Resetting the password does not remove that credential.
This is no longer theoretical. The July 2026 Microsoft 365 vishing campaign showed how attackers could walk users through a fake enrollment and bind their own credential. A month later, the same idea was already packaged as a kit.
Why userVerification: "required" is not enough
A common mistake is treating WebAuthn local checks as proof of account ownership. They are not.
If you set userVerification: "required", you prove that someone unlocked the authenticator locally. You do not prove that the authenticator belongs to the legitimate user. That distinction matters a lot during passkey enrollment security reviews.
The practical rule is stricter: creating a new passkey should require authentication at least as strong as the credential you are about to issue. A valid session alone is too weak if the session started with a phishable factor.
A safer enrollment path usually includes:
- fresh step-up authentication for passkeys before creation
- stricter checks for recovery-driven enrollment
- separate handling for weak sessions, even if the session is technically valid
- notifications through an independent channel after every new credential is added
This also applies to conditional create passkeys risk. Background or low-attention creation may improve adoption, but it still needs the same authorization standard as any visible enrollment flow.
Shared devices need policy, not guesswork
Shared endpoints are where secure passkey creation gets messy. If a platform passkey is saved in a shared OS profile or public terminal, anyone who can unlock that profile may be able to use it later.
The tricky bit is that WebAuthn does not reliably tell you whether a device is shared. Useful signals exist, but none gives perfect ownership proof.
| Signal | What it helps with | Limitation |
|---|---|---|
| Managed device posture | Strongest server-side policy input | Only available in managed environments |
| First-party device binding | Builds confidence from prior strong use | Not proof of ownership |
| Account switching patterns | Good risk signal for shared use | Needs calibration from real traffic |
| Browser/device fingerprinting | Corroboration only | Splits and collisions are common |
| IP, network, geolocation | Context for review | Too weak for allow/deny decisions |
That leads to a more useful shared device passkey policy: classify environments by risk, then change the enrollment path. On a kiosk or likely shared machine, suppress platform passkey creation and offer phone-based cross-device registration or a roaming security key instead.
Notifications, inventory, and revocation matter as much as enrollment
Even good defenses will miss some WebAuthn enrollment attack attempts. That is why passkey security notifications should fire whenever a credential is created, not only when a risk score crosses a threshold.
The notification should be independent of the enrollment session and include recognizable details like provider label, browser, OS, and timestamp. In-session banners are useful UX, but they are not enough for detection.
You also need visible credential inventory and revocation. Users and support teams should be able to see which passkeys exist, distinguish them clearly, and remove suspicious ones fast. That is the core of passkey incident response: first lock down account changes and revoke active sessions, then reset other factors. Do not start with the password reset and assume the problem is gone.
The deeper lesson is that passkeys do not protect weaker sign-in and recovery routes. Your real security boundary is still the weakest path accepted by the account.
Read the full breakdown.
Top comments (0)