Users can be split across multiple accounts, each with its own access history and entitlement set. That creates confusion during support, recovery, and audit, and it can also produce inconsistent authorisation if one account is treated as primary and another as a duplicate.
Why This Matters for Security Teams
When a passkey is created without linking it to the existing user record, identity assurance fragments at the first step of enrollment. The same person can end up with separate profiles, each with different access history, recovery paths, and entitlement decisions. That undermines auditability and makes it harder to prove which record is authoritative during a support call, incident review, or access certification.
This is not just an account hygiene problem. It affects authentication, authorisation, and lifecycle control at once. NIST guidance emphasises that identity records need a consistent trust relationship across the full lifecycle, which is why the NIST Cybersecurity Framework 2.0 treats identity management as an operational control, not a one-time setup task. In practice, split identities can lead to duplicate approvals, broken recovery, and access being granted to the wrong record after a reset or re-enrolment.
NHIMG research shows how often identity drift becomes a real exposure problem: NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams encounter duplicate-account fallout only after a user loses access, a help desk restores the wrong profile, or an auditor asks why entitlements do not match the person they belong to.
How It Works in Practice
The safe pattern is to bind the new passkey to the existing authoritative identity record before it is accepted for production use. That usually means the user first proves control of the current account through a strong recovery or step-up flow, then the passkey is attached as an additional authenticator rather than creating a new principal. The identity source of truth remains the same, while the credential changes.
That linkage matters because authorisation decisions are usually built on the user record, not the authenticator alone. If a passkey spawns a duplicate account, entitlements can diverge over time: one profile may receive new roles, while the other stays stale. This creates hidden privilege gaps and inconsistent approvals, especially where NHI Mgmt Group governance is already struggling with incomplete visibility, and where teams are trying to align identity workflows with NIST Cybersecurity Framework 2.0 identity and access practices.
- Match the passkey enrollment to a verified user identity, not just a successful authentication event.
- Use one authoritative user record for recovery, entitlement review, and session logging.
- Merge or retire duplicates quickly, with clear rules for which account keeps history and which is disabled.
- Log linkage events so support, audit, and incident response can trace when the passkey was attached and by whom.
Where possible, the identity platform should prevent silent auto-provisioning into a new account when a match already exists. These controls tend to break down in federated environments with weak account matching, inconsistent email aliases, or legacy directories that cannot reliably reconcile the same person across systems.
Common Variations and Edge Cases
Tighter account-linking often increases enrollment friction and support overhead, so organisations have to balance usability against the risk of account sprawl. That tradeoff becomes sharper when users return after long inactivity, change email domains, or move between internal and external identities. Current guidance suggests that the linking rule should be explicit and deterministic, but there is no universal standard for exactly how much identity proof is enough before a passkey is attached.
High-risk edge cases include mergers, contractor conversions, and shared-device environments. A person may legitimately have more than one identity record across business units, but the security team still needs one primary record for access decisions. If the platform cannot reconcile records cleanly, the result is often duplicate approvals, inconsistent MFA status, or orphaned access that survives after the original account is closed.
Operationally, teams should treat passkey linkage as part of identity lifecycle governance, not just authentication setup. That means reviewing duplicate detection rules, defining escalation paths for merge conflicts, and making sure recovery processes cannot silently create a second authoritative record. The JetBrains GitHub plugin token exposure and the Schneider Electric credentials breach both underline how weak credential governance can compound into broader access risk when identity records are not cleanly controlled.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Passkey linkage depends on unique identity assignment and access control accuracy. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Duplicate identities create unmanaged access paths and weaken lifecycle governance. |
| NIST AI RMF | Identity drift is a governance risk that affects accountability and traceability. |
Prevent duplicate records and enforce one primary identity per person or workload.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
