Teams should treat passkey sign-in as device-initiated, not username-initiated. Present available passkeys as soon as the user focuses the sign-in field or opens the authenticator flow, then use the credential’s internal identifier to find the account. If no passkey is available, fall back to a familiar passwordless path such as email OTP or magic link.
Why passkey sign-in should be device-initiated
Passkeys work best when the user starts from an available authenticator, not from a typed username. That design removes a fragile step, but it also changes the account lookup problem: the system must be able to surface the right credential options before it knows which account the user intended. The sign-in experience should therefore be shaped around account discovery, credential selection, and graceful fallback rather than a legacy username field.
This matters because usernames are often the least useful part of modern authentication UX. People reuse email addresses, share devices, use multiple accounts, or forget which identifier a service expects. A device-initiated flow reduces friction and avoids forcing users to type something only to abandon it one step later. It also supports stronger authentication because the authenticator can present a passkey only when the relying party and device can complete the ceremony correctly. For teams implementing passwordless paths, the practical question is not whether the username disappears, but how the account is resolved without making the user guess.
Ultimate Guide to NHIs is useful here because the same design instinct applies to machine identities: strong authentication works better when the credential is discovered and bound to the right principal, rather than recovered through a brittle manual lookup. In practice, teams often discover this only after users have already failed at the username step and support has to untangle which account the passkey was actually tied to.
How passkey-first account discovery works in practice
A good passkey sign-in flow begins by letting the browser, platform authenticator, or external security key participate before the user has committed to a username. When the user focuses the sign-in field, taps a “Continue with passkey” control, or opens the authenticator prompt, the application can ask the platform to surface eligible credentials. The authenticator then uses its internal credential identifiers and relying-party binding to match the correct account or accounts.
In practice, teams usually need three pieces working together:
- Account discovery that can match a passkey to one or more known accounts without requiring a typed identifier first.
- A fallback path for users who have no passkey on the current device, such as email OTP, magic link, or an alternate recovery method.
- Session handling that avoids creating ambiguous states where the user has selected an authenticator but the application still expects a username.
Current guidance suggests making the passkey path obvious and immediate, while preserving a low-friction fallback for enrollment gaps, shared devices, and first-time sign-ins. If the user has multiple accounts with the same authenticator, the UI should help them choose the correct account after discovery rather than forcing them to guess before the passkey prompt appears. This is where the design becomes less about login fields and more about reliable identity matching across devices.
Teams should also think about error handling. If the authenticator does not return a usable credential, the application should explain the next step clearly instead of treating the attempt as a generic failure. That avoids accidental lockout and reduces support burden. The underlying ceremony is still passkey-based, but the user experience should remain forgiving enough to handle device loss, sync delays, or browser limitations. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant where teams need to anchor the sign-in flow in strong authentication, account lifecycle, and session control expectations. These controls tend to break down when product teams assume every user has exactly one discoverable passkey on exactly one device, because account ambiguity and fallback logic then become the real source of failure.
Common edge cases and design trade-offs
Tighter passkey discovery often improves usability, but it also increases the need for careful account matching, especially in environments where users have multiple accounts, shared devices, or federated identity boundaries. The trade-off is between removing friction and avoiding the wrong-account problem. If the application cannot safely disambiguate identities, it should ask for an additional cue after the passkey prompt rather than before it.
There is also a genuine implementation difference between passkeys stored locally and passkeys synced across devices. Synced credentials make device-initiated sign-in much easier, but teams should still design for the case where a credential is absent, unavailable, or not yet propagated to the current device. Best practice is evolving, but the consistent principle is simple: do not make the username field the gatekeeper for a passwordless authenticator flow.
For regulated or high-assurance environments, the fallback path deserves the same attention as the passkey path. If email OTP or magic link is the recovery route, it should not silently become the primary login method. That undermines the purpose of passkeys and can create inconsistent assurance levels across user populations. The strongest designs make passkey use the default, keep fallback clearly bounded, and make account discovery accurate enough that users rarely need to think in terms of usernames at all.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 — Identity Management, Authentication, and Access Control | Passkey flows are an authentication design problem. |
| PR.AA-3 — Remote Access is Managed | Passkey sign-in affects how remote user access is established. | |
| PR.PS-3 — Third-Party Services are Managed | Passkey sign-in often depends on external authenticators and synced identity services. | |
| Recommendation — Implement passwordless authentication that verifies users without relying on usernames first. Control remote sign-in paths so passkey login and fallback access are consistently governed. Assess external identity dependencies that support passkey discovery and fallback sign-in. | ||
| CIS Controls v8 | 5 — Account Management | The question centers on user account discovery and authentication flow. |
| 6 — Access Control Management | Passkey sign-in must still enforce correct access decisions after discovery. | |
| Recommendation — Maintain accurate account records and authentication methods for passwordless sign-in. Apply access-control rules that bind discovered credentials to the correct account. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | Passkeys are an authenticator design choice within digital identity assurance. |
| Recommendation — Use approved authenticators and ensure the sign-in ceremony meets the intended assurance level. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Access Requests | Device-initiated sign-in aligns with requesting access based on verified context. |
| Recommendation — Evaluate sign-in requests using context and authenticators rather than username-first assumptions. | ||
Practitioner Guidance
What to prioritise: Design the first interaction around credential discovery, not identifier entry. The UI should surface passkey options immediately, then use account hints, prior-session context, or authenticator results to narrow the match.
Decision rule: If the system cannot confidently map a discovered passkey to a single account, stop short of auto-login and ask for one additional disambiguation step. If it can match reliably, do not force a username prompt just to preserve legacy flow symmetry.
What practitioners underestimate: The hardest part is usually not the passkey ceremony itself but the fallback and recovery paths. Teams should verify that a missing or unavailable passkey does not strand users in a loop where the product still behaves like a password-first system.
Practitioner takeaway: A good passkey experience removes the username as a required starting point, but it does not remove the need for accurate account resolution, explicit fallback design, and careful handling of ambiguity.
Related resources from NHI Mgmt Group
- How should organisations reduce reliance on legacy MFA methods without making sign-in harder for users?
- How should teams use OpenID Connect to simplify customer sign-in without weakening security?
- How should security teams authenticate AI agents in enterprise environments?
- How should SaaS teams authenticate users, partners, and workloads without mixing trust boundaries?
