Passkeys and digital credentials are converging in customer identity

At a glance

What this is: This is an analysis of how passkeys and digital identity credentials fit together in customer identity, with the key finding that authentication and attribute proof are diverging into different journey moments.

Why it matters: It matters because IAM teams now have to design for mixed assurance flows across human identity, recovery, and regulated onboarding without turning every interaction into an unnecessary verification step.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Authsignal's analysis of passkeys and digital identity credentials

Context

Passkeys have changed the baseline for consumer authentication, but they do not replace every identity check. The broader shift is that businesses now have to separate proof of access from proof of attributes, and design journeys that use each only when it is actually needed.

Digital identity credentials, such as government-issued digital IDs and wallet-based credentials, create a second assurance layer for human identity. That makes customer onboarding, recovery, and regulated actions more flexible, but also more complex to govern across web, app, and contact-centre channels.

Key questions

Q: How should organisations decide when to use passkeys versus digital identity credentials?

A: Use passkeys when the goal is secure account access, and use digital credentials when the business needs a verified attribute such as age, entitlement, or regulated identity evidence. The key is to match the control to the assurance question. Do not force one method to do both jobs, or you will create friction and weaken the journey.

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: What breaks when recovery and fallback are not designed for credential-based journeys?

A: Users fall back into weaker methods, support teams improvise exceptions, and attackers target the recovery path instead of the primary authenticator. If the business cannot handle lost devices, unavailable credentials, or contact-centre recovery cleanly, the control only works on the happy path.

Q: Who should own policy for digital credential acceptance in a customer identity programme?

A: Identity, security, privacy, and product teams should share ownership, but identity governance must define the acceptance rules. The business needs clear policy for trusted issuers, minimum attributes, recovery, and exception handling, because these choices shape both risk and user experience.

Technical breakdown

Passkeys prove access, not identity attributes

A passkey is a phishing-resistant authenticator that replaces the shared secret pattern behind passwords. It confirms that the user can access the account, but it does not by itself prove age, residency, entitlement, or other asserted attributes. That distinction matters because many customer journeys have historically overloaded one login event with multiple assurance goals. As passkeys become common, product teams have to separate authentication from evidence collection and treat them as different control points in the identity stack.

Practical implication: Separate sign-in assurance from attribute verification in your journey design so you do not force every login to carry the weight of onboarding or compliance checks.

Digital credentials shift assurance to the transaction stage

Digital credentials are strongest when the business needs a verified fact about the person, not just a secure session. They can support age checks, regulated account opening, and entitlement proof without requiring a full identity record every time. The architectural challenge is orchestration: the system must request the right credential at the right point, validate it against the trusted issuer, and avoid creating brittle fallback paths when the credential is absent or unavailable. That makes policy design as important as the credential technology itself.

Practical implication: Map specific attributes to specific transaction types and define fallback paths before you wire the credential into production journeys.

Recovery and fallback become the real governance problem

As adoption grows, identity teams discover that the hard part is not the happy path. Device replacement, lost credentials, customer support flows, and recovery from account lockout all create assurance gaps that attackers exploit. If a business cannot answer what happens when a user has a valid credential but cannot present it, or when the preferred authenticator is unavailable, the journey will collapse back to weaker methods. That is where policy, observability, and customer support controls determine whether the design holds up under real-world pressure.

Practical implication: Review recovery, support, and fallback controls as first-class identity risks rather than treating them as edge cases.

NHI Mgmt Group analysis

Passkeys and digital credentials should be treated as different identity primitives, not competing replacements. Passkeys secure account access, while digital credentials prove attributes that may be needed only at onboarding or in higher-risk transactions. Conflating them creates over-verification, bad journeys, and weak control design. Practitioners should build policy that chooses the right proof for the right moment, not a single method for every interaction.

Attribute proof introduces a new governance layer for consumer IAM. Once a business asks for verified identity data, it has to govern issuer trust, attribute minimisation, presentation rules, and recovery paths. That pushes IAM closer to privacy, fraud, and orchestration decisions, especially in regulated journeys. The practical conclusion is that credential acceptance policy now belongs in identity governance, not only in product implementation.

Journey design becomes the control plane when assurance is distributed across methods. The article shows that customers will tolerate stronger verification only when the friction is proportional to the risk. That means authentication, recovery, and support flows have to be sequenced with intent, or customers will fall back to weaker channels. Identity leaders should treat journey design as an assurance control, not a UX afterthought.

Named concept: verification portability. As digital credentials spread, assurance can move between devices, wallets, apps, and channels without staying bound to a single login method. That portability is useful, but it also creates governance complexity because the business must preserve trust while the presentation context changes. Practitioners should think in terms of portable evidence with explicit policy boundaries, not one-time authentication success.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, a reminder that identity assurance failures often surface as operational damage rather than isolated incidents.
• Use Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs to compare how lifecycle governance changes when credentials, not just users, become the control point.

What this signals

Verification portability will push more identity decisions into journey orchestration, where teams must decide when a passkey is enough and when verified attributes are necessary. That design pressure will be strongest in banking, government, healthcare, and other regulated customer flows, where friction and assurance have to stay in balance.

As digital credentials spread, the governance question shifts from support for a credential format to control over who can request what, where, and under which policy. Teams that already struggle to account for identity sprawl should expect similar pressure in customer IAM, because assurance will be distributed across wallets, apps, support channels, and issuers.

The broader programme implication is that customer identity will increasingly resemble NHI governance in one respect: policy, lifecycle, and fallback handling matter more than the authenticator name. When control points multiply, visibility and exception management become the difference between usable trust and operational drift.

For practitioners

• Separate access proof from attribute proof Define which journeys need a passkey, which need a digital credential, and which need both. Keep onboarding, recovery, and regulated transactions distinct so you do not overload one control with multiple assurance goals.
• Design fallback paths before launch Document what happens when a customer lacks a credential, loses a device, or cannot present an otherwise valid credential. Make sure support teams have controlled alternatives that do not reopen password or OTP weaknesses.
• Map issuer trust and attribute minimisation rules Limit the attributes you request to the minimum needed for the transaction, and record which issuers are trusted for each claim. This reduces unnecessary data handling and keeps assurance policy explicit.
• Instrument recovery as a security control Measure how often users fall back from passkeys or digital credentials into weaker routes, and treat spikes as a control failure. Recovery is where identity journeys usually lose assurance.

Key takeaways

• Passkeys and digital credentials solve different assurance problems, so treating them as interchangeable will create weak journeys and excess friction.
• The hard part is governance around recovery, fallback, issuer trust, and attribute minimisation, not basic support for the credential itself.
• Identity teams should design for mixed assurance flows now, before customer expectations and regulation force a rushed implementation.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Digital Credential: A digital credential is a signed set of claims that can be presented by a wallet to prove an identity attribute or entitlement. In wallet ecosystems, the credential is used for authentication or evidence, while downstream systems still need policy and authorization logic to decide access.
• Attribute Verification: Attribute verification is the act of confirming a specific fact about a person rather than establishing full account access. It matters when a business needs evidence for onboarding, regulatory checks, or higher-risk actions without repeatedly collecting more identity data than necessary.
• Recovery Path: The set of backup methods, reset flows, and help-desk procedures that restore access when a user loses their primary credential. Recovery paths often become the weakest part of identity governance because they can reintroduce shared secrets, manual override, or inconsistent verification standards.

What's in the full article

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

• Journey-level examples for when a passkey alone is sufficient and when a digital credential should be requested.
• Operational guidance on handling recovery when a customer has a credential but cannot present it.
• Implementation detail on how wallet-based credentials fit into existing authentication orchestration.
• Practical discussion of customer journey design across app, web, and contact-centre channels.

👉 Authsignal's full post covers journey design, recovery, and credential placement across customer flows.

Deepen your knowledge

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