Passkeys in Amazon Cognito expose the hidden IAM merge gap

At a glance

What this is: This is a guide to adding passkeys to Amazon Cognito through OIDC federation, with a key emphasis on account merging and identity continuity.

Why it matters: It matters because IAM teams need to understand how passwordless login changes federation, user lifecycle handling, and duplicate-account risk across human identity programmes.

👉 Read Descope's guide to adding passkeys in Amazon Cognito

Context

Amazon Cognito passkeys are a federation and account-linking problem as much as an authentication problem. The article shows how an OIDC provider can front passwordless sign-in while Cognito continues to own the user pool and application session model.

For identity teams, the hard part is not enabling a login button. It is deciding how verified identities, custom claims, and existing user records stay aligned when authentication methods change, especially where lifecycle, roles, and duplicate-account handling are already fragile.

Key questions

Q: How should organisations roll out passkeys in a federated user pool without creating duplicate accounts?

A: Use a verified identity attribute, usually email, as the linking key, and test the merge path before production. The safe pattern is to let the external authenticator prove the user, then let a controlled linkage step attach that proof to the existing Cognito profile without changing downstream entitlements.

Q: Why do passwordless sign-ins still require IAM and lifecycle controls?

A: Because removing the password does not remove identity state. The organisation still has to govern account linking, claim mapping, role continuity, and recovery paths. Those controls determine whether the authenticated user is placed into the right application identity with the right permissions.

Q: What can go wrong if passkey identities are not linked to existing user records?

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

Q: Who should own the controls for federated passkey account merging?

A: IAM or identity engineering should own the policy, while application teams implement the integration details. The reason is simple: the merge logic affects identity assurance, entitlement continuity, and recovery, so it belongs in governed identity design rather than ad hoc application code.

Technical breakdown

OIDC federation for passkeys in Amazon Cognito

The pattern uses OpenID Connect to let a federated provider authenticate the user with passkeys, then hands the result to Amazon Cognito for user-pool management. In practice, Cognito remains the primary application identity store while the external provider handles authentication assurance. That separation is useful because it avoids rewriting the application login stack, but it also means attribute mapping, scopes, and claim content become part of the trust boundary. If the mapped claims are wrong, the application can receive an identity that is authenticated but not correctly represented in downstream authorization.

Practical implication: Treat claim mapping and scope design as part of the control plane, not as UI setup.

Identity merging when password and passkey accounts collide

When a user who previously signed in with passwords returns through a federated passkey flow, Cognito may see a new subject unless the identities are linked. The article uses an AWS Lambda trigger to search for existing records by email and then link the provider subject to the Cognito profile. This is an identity resolution step, not just a convenience feature. Without it, the same person can end up with multiple identities, each carrying different entitlements, history, and recovery paths.

Practical implication: Design identity-linking logic before rollout so authentication method changes do not fragment the user record.

Lambda triggers and IAM permissions in account linking

The merge flow depends on a Lambda function with permission to read and link Cognito users. That makes the permission model part of authentication integrity, because the trigger must be allowed to locate the right account and complete the link without overexposing the directory. The article also notes that email verification is used to prevent spoofed linking. This is a standard federated identity pattern: an external authenticator proves the user, then IAM controls determine whether that proof can be safely merged into an existing identity.

Practical implication: Scope Lambda permissions tightly and verify that account-linking logic only executes against trusted, verified attributes.

NHI Mgmt Group analysis

Passwordless login does not remove identity governance complexity, it relocates it. The article shows that passkeys eliminate one common attack path, but they replace password risk with federation, account-linking, and claim-mapping risk. That means the governance burden shifts from credential choice to identity resolution and trust translation. Practitioners should read this as a control relocation, not a simplification.

Verified-email account linking is a human identity control, not a generic developer shortcut. The merge logic only works because the flow assumes a stable, verified email as the anchor between old and new credentials. That is acceptable in a human IAM context, but it becomes brittle if organisations later reuse the same pattern for broader lifecycle automation without reviewing assurance level, recovery path, and entitlement continuity. Practitioners should treat linking rules as governed identity policy.

Claim mapping is the hidden authorisation dependency in OIDC passkey rollouts. The article explicitly passes custom claims such as roles and tenants into Cognito, which means the authentication flow is also shaping downstream authorisation. This is where many deployments drift: teams think they are modernising sign-in, when in fact they are redefining the trust boundary for application access. Practitioners should treat claims as security data, not just integration metadata.

Passkeys reduce account takeover exposure, but they do not eliminate lifecycle failure modes. The guide still needs Lambda-based user merging, IAM permissions, and fallback handling for existing accounts. That tells us the real operational problem is identity continuity across authentication methods, not the password itself. Practitioners should use passkeys as a control improvement, while keeping lifecycle governance for linked identities explicit and testable.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why teams should also review Ultimate Guide to NHIs for lifecycle and access-governance patterns that keep identity state auditable.

What this signals

Passwordless authentication projects often start as user-experience improvements, but they quickly become identity-resolution programmes. If your team cannot prove which verified identity maps to which existing account, the login method has changed faster than the governance model.

Claim-linking debt: when authentication methods change faster than account governance, identity records diverge and entitlement continuity becomes harder to prove. That is why federated passkey deployments should be reviewed alongside lifecycle controls, recovery design, and auditability, not just sign-in UX.

For practitioners, the signal is clear: if you are adding OIDC-based passkeys, you should validate your claim-mapping design against the principles in Ultimate Guide to NHIs and the broader access control model in NIST AI Risk Management Framework only where AI governance is relevant to your environment.

For practitioners

• Map identity-linking rules before enabling passkeys Define which attribute, usually verified email, is allowed to connect an existing Cognito record to a federated passkey identity. Document how conflicts are resolved when more than one account matches the same person.
• Scope Lambda permissions to account-linking only Give the merge trigger only the Cognito actions it needs to look up and link identities. Review the role so the function can complete the flow without broad directory access.
• Treat custom claims as authorisation inputs Review every mapped claim, especially roles and tenant attributes, as part of the application trust model. Test that the values returned by the federated provider match the downstream access model exactly.
• Validate duplicate-account handling in a test pool Run sign-in tests for users who already exist in Cognito and for users who are new to the pool. Confirm that the merge flow preserves roles, permissions, and recovery paths exactly as intended.

Key takeaways

• Passkeys reduce password attack exposure, but they shift the hard problem to identity linkage and claim governance.
• The AWS Lambda merge step shows that authentication modernisation still depends on tightly controlled IAM and lifecycle decisions.
• If account continuity is not designed up front, federated login can create duplicate identities, inconsistent permissions, and audit gaps.

Key terms

• Federated identity provider: An external identity system that authenticates a user and passes that result into another service for session creation or access decisions. In a passwordless flow, it becomes part of the trust boundary because its claims, scopes, and attributes influence what the application believes about the user.
• Identity linking: The process of connecting two authentication records that belong to the same person so access history, roles, and recovery paths stay consistent. In federated login, linking is a governance step, not just a developer convenience, because it determines whether one user or many accounts exist for the same identity.
• Claim mapping: The translation of identity attributes from one system into the format another system uses for access and authorisation. The mapping must be explicit and tested because it can carry roles, tenants, and other security-relevant data into downstream policy decisions.
• Passkey: A phishing-resistant authentication method that uses cryptographic keys stored on the user device or authenticator instead of a password. It improves login assurance, but organisations still need to govern account recovery, linking, and lifecycle handling around the identity it unlocks.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Cognito and OIDC configuration values for the federation setup.
• The Lambda code used to merge user identities based on email.
• The exact Cognito attribute mappings and custom-claim settings used in the flow.
• The hosted UI and custom UI redirect sequence needed to complete the passkey login flow.

👉 The full Descope post covers the OIDC setup, Lambda merge logic, and Cognito attribute mapping steps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.