What breaks when shared accounts move to passkeys without lifecycle controls?

The biggest failure is false confidence. Teams may assume that passwordless login has solved the problem, while the account remains shared, overexposed, or difficult to revoke. That creates a governance gap where access remains active longer than intended and audit evidence is incomplete.

Why This Matters for Security Teams

Moving a shared account to passkeys can remove password reuse, phishing exposure, and weak authentication prompts, but it does not fix the harder problem: who owns the account, who can use it, and how fast access can be revoked. Without lifecycle controls, a passwordless shared account can become easier to enter yet harder to govern, because the credential event is modern while the administration model stays stale.

That gap matters most for service desks, operations teams, contractors, and emergency access accounts where multiple people rely on the same identity. Current guidance from the OWASP Non-Human Identity Top 10 treats lifecycle and secret handling as separate failure points for a reason: authentication strength does not compensate for missing ownership, revocation, or auditability. NHIMG research on NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows how often organisations lose control once an identity is shared across users or teams. In practice, many security teams discover the revocation problem only after a staff change, incident, or audit request, rather than through deliberate lifecycle design.

How It Works in Practice

Passkeys improve the authentication step, but shared accounts still need lifecycle controls around assignment, approval, use, and deprovisioning. If a passkey is bound to a shared mailbox, admin console, or break-glass account, the organisation must still answer basic governance questions: who is allowed to enrol the passkey, who approves use, how is it stored, and how is it removed when the account is no longer needed?

In practice, the control plane should treat the shared account like any other privileged NHI: define an owner, limit the number of authorised users, record enrolment events, and require a joiner-mover-leaver process for access changes. The Guide to the Secret Sprawl Challenge is relevant here because passkeys often reduce password handling while leaving adjacent credentials, recovery channels, and session tokens untouched. NHI governance should also track where the passkey is enrolled, whether the platform supports revocation, and whether backup methods silently reintroduce weaker access paths.

• Use a named business owner for every shared account and make revocation part of the owner’s obligations.
• Keep enrolment and recovery methods under change control, not ad hoc helpdesk handling.
• Log who used the account, from where, and under what approval or ticket reference.
• Prefer per-person access or delegated admin roles when the workflow allows it.

Static authentication is not enough if the account survives personnel changes, tool migrations, or vendor offboarding. The NCSC guidance on FIDO2 authentication supports stronger login, but it does not remove the need for identity lifecycle governance. These controls tend to break down when one passkey is registered to a long-lived shared admin account across multiple teams because nobody can prove timely revocation or exclusive ownership.

Common Variations and Edge Cases

Tighter control over shared accounts often increases operational overhead, requiring organisations to balance cleaner revocation against faster team access. That tradeoff becomes visible in emergency access, legacy platforms, and third-party integrations where individual identities cannot yet replace a shared one.

Best practice is evolving, but current guidance suggests treating these cases as exceptions with compensating controls rather than normalising them. For example, a break-glass shared account may use passkeys, but it still needs separate vaulting, approval, alerting, and periodic access reviews. A service account used by automation should not rely on human passkey enrolment at all; it should be governed as an NHI with explicit lifecycle automation instead. The Top 10 NHI Issues is useful here because shared access, poor offboarding, and secret sprawl often co-occur.

There is no universal standard for passkey lifecycle management on shared accounts yet, so organisations should document local policy for enrolment, rotation, recovery, and deprovisioning. Where auditability is the priority, keep the number of people able to exercise the passkey as small as possible and tie every use to an accountable human workflow. Otherwise, a passwordless shared account can still outlive the people who were supposed to control it.

Related resources from NHI Mgmt Group

• What breaks when prompt injection meets shared service accounts?
• What breaks when private PKI is deployed without lifecycle governance?
• What breaks when legacy service accounts are left outside modern identity controls?
• What breaks when passkeys are synced without strong account recovery controls?