Account recovery is the identity industry's most overlooked challenge

Last year at Identiverse, I joined an expert panel on account recovery alongside Dean Saxe (IDpro), Ove-Morten Stalheim (BankID Norway), Rob Brown (Inverid), and Bertrand Carlier (Wavestone). The discussion kept coming back to the same point: most companies have account recovery in the wrong bucket. They treat it as a customer service problem when it's really a security and business architecture challenge.

‍

The problem we’re not talking about

Here’s a statistic that should make every identity professional pause: in Norway's BankID scheme, which serves 4.7 million users, approximately 3 million account recovery events happen every year. That's 2 million users swapping phones with device-bound credentials, plus 1 million password resets. To put it bluntly, more than half the user base goes through account recovery annually.

At one major energy company, 25% of customers were using the account recovery flow every single month just to pay their electricity bills. They weren't forgetting their passwords; they were actively choosing recovery because it was easier than remembering credentials. When your recovery mechanism becomes the primary authentication path, you haven't just failed at UX. You've created a security nightmare.

‍

Why authentication alone isn’t enough

At Authsignal, we spend considerable time talking to consumer-facing platforms from airlines to financial services and see a consistent pattern - companies invest heavily in authentication. Passkeys, biometrics, phishing-resistant MFA. They're solving yesterday's problem brilliantly. But as Bertrand pointed out during our panel, attackers are already shifting their focus.

Authentication is largely solved. Account recovery is now the weak link in the user lifecycle.

We've built incredible systems to verify users during login. But what happens when someone loses their phone? When they get a new device? When they can't access their email? That's when the carefully constructed security model often collapses into security questions about your first pet's name (information readily available on Facebook) or SMS codes (vulnerable to SIM swapping).

‍

You can't optimize for everything: The iron triangle

Dean Saxe's framework for thinking about account recovery revolves around what he calls the "iron triangle": security, privacy, and access continuity. You can optimize for any two, but rarely all three.

‍

A bank might prioritize security and access continuity, requiring in-person identity verification with government documents to recover an account. Strong security, good access (if you can get to a branch), but minimal privacy.

Reddit takes a different approach: email verification, multiple MFA devices, and backup codes. But if you lose everything? You're locked out permanently. They've optimized for security and privacy at the expense of access continuity.

The reality is there's no universal "right" answer. The appropriate balance depends entirely on your threat model, user base, and business requirements.

‍

The misaligned incentives problem

Rob pointed out something important about organizational structure. The people responsible for onboarding want low friction to maximize new customer acquisition. They're measured on conversion rates. Meanwhile, account recovery typically falls to the contact center, which is measured on handle time and cost per interaction. These are fundamentally misaligned incentives.Companies optimize the wrong things. They make onboarding easy by collecting minimal authentication factors, then pay for it later in contact center costs when users need recovery. Or worse, they suffer account takeover attacks because the recovery mechanism is weaker than the primary authentication. It's an org chart problem as much as a tech problem.

‍

What actually works

Here's what we've learned at Authsignal and from the panel discussion:

Think about recovery at onboarding

The best time to set up account recovery isn't when the user needs it. It's when they're creating the account. This is when identity assurance is highest. This is when you can bind passkeys, capture server-side biometrics, or establish multiple authentication factors.

Yet most organizations treat recovery as an afterthought. They wait until the user is locked out, then scramble to verify identity with whatever information they can gather. This is backwards.

Multiple factors, multiple options

Users need options. A single MFA mechanism ensures that losing one device triggers a full account recovery event. That's poor user experience and unnecessary risk.

Passkeys, particularly synced passkeys, offer an interesting middle ground. When synchronized through a platform provider like Apple, Google, or third-party password managers, they enable credential recovery without traditional account recovery. The user recovers access through their ecosystem provider. Of course, this shifts the recovery risk to that provider, but for many use cases, that's an acceptable trade-off.

Recovery should be stronger than authentication

This seems obvious, but it's violated constantly. If your recovery mechanism is weaker than your authentication mechanism, users will use recovery as a shortcut. And so will attackers.

The panel discussed several high-assurance mechanisms: NFC passport chip scanning combined with biometric liveness detection, cryptographically bound documents (digital credentials), and multi-party quorum systems (systems that require multiple people to approve recovery). These aren't appropriate for every use case, but for high-value accounts, they're the best options available.

Watch: See how passkeys and biometric liveness detection work together in practice.

Consider reduced scope after recovery

Not every recovery event should grant full account access. If a user recovers their account through a fallback mechanism, consider limiting what they can do immediately afterward. Perhaps they get read-only access initially, or they can't perform high-risk transactions for 24-48 hours.Time delays can be security features. They provide a window for the legitimate account owner to detect and stop fraudulent recovery attempts. They also reduce the value of account takeover for attackers.

‍

The deepfake problem

AI came up a lot during the panel. On the attack side, biometric spoofing is getting scary good. Deepfakes can defeat many liveness detection systems. Document forgery is becoming increasingly sophisticated. The old axiom that "physical presence provides higher assurance than digital verification" is eroding rapidly.

Rob said something that stuck with me: AI can't defend against AI. Defensive models are always playing catch-up because attackers can probe them to learn what gets through. Your defensive model hasn't learned anything when an attack succeeds, but the attacker's model has learned what works.

This suggests we need to lean more heavily on cryptographic proof and less on biometric verification alone. Passports with NFC chips, for example, contain cryptographically signed data that's much harder to forge than the document itself.

‍

What to actually do

Here's what to actually do:

1. Audit your current recovery flows. Is recovery actually weaker than authentication? Are users choosing recovery because it's easier? Be honest about the answers.
2. Establish recovery mechanisms during onboarding. Bind passkeys, collect multiple contact methods, set up backup codes. Don't wait until users need recovery.
3. Provide multiple recovery paths. Different users will lose access in different ways. A single recovery mechanism will fail for some portion of your user base.
4. Consider risk-based authorization post-recovery. Not every recovery event should grant full access immediately. Time delays and reduced scope can provide crucial security benefits.
5. Notify users of all account changes. Changes to email, phone numbers, authentication factors, or recovery events should be broadcast to all available channels. Give legitimate users a chance to catch fraud early.
6. Calculate the true cost. Don't just look at contact center expenses. Include the opportunity cost of security incidents, the user experience impact of friction, and the revenue impact of abandoned accounts.
7. Use cryptographic verification where possible. Biometrics can be spoofed. Documents can be forged. Cryptographic proof backed by hardware (like passport chips or FIDO keys) provides higher assurance.

‍

The future of account recovery

I think the future involves a combination of approaches:

• Synced passkeys for most consumer use cases, delegating recovery to trusted ecosystem providers
• Cryptographic document verification (like passport chips) for high-assurance scenarios
• Time-delayed, reduced-scope access for fallback recovery mechanisms
• Better organizational alignment between teams responsible for onboarding, authentication, and recovery

The winners will be the companies that treat account recovery as a first-class concern from day one, not as an afterthought when users get locked out.

‍

Join the conversation

Dean Saxe and the panel have created a GitHub repository with resources and best practices for account recovery: github.com/deansaxe/account_recovery. I encourage everyone working in identity to review these materials and contribute their own experiences.

At Authsignal, we're committed to making account recovery a core part of the authentication conversation. It's not a separate problem. It's not a support issue to be handled by the contact center. It deserves the same attention and engineering effort as your login flow.

The panel at Identiverse was titled "The Recovery Session" as a playful nod to conference hangovers. But the real recovery we need is from years of treating it like an edge case.

‍

Acknowledgements

Thanks to my fellow panelists at Identiverse: Dean Saxe (IDpro), Ove-Morten Stalheim (BankID Norway), Rob Brown (Inverid), and Bertrand Carlier (Wavestone). Your insights shaped this article.