Notifications
Clear all
Topic starter
11/07/2026 1:55 pm
TL;DR: Account recovery now carries more real-world identity risk than login in many consumer journeys, with Norway’s BankID handling about 3 million recovery events a year for 4.7 million users and one energy provider seeing 25% of customers use recovery monthly, according to Authsignal. Recovery must be designed as a primary security flow, because weak fallback paths quickly become the main authentication path.
NHIMG editorial — based on content published by Authsignal: Account recovery is the identity industry's most overlooked challenge
By the numbers:
- At one major energy company, 25% of customers were using the account recovery flow every single month just to pay their electricity bills.
Questions worth separating out
Q: How should security teams design account recovery so it is not weaker than login?
A: Security teams should make recovery at least as strong as the primary authenticator, not a lower-friction bypass.
Q: Why does account recovery create fraud and account takeover risk?
A: Recovery is risky because it often relies on weaker evidence than login, such as SMS codes, knowledge-based questions, or call-centre checks.
Q: What signals show that account recovery is failing in practice?
A: A recovery system is failing when users choose it more often than expected, support teams see repeated lockout cases, or fallback methods become the normal way to access accounts.
Practitioner guidance
- Audit recovery as a first-class identity flow Map every recovery path, including SMS, email, knowledge-based questions, help-desk verification, and synced passkey recovery.
- Bind multiple recovery factors during onboarding Require recovery setup while identity assurance is highest.
- Apply step-up controls after recovery events Reduce transaction limits, delay sensitive changes, and notify every registered channel after recovery.
What's in the full article
Authsignal's full article covers the operational detail this post intentionally leaves for the source:
- The panel perspectives behind the iron triangle of security, privacy, and access continuity.
- Practical examples of synced passkeys, backup codes, and device-bound recovery patterns.
- Detailed discussion of post-recovery restrictions, time delays, and notification design.
- The AI and deepfake-related verification risks that influence high-assurance recovery choices.
👉 Read Authsignal's analysis of account recovery as an identity security problem →
Account recovery and identity assurance: where do controls fail?
Explore further
11/07/2026 2:06 pm
Recovery is the weak link because it is usually designed outside the authentication model. The article is right to frame recovery as an identity architecture problem rather than a support issue. When login is hardened with passkeys and phishing-resistant MFA but recovery remains dependent on weaker proofs, attackers simply move to the easier path. Practitioners should treat the recovery flow as part of the primary trust boundary.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- The same research shows that only 5.7% of organisations have full visibility into their service accounts, which is why recovery and revocation must be designed as a single lifecycle.
A question worth separating out:
Q: Who should own account recovery governance in an identity programme?
A: Account recovery should be jointly owned by IAM, fraud, security architecture, and customer operations, with a single accountable decision maker. It crosses assurance, user experience, and business continuity, so leaving it to support alone creates blind spots. Recovery policy should be reviewed like any other access control because it determines who can regain trust and when.
👉 Read our full editorial: Account recovery is the overlooked weak point in identity security
