Why do passkey and password coexistence models create account governance risk?

They create risk because the same person can arrive through multiple authentication paths, which can produce duplicate records or ambiguous ownership if linking is not deterministic. IAM teams need one authoritative merge rule, otherwise access reviews, revocation, and audit trails become inconsistent across sign-in methods.

Why This Matters for Security Teams

Passkey adoption is meant to reduce phishing and credential replay, but coexistence with passwords can create a second governance problem: the identity layer may no longer have a single, deterministic record for one person. When a user can authenticate through multiple paths, the join logic becomes just as important as the authenticator itself. Without authoritative merge rules, account ownership can drift, reviews become inconsistent, and revocation may only partially work. That is why identity governance must treat linking as a control, not a convenience.

This issue is visible in broader identity-risk research as well. In Ultimate Guide to NHIs — Regulatory and Audit Perspectives, NHIMG highlights how auditability depends on stable identity records, and the same principle applies when people can appear through passkey and password pathways. The control objective is not just successful login, but unambiguous ownership across all sign-in methods. Current guidance suggests this should be handled as an identity lifecycle issue, not only as an authentication upgrade.

In practice, many security teams discover the mismatch only after a disabled password path still leaves an active passkey-backed account, rather than through intentional identity design.

How It Works in Practice

The safest coexistence model starts with one authoritative identity record and one merge rule that binds passkeys, passwords, and any recovery factors to that record. During enrollment, the system should require strong proof of continuity before attaching a new authentication method. That can include step-up verification, existing-session confirmation, or an admin-reviewed workflow for high-risk accounts. The point is to prevent separate records from forming around the same person.

Operationally, IAM teams should define how matching works across directories, HR systems, and customer identity stores. If the same user can appear through different email aliases, devices, or registration paths, deterministic linking must be based on a stable internal identifier, not on whichever credential was used most recently. This is especially important for audit trails, because a review that spans two partial records can miss privilege creep or make revocation appear complete when it is not.

For governance teams, the practical controls are simple in concept but demanding in execution:

• Use one canonical account per person, with passkeys and passwords attached as methods, not as separate identities.
• Require deterministic merge logic before creating a new record when an existing identity already exists.
• Log method enrollment, unlinking, and recovery events as first-class audit events.
• Test deprovisioning to confirm that removing one method does not leave an unintended path active.

Where this becomes more complex, the security objective still stays the same: stable identity ownership must survive method changes. That alignment is consistent with the NIST Cybersecurity Framework 2.0 emphasis on governed access lifecycle management, and with NHIMG’s Top 10 NHI Issues, which repeatedly shows that identity sprawl begins when records are created faster than they are reconciled. These controls tend to break down in federated environments with multiple IdPs and weak account-linking rules because no single system can prove which record is authoritative.

Common Variations and Edge Cases

Tighter account linking often increases operational friction, requiring organisations to balance user convenience against the risk of duplicated ownership. That tradeoff becomes more visible in passwordless rollouts, helpdesk recovery, and delegated administration, where a strict merge rule can slow enrollment but a loose rule can create shadow accounts. Best practice is evolving, but there is no universal standard for this yet.

Edge cases usually involve recovery and transition states. For example, a user may begin with a password, add a passkey, then lose device access and rely on fallback methods. If the fallback process creates a new account path instead of returning to the canonical record, governance is lost. Shared devices, contractor onboarding, and merged subsidiaries also complicate linkage because the same person may be known by different authoritative systems.

NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces a useful operating rule: identity state changes must be tracked across creation, linking, use, and retirement. For coexistence models, that means passkeys should be treated as stronger authentication methods, not as separate identity containers. When organisations fail to separate method management from account governance, access reviews become method-specific instead of person-specific, and that is where audit gaps appear.

Related resources from NHI Mgmt Group

• Why do custom JWT claims create governance risk if they are not refreshed?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?