Notifications
Clear all
Topic starter
06/07/2026 9:46 am
TL;DR: OIDC federation can add passkeys to Amazon Cognito without core app changes, while also exposing a hidden identity-merge problem when password users and passkey users collide in the same user pool, according to Descope. The real governance issue is not login convenience, but preserving account continuity, role mapping, and lifecycle control across federated identities.
NHIMG editorial — based on content published by Descope: How to Add Passkeys to Amazon Cognito Using Descope
Questions worth separating out
A: Use a verified identity attribute, usually email, as the linking key, and test the merge path before production.
Q: Why do passwordless sign-ins still require IAM and lifecycle controls?
A: Because removing the password does not remove identity state.
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.
Practitioner guidance
- 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.
- Scope Lambda permissions to account-linking only Give the merge trigger only the Cognito actions it needs to look up and link identities.
- Treat custom claims as authorisation inputs Review every mapped claim, especially roles and tenant attributes, as part of the application trust model.
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.
👉 Read Descope's guide to adding passkeys in Amazon Cognito →
Amazon Cognito passkeys and the identity merge gap teams miss?
Explore further
06/07/2026 10:02 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Passkeys in Amazon Cognito expose the hidden IAM merge gap
