A weak design shows up when users see only one account option even though multiple passkeys exist, or when shared devices create confusion over which identity is being selected. This usually means the account discovery and selection step is too rigid. A better flow should support multiple passkeys, clear choice, and reliable account lookup after selection.
Why Passkey Login Breaks Down on Shared Devices
A passkey flow that works well for a single person can feel broken the moment a device is shared or a user has several accounts. The main sign is not just friction, but ambiguity: users cannot tell which account will be used, which passkey belongs to which identity, or whether the system can reliably find the right credential after the first choice. That ambiguity matters because passkeys are meant to reduce both phishing and password handling, not force people back into ad hoc workarounds.
In practice, weak designs show up as account pickers that collapse too much context, login screens that assume one device equals one identity, or recovery steps that become the real authentication path. Shared tablets, family laptops, kiosk-like environments, and employees who maintain multiple work and personal identities often expose these flaws immediately. When a flow does not clearly separate identity choice from authentication, users start selecting the wrong account, retrying until they are unsure what succeeded, or abandoning the passkey entirely.
How a Well-Designed Flow Should Behave
A better passkey experience separates discovery, selection, and verification without making the user repeat themselves. The login surface should allow more than one credential to be visible when more than one account is legitimately available, and it should present enough context for a user to distinguish identities at a glance. That context might include an email, tenant name, display label, or organization hint, provided it is consistent and not overloaded with jargon.
On shared devices, the system should not assume a remembered session equals the right identity. It should confirm the account before binding the passkey operation to a final authentication result, especially where local browser state, synced passkeys, or platform credential managers can surface multiple plausible matches. This is particularly important for users who move between managed and unmanaged devices, because the credential availability pattern changes even when the underlying identity does not.
Good flows also avoid making fallback behavior look like success. If the page silently falls back to a password, email link, or recovery path whenever account selection is uncertain, the passkey experience becomes inconsistent and harder to trust. Current guidance suggests that the best designs make the available choice obvious, keep the selection state visible, and fail clearly when the system cannot resolve the intended account rather than guessing.
For practitioners, the operational test is simple: a user should be able to land on a shared device, identify the correct account quickly, and complete the login without needing to infer which identity the browser or platform is trying to help with. The NIST SP 800-53 Rev 5 Security and Privacy Controls document is useful background when you are mapping that behaviour to access-control and authentication expectations, and NHI Mgmt Group’s Ultimate Guide to NHIs is a useful reminder that identity systems fail fastest when visibility and lifecycle assumptions are too narrow.
These controls tend to break down when passkey discovery is delegated entirely to the platform with no application-level context, because the system can no longer distinguish a convenient match from the intended one.
Common Variations and Edge Cases
Tighter account matching often improves precision, but it can also create friction for people who legitimately use several accounts on the same device, so teams need to balance clarity against extra clicks. There is no universal standard for how much account context is enough yet, and passkey UX is still evolving across browsers, operating systems, and identity providers.
One edge case is a user with two accounts that share the same email domain or display name conventions. Another is a household or lab device where the same browser profile is used by different people. In those cases, the design must avoid overreliance on stale local hints, because the wrong hint can be more harmful than no hint at all. Another common failure is assuming synced passkeys will make account discovery easier everywhere; in reality, sync can increase the number of plausible matches and make the wrong-choice problem worse if the picker is poorly labeled.
Practitioners should also watch for accessibility and recovery trade-offs. If the only way to disambiguate accounts is by visual cues that are hard to scan, the flow may be technically correct but operationally weak. Likewise, if recovery becomes the default path whenever account selection is uncertain, the organisation may accidentally push users away from passkeys and back into weaker login habits.
Risk and Threat Considerations
When passkey flows are not designed for shared devices or multi-account use, the main risk is account confusion that turns into unintended access, failed authentication, or unsafe fallback behaviour. That is a governance and access-control problem as much as a usability problem, because weak account resolution can blur the boundary between identities that should remain separate.
Failure mechanism: The flow either shows too little identity context, resolves to the wrong account after a credential match, or pushes the user into a fallback path when the intended account is not obvious. On shared endpoints, browser state and platform credential managers can widen the set of plausible accounts, increasing the chance of mis-selection or repeated retries.
Impact: Users may authenticate to the wrong account, lose confidence in passkeys, or bypass the intended flow through password reset or alternate login methods. In higher-risk environments, that can also create audit ambiguity about which identity actually completed the session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while 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 authentication and account-resolution controls. |
| Recommendation — Validate account selection and authenticate only the intended identity. | ||
| CIS Controls v8 | 6 — Access Control Management | Shared-device passkey issues expose access-control weaknesses. |
| Recommendation — Require clear account binding and remove ambiguous login fallback paths. | ||
| NIST SP 800-63 | 6.1 — Authenticator Lifecycle Management | Passkeys are authenticators whose usability depends on lifecycle and binding. |
| Recommendation — Bind each passkey to the correct subscriber account and verify retrieval logic. | ||
| NIST Zero Trust (SP 800-207) | SP 800-207 — Zero Trust Architecture | Shared-device ambiguity weakens strong identity assurance at the access edge. |
| Recommendation — Treat identity selection as a policy decision and verify before granting access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Inventory and Ownership | Multi-account passkey confusion mirrors lifecycle and ownership ambiguity in machine identity systems. |
| Recommendation — Maintain clear ownership and inventory for every credential-bound identity. | ||
Practitioner Guidance
What to verify: Test the flow on shared devices with at least two valid accounts, then confirm that the picker shows enough context to distinguish them and that the post-selection step returns the user to the exact intended identity. If the UI cannot make the choice unambiguous without extra user memory, the design is too fragile.
Decision rule: If the application cannot reliably resolve identity after selection, treat that as a design defect rather than a user-training issue. The fix is usually clearer account presentation, better binding between account choice and credential discovery, and removal of silent fallback paths that mask the problem.
Practitioner takeaway: A passkey flow is well designed only when identity choice remains obvious on shared devices and the system never has to guess which account the user meant.
Related resources from NHI Mgmt Group
- How should security teams handle passkey login when users switch devices?
- What breaks when shared mobile devices stay signed in between users?
- What do users and organisations get wrong about session safety on shared devices?
- Who is accountable when an OAuth login flow allows account takeover through weak redirect controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
