Passkeys in Amazon Cognito expose the hidden IAM merge gap

At a glance

What this is: This guide shows how to add passkeys to Amazon Cognito through OIDC federation, while surfacing the identity merge gap that appears when new federated users match existing pool accounts.

Why it matters: It matters because IAM teams must preserve account continuity, role assignment, and offboarding logic when password and passkey identities converge inside one user pool.

Context

Amazon Cognito can centralise user sign-up, sign-in, and access control, but password-centric authentication still leaves teams exposed to forgotten-password friction and credential stuffing. In identity terms, the gap is not just login convenience. It is whether a user pool can keep identity continuity intact when authentication methods change.

Descope’s approach uses OIDC federation to let passkeys sit in front of Cognito without changing the application core. That shifts the control question from front-end login mechanics to identity reconciliation, because a federated passkey user can be treated as a new account unless lifecycle and merge logic are deliberately handled.

Key questions

Q: What breaks when passkeys are added to an existing Cognito user pool without identity merge logic?

A: 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.

Q: Why do passkeys improve security but still require IAM governance?

A: Passkeys improve security by reducing phishing and secret theft, but IAM governance is still required because identity risk moves to enrollment, device trust, and recovery. If those processes are weak, the organisation can still suffer account takeover through the path around the passkey rather than through the passkey itself.

Q: How can security teams tell whether passkey and password identities are being merged correctly?

A: Look for consistent account attributes, preserved role mappings, and a single audit trail after a user switches authentication methods. If the same email produces multiple principals or permissions drift, the merge process is not working as intended.

Q: What is the difference between authentication and identity reconciliation in OIDC federation?

A: Authentication proves the user at sign-in. Identity reconciliation decides whether that proof should attach to an existing principal, create a new one, or link two records without changing the user’s access scope.

Technical breakdown

How OIDC federation inserts passkeys into Cognito

OpenID Connect lets one identity provider assert a user’s identity to another system after authentication. In this pattern, Descope acts as the external IdP, Cognito remains the user pool and application-facing identity layer, and the app redirects to Cognito’s OAuth authorize endpoint for the login sequence. Passkeys remove the password from the primary authentication step, but they do not remove the need for attribute mapping, redirect handling, or claim propagation. The technical benefit is a thinner application integration surface. The technical risk is that identity creation and identity matching now depend on federation metadata and the user pool’s reconciliation rules rather than a single local account record. Practical implication: treat federation mapping as an identity-control decision, not just a login implementation detail.

Practical implication: treat federation mapping as an identity-control decision, not just a login implementation detail.

Why identity merge logic becomes the real control point

When a user signs in through a federated passkey flow, Cognito may see an external identity that does not yet correspond to an existing local account. If the same email already exists in the pool, the system still needs a deterministic merge step to link the identities and preserve roles, permissions, and settings. Without that merge logic, password and passkey users can split into duplicate accounts, breaking authorisation continuity and lifecycle tracking. This is an IAM reconciliation problem, not an authentication-strength problem. The merge function is effectively the policy engine that decides whether two proofs of identity belong to one principal. Practical implication: define identity linking rules before enabling alternate authenticators in a live user pool.

Practical implication: define identity linking rules before enabling alternate authenticators in a live user pool.

Why Lambda permissions govern merge safety

The article’s merge flow relies on an AWS Lambda trigger calling Cognito APIs to find and link matching users. That means the merge process depends on IAM permissions as much as it depends on code. If the Lambda role cannot read or update user identities, reconciliation fails; if it is over-permitted, the merge path becomes unnecessarily broad. This is classic privileged automation inside identity governance: a small function is given delegated authority over account state, so scope and auditability matter. Practical implication: govern the Lambda execution role like any other privileged identity that can alter user membership and linkage.

Practical implication: govern the Lambda execution role like any other privileged identity that can alter user membership and linkage.

NHI Mgmt Group analysis

Identity merge is now the real governance boundary: The article shows that passkeys do not eliminate the account-continuity problem, they move it to reconciliation. When a federated identity lands in a Cognito pool that already contains a password-based account, the control question becomes whether the organisation can prove it is the same principal. The implication is that authentication modernization without merge governance produces duplicate identities, not cleaner identity.

Passkey adoption exposes a lifecycle mismatch, not just an authentication upgrade: The password-to-passkey transition only works cleanly when account linking, attribute matching, and role preservation are already defined. That makes lifecycle management part of the authentication design, not a downstream cleanup task. For practitioners, the lesson is that authentication method changes must be modelled as identity-change events.

Delegated merge logic is privileged identity work: The Lambda trigger is not just application glue, it is an identity authority that can link principals across providers. That means its permissions, logging, and failure handling belong in the same governance conversation as privileged access. The practitioner conclusion is simple: if a function can rewrite account relationships, it is an identity control surface.

Passkeys reduce password risk but increase identity-reconciliation dependence: Removing passwords from the primary flow lowers exposure to credential stuffing and forgotten-password friction, but the control burden shifts toward federation quality and user-pool design. The important issue is not whether passkeys are secure in isolation. It is whether the surrounding IAM model can preserve one authoritative identity across multiple authenticators.

Hidden identity collisions are an implementation smell teams should expect: Any environment that adds passkeys to an existing user pool must assume that duplicate-principal scenarios will appear unless merge rules are explicit. That is especially true where email becomes the linking attribute. The practitioner conclusion is to treat identity collision handling as a required design control, not an edge case.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: NHI Authentication Guide

What this signals

Identity collision handling is now a core IAM design concern: Passkey rollout in an existing user pool does not just introduce a better login factor. It creates a reconciliation problem, because the organisation must decide how one verified person maps to one authoritative account across multiple authenticators. Teams that delay this decision usually discover it only after duplicate identities appear.

Account continuity has to be designed into the federation path: The moment a passkey user can arrive through OIDC and land in a pre-existing Cognito pool, the programme is no longer about authentication alone. It becomes a governance exercise in preserving roles, tenants, and lifecycle state while identity proofs change form.

For practitioners

• Define identity linking rules before rollout Specify which attribute, usually verified email, determines whether a federated passkey user maps to an existing Cognito principal or a new account. Test collisions between password and passkey identities before enabling production traffic.
• Treat merge Lambda as privileged identity code Scope the Lambda role to only the Cognito actions needed for linking and auditing user identities. Review the function as privileged automation that can alter account relationships, not as a routine helper script.
• Preserve role and permission continuity through federation Check that custom claims, role mappings, and tenant attributes survive the OIDC handoff and are not lost when the user is linked back to the Cognito record.
• Test duplicate-account scenarios in a nonproduction pool Simulate an existing password user signing in through the new passkey path and verify that the merge outcome keeps the original account state, access scope, and audit trail intact.

Key takeaways

• Passkeys improve Cognito authentication, but the deeper governance issue is whether federated and local identities resolve to one authoritative account.
• The article’s merge flow shows that account continuity depends on explicit linking logic and delegated IAM permissions, not just on stronger authentication.
• IAM teams should test identity collisions, preserve role mappings, and govern the merge function as privileged identity code before rollout.

Key terms

• Identity Reconciliation: The process of comparing authoritative identity records with live access data to find mismatches, missing owners, or stale entitlements. It is the operational bridge between inventory and governance, and it is essential when hidden access may exist outside the normal provisioning path.
• Federated Identity: Federated identity lets one organisation trust an external identity provider so a user can access another service without creating a separate account. It simplifies access, but it also expands the trust relationship that must be monitored. Weak federation settings can turn a single compromise into cross-domain access.
• Account Continuity: Account continuity is the preservation of one user’s roles, permissions, settings, and audit trail across authentication changes. It matters when a person moves between password, passkey, or social login methods, because the organisation still needs one authoritative principal rather than multiple partial records.
• Privileged Automation: Privileged automation is any scripted or integrated process that can create, modify, or delete production assets with elevated authority. It reduces manual effort, but it also expands blast radius if the script, input data, or credentials are compromised. Governance must therefore cover both code and the credential behind it.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.