Your Passkey Is Gone. Now What? Native Passkey Recovery with Verifiable Credentials and Keycloak

Table of contents

What Happens When Your Passkey Is Gone?

Passwordless authentication solves the password problem. It does not automatically solve the account recovery problem.

Passkeys are phishing resistant authentication: the user unlocks them with face, fingerprint, or PIN, backed behind the scenes by the User Verification (UV) configured on the device. It’s a much better experience than passwords. But how do you provide a recovery mechanism with the same level of assurance, without falling back to something weaker than the passkey they just lost?

Most recovery flows quietly reintroduce the exact weaknesses passwordless was supposed to remove: a password reset, an SMS OTP, a support ticket. Every one of those is a phishable, socially engineerable fallback sitting underneath an otherwise strong authenticator. The recovery path is only as strong as its weakest link, and if that link is a six-digit code sent by SMS, the passkey didn’t actually raise the security bar for the account. It just moved the attack surface to the recovery flow.

If passwordless is going to mean anything, recovery has to be passwordless too.

At TwoGenIdentity, we’ve been exploring Verifiable Credentials (VCs) as a way to close that gap: a second, independent, cryptographically verifiable way to establish identity, used specifically at the moment a user needs to recover access. Not as a replacement for the passkey, but as what proves you’re allowed to register a new one.

A Verifiable Credential Is Not an Authentication Protocol

Before getting into the recovery flow, it’s worth being precise about what a Verifiable Credential actually is, because it’s easy to conflate it with authentication.

A Verifiable Credential is a digitally signed set of claims issued by a trusted Issuer about a Subject, which a Holder stores and later presents to a Verifier.

Think of it as a digital Employee Credential. The organization (Issuer) issues it. The employee (Holder) stores it in a wallet. When needed, the employee presents it, and the party checking it (Verifier) can cryptographically confirm it’s genuine, unaltered, and actually theirs, without calling the issuing organization to check.

The important distinction is this:

OIDC ID Token → “This authentication event says this user is Martin.”

VC → “This trusted issuer says Martin has this attribute/credential.”

VP (Verifiable Presentation) → “Martin is presenting this credential to you, with proof that he controls it.”

The Credential Format Landscape

There isn’t one standard VC format. There are three actively used ones, each with different roots and different sweet spots:

Rather than picking a single winner, the issuance and presentation protocols were designed to be format agnostic:

• OpenID4VCI (OpenID for Verifiable Credential Issuance) handles issuance. The wallet uses OAuth based flows to obtain a credential from the issuer. The 1.0 specification supports W3C VC, SD-JWT VC, and ISO mdoc.
• OpenID4VP (OpenID for Verifiable Presentations) handles presentation. A verifier requests credentials from a wallet, and the wallet returns a presentation. It also supports all three formats.

In this model, Issuer to Holder interactions are governed by OpenID4VCI, covering credential issuance, and Holder to Verifier interactions are governed by OpenID4VP, covering credential presentation and verification.

For the employee credential recovery use case, SD-JWT VC is the natural fit: it’s JWT based, so it slots into existing OAuth/OIDC infrastructure with minimal friction, and it supports selective disclosure, meaning the employee can present only the claims the recovery flow actually needs, not the entire credential.

It’s worth a quick side note on where the rest of the ecosystem is headed. Google Wallet and Apple Wallet’s current digital ID implementations are both centered on ISO mdoc (ISO/IEC 18013-5) rather than SD-JWT VC. This lab uses SD-JWT VC, integrated with the existing Keycloak deployment.

Our Native Experience

This recovery experience rests on a specific integration pattern, worth explaining before walking through the demo.

We support a native integration where the app follows the flow configured in Keycloak, rather than the traditional redirect to the Identity Provider. Keycloak, through the TwoGenIdentity Keycloak Advanced Authentication Extensions, owns the definition of the flow: which steps to present, which credential to accept, and when a new passkey may be registered. The app’s job is simply to render whatever step Keycloak’s flow calls for next, natively.

Keycloak remains responsible for deciding what is required:

• Which recovery method is available
• Which credential can be accepted
• Whether the Verifiable Presentation is valid
• Whether the user can register a new passkey

The application is responsible for presenting the journey in a way that feels native, clear, and consistent.

This separates the experience from the decision:

• The app delivers the user experience.
• The wallet holds the credential.
• Keycloak with the TwoGenIdentity Keycloak Advanced Authentication Extensions verifies the credential and enforces the recovery policy.
• The new passkey becomes the user’s authenticator.

For this recovery use case, the application can request a Verifiable Presentation directly from the user’s wallet through the Digital Credentials API using Android Credential Manager, receive the presentation, and continue the recovery journey without leaving the app.

The Practical Case: Native Passkey Recovery with Keycloak

Here’s where the theory turns into something a user actually experiences.

In the following demo, Keycloak has already issued a Verified Employee ID for the employee. The credential is stored in the employee’s digital wallet and can later be presented when identity verification is required.

The recovery experience is simple:

Lost passkey → Present Employee Credential → Verify identity → Register a new passkey

And the entire journey happens directly in the application:

• No password.
• No QR code.
• No browser redirect.

That last point matters more than it sounds. Most VC presentation demos rely on cross device flows: scan a QR code with your phone, approve in a separate wallet app, get redirected back to a browser tab. That’s a workable pattern for some use cases, but it’s a poor fit for account recovery, where you want the fewest possible steps and the fewest possible places for a user to get confused or a phishing page to intercept a redirect.

Instead, this integration uses the native Digital Credentials API to talk directly to the wallet, combined with the TwoGenIdentity Keycloak Advanced Authentication Extensions to give a native experience. The whole exchange happens in band, inside the application the user is already in.

As described above, the VC establishes identity, Keycloak enforces the recovery policy, and the passkey becomes the new authenticator. None of these three replace the other. The VC doesn’t replace the passkey; it earns the right to register a new one. The new passkey is what the user actually authenticates with going forward.

This is what makes it a native recovery experience rather than a fallback: it doesn’t drop the user into a weaker authentication mechanism to get them out of a jam. It uses a credential exactly as strong and phishing resistant as the authenticator it’s replacing.

Demo: Native Passkey Recovery

The recovery journey happens directly in the mobile application.

The employee:

1. Selects “Other ways to sign in.”
2. Chooses “Recover with Verified Employee ID.”
3. Presents their Verified Employee ID from their digital wallet.
4. Their identity is verified.
5. They create a new passkey.
6. Their account is recovered and the new passkey is ready to use.

The entire experience happens directly in the application, start to finish.

Demo: Web Native Passkey Recovery

The same journey is also available on the web, using the browser’s native Digital Credentials capabilities.

For the hands on implementation, including the Keycloak authenticator configuration, the issuer setup, and the Digital Credentials API wiring, see the full lab writeup at twogenidentity.com/labs/keycloak-verifiable-credentials.

Beyond Recovery

Account recovery is just one use case. The same foundation, a trusted issuer, a holder controlled wallet, and a verifier that can check a presentation cryptographically without a phone call to the issuer, extends to passwordless authentication, step up authentication, employee onboarding, access to sensitive applications and resources, identity proofing, and other scenarios where an organization needs to verify trusted attributes about a user.

Going passwordless was never just about removing passwords from login. It’s about making the entire authentication lifecycle stronger, including the moment things go wrong and a user needs to get back in.

Looking Ahead

This builds on the ongoing efforts of the Keycloak team, the FIDO Alliance’s work on passkeys and Verifiable Credentials, and the OpenID Foundation’s work on Verifiable Credentials and digital identity standards.

The European Digital Identity (EUDI) Wallet is another strong example of how digital wallets and verifiable credentials are becoming part of the future of digital identity in Europe.

Verifiable Credentials are still evolving, and there are areas where the ecosystem and standards need further definition and alignment.

The Digital Credentials API is also relatively new, and wallet, browser, and platform support will continue to evolve.

But the direction is promising.

The ability to combine trusted digital credentials, native wallet experiences, and passkeys opens new possibilities for identity, authentication, onboarding, and recovery.

For us, this is an exciting area to continue exploring and bringing into our identity platform as the ecosystem matures.