Identity verification is replacing weak password reset trust

At a glance

What this is: This article argues that identity proofing, not just authentication factors, should govern self-service password resets because legacy recovery flows are easy to impersonate.

Why it matters: For IAM, PAM, and identity governance teams, this matters because account recovery is often the weakest recovery path in an otherwise well-controlled environment, and attackers increasingly target that gap.

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.

👉 Read Trusona's analysis of identity verification for self-service password resets

Context

Identity verification is the process of confirming that a person really is who they claim to be before a sensitive action is approved. In password reset flows, that distinction matters because the recovery step is often less protected than the login step, even though it can lead directly to account takeover.

The article’s core problem is a governance gap in recovery assurance, not an authentication gap at sign-in. Legacy self-service password reset models rely on enrolled factors, knowledge-based checks, or help-desk discretion, all of which can be manipulated when attackers use stolen data, deepfakes, or social engineering.

For identity programmes, the lesson is that account recovery must be treated as a high-risk identity event in its own right. That applies to human users, customer support flows, and adjacent onboarding or recovery journeys where a false identity claim can create immediate access.

Key questions

Q: How should security teams secure self-service password reset and account recovery?

A: Use identity proofing before access is restored, not after. Replace security questions and SMS or email OTPs with stronger verification such as document validation, liveness detection, and risk-based escalation for ambiguous attempts. The goal is to confirm a real, present user before the identity lifecycle is reopened.

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. Once an attacker controls the recovery step, they can reset passwords, re-enroll MFA, and take over the account. The problem is not convenience itself, but weak assurance at the moment of access restoration.

Q: What do organisations get wrong about MFA recovery?

A: Many teams assume recovery is a support workflow, not a security boundary. In practice, recovery can become the easiest way to bypass strong authentication if proofing is weak or exceptions are common. The right model treats reset, re-enrollment, and device replacement as controlled identity events, not convenience functions.

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.

Technical breakdown

Why pre-registered factors fail in password recovery

Legacy self-service password reset systems usually assume that if a user can present an enrolled factor, the recovery request is legitimate. That assumption breaks down when attackers can obtain or spoof phone numbers, email access, authenticator prompts, or support-channel context. The control problem is not encryption weakness, but trust in a factor that was registered long before the recovery event and may no longer reflect the true account holder. Identity proofing at the moment of reset changes the verification model from static enrollment to real-time assurance.

Practical implication: move recovery decisions away from factor possession alone and toward assurance steps that validate the person at the time of reset.

How deepfakes and impersonation reshape recovery risk

Deepfakes, voice cloning, and synthetic identity techniques make social engineering more scalable because the attacker no longer needs perfect knowledge, only plausible evidence. Help-desk staff are especially exposed because they often rely on urgency, confidence, and partial account data when deciding whether to override a reset. In this environment, the attacker’s objective is to convert a support interaction into a credential change or MFA reset, which then creates full account control. That is why impersonation detection is becoming a core identity security function rather than a fraud-only concern.

Practical implication: harden support and recovery channels with document, device, and provenance checks before any reset action is allowed.

What identity proofing adds to IAM architecture

Identity proofing adds a higher-assurance step that checks document authenticity, authoritative data, and device signals before recovery proceeds. In IAM terms, it introduces a verification layer that sits upstream of credential issuance or reset, so the system can confirm identity without requiring a pre-enrolled mobile app or manual agent judgment. The architecture matters because it reduces dependency on brittle fallback methods while preserving a self-service experience. It also produces a traceable event record that can support audit and forensics after the fact.

Practical implication: design recovery workflows so identity proofing becomes the gate to password or MFA change, not an optional add-on after the fact.

Threat narrative

Attacker objective: The attacker aims to turn a recovery interaction into durable account control and then use that control to move into adjacent systems and data.

1. Entry occurs when an attacker targets account recovery rather than the primary login path, using stolen personal data, social engineering, or synthetic media to look credible.
2. Credential access follows when the attacker convinces the recovery process or help desk to reset a password, remove MFA, or register a new factor under attacker control.
3. Impact is full account takeover, followed by access to email, SaaS applications, and downstream identity resets that widen the blast radius.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Factor possession is not proof of identity. A pre-registered authenticator app, SMS code, or email link only proves access to a channel that may already be compromised or socially engineered. The article exposes a broader governance flaw: recovery systems often confuse enrollment history with current identity assurance. Practitioners should read this as a failure of identity evidence quality, not a simple MFA weakness.

Identity proofing is becoming the new control plane for high-risk recovery. The most useful named concept here is recovery assurance gap: the distance between an account holder’s real identity and the evidence accepted by the reset workflow. The wider that gap, the easier it is for an attacker to weaponise support and self-service processes. Identity programmes that cannot close that gap will keep losing the recovery channel to impersonation.

Help-desk discretion is an access control, and it needs governance. When support staff can override reset safeguards based on confidence or partial verification, they become part of the attack path. That makes support policy, agent training, and escalation design part of identity architecture, not just service operations. Organisations that ignore this will keep pushing risk into the one place attackers know how to exploit: the human approval layer.

Recovery controls must be evaluated alongside account lifecycle controls. Even strong sign-in controls do little if an attacker can re-establish access through reset, re-enrollment, or device replacement. That is why IAM, IGA, and fraud teams need a shared view of recovery events, especially where customer identity, employee identity, and support workflows intersect. The practitioner conclusion is simple: the reset flow is part of the identity estate and must be governed accordingly.

From our research:

• 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.
• That gap is why 52 NHI Breaches Analysis remains essential reading for teams mapping privilege exposure to real-world compromise patterns.

What this signals

Recovery is becoming part of the identity security perimeter, which means teams need to design for impersonation at the exact moment access is being restored. The control question is no longer whether a user can answer a challenge, but whether the organisation can prove the recovery request came from the real account holder before the reset completes.

Recovery assurance gap: as long as organisations treat password resets as a convenience flow, attackers will keep using support and self-service channels as a shortcut to account takeover. That gap is especially dangerous where support staff, fraud workflows, and IAM controls do not share the same risk signals.

For practitioners, the near-term priority is to align identity proofing, support policy, and audit logging so recovery events become visible in governance workflows. Teams that already monitor privileged access should extend that same discipline to reset and re-enrollment paths, because those paths now carry comparable blast-radius risk.

For practitioners

• 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.
• Audit recovery paths for impersonation exposure Test password reset, MFA re-enrollment, and help-desk escalation against deepfake, voice-cloning, and stolen-data scenarios, then close the highest-risk paths first.
• Log and review recovery events as security signals Feed reset requests, failed proofing attempts, and support overrides into monitoring so recovery abuse becomes visible in IAM, fraud, and SOC workflows.

Key takeaways

• Password reset flows are now a primary impersonation target, not a minor support task.
• The core failure is weak assurance at the moment of recovery, not lack of authentication technology.
• Identity proofing, support governance, and event logging should be treated as one recovery control system.

Key terms

• Identity proofing: The process of verifying that a person is who they claim to be before granting or restoring access. In higher-risk recovery paths, proofing can include stronger evidence checks such as government ID validation or liveness-based facial verification so the assurance level matches the sensitivity of the request.
• Recovery Assurance: The level of confidence that an organisation has in identity proofing during password reset, device replacement, or account recovery. Strong recovery assurance is essential because the overall security of an authentication system is limited by the least trustworthy path back into the account.
• Self-service password reset: A recovery workflow that lets users regain access without relying on a help desk agent to perform the reset. In identity governance terms, it replaces discretionary manual verification with a standardized, auditable process that can be tuned to the risk of the account or application being recovered.
• Workforce Identity Impersonation Detection: Workforce identity impersonation detection is a control area focused on spotting attempts to pose as employees, contractors, or other workforce users. It typically combines behavioral checks, device and context signals, and verification steps during sensitive workflows such as help desk recovery, access resets, and privileged requests.

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.

👉 The full Trusona post covers recovery flow design, impersonation detection, and the UConn deployment example.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.