Duplicate accounts can appear when Cognito treats a federated passkey user as new even though a password-based account already exists. That splits roles, permissions, and audit history across records, which makes account continuity and offboarding harder to govern.
Where Cognito account continuity breaks
When passkeys are introduced into an existing user pool, the breakage is usually not in authentication itself, it is in identity resolution. If Cognito does not have merge logic, the same person can be represented by separate records for password and federated passkey sign-in. That creates two account paths that may look valid independently but do not behave like one user across the application.
The practical consequence is that the system no longer has a single source of truth for that user’s profile, entitlements, recovery state, and sign-in history. One account can continue to receive new sessions while the older record still carries legacy roles or disabled-state assumptions. In mixed authentication estates, that problem is especially easy to miss during rollout because each login method appears to work on its own.
For a useful implementation reference on passkey rollout and recovery behaviour, see Passwordless and Passkeys Guide and NIST SP 800-63 Digital Identity Guidelines.
Which controls and records drift apart
The first thing that breaks is usually authorization consistency. Roles, permissions, and group membership can diverge between the password account and the newly created passkey account, so access decisions stop being predictable. The second is governance data: audit trails, last-login evidence, and account ownership can split across records, which makes reviews, attestations, and investigations harder to interpret.
This is why lifecycle handling matters as much as sign-in handling. If the environment already has joiner-mover-leaver processes, the new passkey identity must inherit or map cleanly to the existing user, otherwise offboarding can remove one record while leaving the other active. NHIMG’s NHI Lifecycle Management Guide is useful here because the failure mode is fundamentally lifecycle drift, even if the immediate symptom is a second sign-in method.
For practitioners who want a broader account-security view, Workforce Identity Security Guide and Identity Provider and SSO Security Guide help frame how federation, recovery, and session handling become part of the same control surface.
Why duplicate identities become an operational risk
Duplicate user records are more than a cosmetic data issue. They can produce over-privilege if one record is granted access during a migration and the older record retains inherited access from before the migration. They also complicate incident response, because an investigator may have to determine which record issued the active session, which record owns the alert, and which record should be disabled first. Top 10 NHI Issues covers the same pattern of identity sprawl and entitlement drift from a governance perspective.
The issue is amplified when password sign-in and passkey sign-in can both remain valid during a transition period. In that case, revocation has to be exact: disabling one authentication path does not necessarily terminate the other record or its sessions. For teams using passkeys because they are phishing-resistant, Passwordless and Passkeys Guide is the right companion reference because it highlights the rollout and recovery decisions that determine whether the migration stays coherent.
Risk and Threat Considerations
Duplicate accounts create an avoidable trust gap during migration. The exposed risk is not just extra admin work, it is unauthorized continuity: a user who should have one governed identity can end up with two partially independent access histories, which weakens offboarding, review, and forensic confidence.
Failure mechanism: Cognito treats the passkey-backed sign-in as a new federated identity instead of binding it to the pre-existing password account, so entitlements, profile data, and session history fragment across records.
Impact: Access may persist on the wrong record, audit evidence becomes split, and removal actions can miss the surviving identity, leaving an orphaned path back into the application.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkey rollout depends on managing authenticators and their lifecycle across sign-in methods. |
| IA-9 — Service Identification and Authentication | Federated passkey sign-in creates a separate authentication path that must be bound correctly to the existing account. | |
| AC-2 — Account Management | Duplicate user records are an account lifecycle problem that affects provisioning, revocation, and review. | |
| Recommendation — Track and govern authenticators so a new passkey does not create an unmanaged second identity path. Bind federated and passwordless authentication to the same subject before granting access. Maintain one authoritative account record and merge duplicates before they reach production access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Split identities make revocation and offboarding incomplete when one record survives the migration. |
| NHI-09 — NHI Reuse | Existing users can be treated as new identities when passkey mapping is missing, creating parallel records. | |
| Recommendation — Ensure every login path is tied to the same offboarding action and revocation record. Prevent parallel identities by linking the new passkey to the pre-existing account before activation. | ||
Practitioner Guidance
What to verify: Before enabling passkeys, confirm how the user pool correlates an existing password account to a newly presented federated or passwordless assertion. If the mapping is not deterministic, treat the rollout as an identity-migration problem, not a simple authentication upgrade.
Decision rule: If a second record can be created for the same person, require explicit merge or linking logic, and define which record owns roles, recovery factors, and revocation authority. If that cannot be enforced, restrict the rollout to a controlled cohort until continuity is proven.
What practitioners underestimate: The hardest part is usually not enrolling the passkey, it is preserving the continuity of authorization and offboarding after the first successful login. The safest outcome is one person, one governed account, one audit trail.
Practitioner takeaway: A passkey rollout is only clean when the new authenticator inherits the existing identity, otherwise you have improved login security while degrading account governance.
Related resources from NHI Mgmt Group
- What breaks when extension logic is added without configuration discipline?
- What breaks when digital identity wallets are added without a connector strategy?
- How should organisations roll out passkeys in a federated user pool without creating duplicate accounts?
- What breaks when identity verification is added to legacy systems without a middleware layer?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org