Notifications
Clear all
Topic starter
19/08/2026 3:24 pm
TL;DR: Account recovery remains a high-risk identity choke point because help desks and self-service resets often verify knowledge or possession, not the real person, according to iProov. As AI-enabled impersonation improves, recovery needs stronger re-verification, not lower-assurance fallback paths.
NHIMG editorial — based on content published by iProov: account recovery and the risks of re-verifying identity
By the numbers:
- The average enterprise has 25x to 50x more non-human identities than human identities.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
Questions worth separating out
Q: What breaks when service desk staff are allowed to use judgment during account recovery?
A: Judgment-based recovery breaks consistency, auditability, and resistance to social pressure.
Q: Why do recovery flows create a bigger risk than login in some programmes?
A: Recovery often accepts weaker proof than the original login, even though it can restore the same or greater access.
Q: How can security teams judge whether authentication recovery is safe enough?
A: By testing the recovery path with the same scrutiny as primary login.
Practitioner guidance
- Replace knowledge-based recovery with verified person checks Remove security questions and similar shared facts from any recovery flow that can reset MFA or rebind a device.
- Segregate help desk authority for privileged accounts Do not allow a single support action to reset MFA, enroll a new authenticator, and restore access for administrative users.
- Audit every recovery event as a security event Log who approved recovery, what evidence was used, which factor was reset, and whether the reset resulted in device rebinding or authenticator enrolment.
What's in the full article
iProov's full article covers the operational detail this post intentionally leaves for the source:
- The exact recovery flow options the article contrasts, including self-service reset and help desk-assisted recovery.
- The practical role of liveness verification in re-binding credentials after device loss.
- The specific questions to ask when evaluating recovery assurance against impersonation and synthetic media.
- The operational distinction between proving possession of a factor and proving the genuine person is present.
👉 Read iProov's analysis of account recovery as an identity attack surface →
Account recovery and identity proofing: are your controls keeping up?
Explore further
19/08/2026 4:09 pm
Account recovery is the new identity attack surface. Organisations have invested heavily in stronger login methods, but recovery often remains governed by weaker questions, codes, and human discretion. That creates a structural asymmetry: attackers do not need to defeat the strongest control if they can step around it at the restoration stage. For IAM teams, the real issue is not just authentication strength but lifecycle assurance across reset, rebind, and re-enrolment.
A question worth separating out:
Q: Who is accountable when identity recovery workflows are abused?
A: Accountability sits with the organisation that owns the recovery design, the support process, and the audit evidence. If reset paths can be social-engineered or misused without strong logging and escalation rules, the control failure is governance-related, not just operational.
👉 Read our full editorial: Account recovery is now the weakest point in identity security
