Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Password reset workflows remain a common account takeover path because legacy self-service systems rely on pre-registered factors and help-desk trust, while deepfakes and voice cloning make impersonation easier, according to Trusona. The real control shift is from authenticating a device to verifying the person at recovery time, because registered factors no longer prove identity.
NHIMG editorial — based on content published by Trusona: Identity Verification, Not Just Authentication: Rethinking Self-Service Password Resets
By the numbers:
- In 70% of SaaS breaches analyzed by Obsidian Security, attackers were able to subvert MFA.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams secure self-service password reset and account recovery?
A: Use identity proofing before access is restored, not after.
Q: Why do legacy password reset flows create account takeover risk?
A: Legacy reset flows often trust pre-registered factors, support interactions, or knowledge-based checks that attackers can steal, spoof, or socially engineer.
Q: What do organisations get wrong about MFA recovery?
A: Many teams assume recovery is a support workflow, not a security boundary.
Practitioner guidance
- Reclassify password reset as a high-risk identity event Map recovery flows to the same assurance tier used for privileged access changes, and require stronger evidence before any password or MFA reset can complete.
- Remove human discretion from routine recovery approvals Define clear support rules that prevent agents from overriding reset safeguards based on urgency, familiarity, or partial identity data.
- Add identity proofing to self-service recovery Use document authenticity checks, authoritative data matching, and device signals at the moment of reset so a user must prove current identity before access is restored.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- A closer walkthrough of the ATO Protect identity proofing flow, including ID scanning, authoritative data checks, and device intelligence.
- The UConn recovery example and the operational impact of moving users out of help-desk queues.
- The no-code and low-code deployment model for integrating identity verification into existing IAM flows.
- The difference between recovery-time identity proofing and traditional MFA enrollment models.
👉 Read Trusona's analysis of identity verification for self-service password resets →
Self-service password resets: are your recovery controls keeping up?
Explore further
25/08/2026 6:11 pm
Identity recovery is now a primary trust boundary, not an administrative convenience. Password reset flows were designed around usability and fallback, which made sense when social engineering was lower scale and voice imitation was weak. That assumption no longer holds. In modern IAM programmes, the reset step can be as sensitive as initial authentication, so governance has to treat it as a privileged identity event with its own assurance requirements.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a call center allows an impostor to reset access?
A: Accountability sits with the organisation that designed the recovery control and the operating team that allowed manual exceptions to bypass assurance. Regulators and auditors will look at whether the workflow used appropriate multi-factor evidence, logged decisions, and limited agent exposure to sensitive data.
👉 Read our full editorial: Identity verification is replacing weak password reset trust
