TL;DR: Compromised self-service password reset can let attackers set a new password and walk in as the legitimate user, turning identity verification into a direct takeover path, according to Securden. The issue now spans human and non-human access workflows, so teams need to treat reset assurance as a governance control, not a helpdesk convenience.
NHIMG editorial — based on content published by Securden: Secure SSPR Identity Verification for Hybrid Enterprises
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
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 weak reset methods increase account takeover risk?
A: Weak methods such as SMS, email OTP, and security questions can be defeated through SIM swap, mailbox compromise, or social engineering.
Q: What signals show that password reset governance is too fragmented?
A: Common signals include separate reset processes for different platforms, frequent script-based recovery, inconsistent audit records, and users being routed through support for systems outside Entra ID.
Practitioner guidance
- Classify reset paths by account criticality Separate standard users, privileged users, and operational accounts into different recovery policies.
- Eliminate weak methods from privileged recovery Block SMS, personal email, and security questions for accounts that can influence infrastructure, finance, or admin tooling.
- Require two independent verification methods Set a minimum of two methods for every self-service reset and test whether both can be defeated through the same compromise of a phone, mailbox, or device.
What's in the full article
Securden's full article covers the operational detail this post intentionally leaves for the source:
- Method-by-method comparison of SSPR verification options across standard and privileged user classes
- Deployment and directory integration detail for Active Directory, Microsoft Entra ID, and Google Workspace
- Policy examples for deciding which reset methods to allow, restrict, or reserve as backup
- Workflow patterns for keeping privileged credentials out of self-service reset paths
👉 Read Securden's analysis of secure SSPR identity verification →
SSPR identity verification: are your reset controls strong enough?
Explore further
SSPR is a governance control, not a convenience layer. Once an attacker can complete identity verification and set a fresh password, the reset flow becomes part of the access control plane. That means IAM and PAM teams have to treat recovery methods as security decisions, not support options. The practitioner conclusion is simple: reset assurance should be measured against the same risk standard as sign-in assurance.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Another 19% of organisations give AI systems dramatically more access than human employees, which shows how quickly privilege decisions outrun governance.
A question worth separating out:
Q: Who should own password reset assurance in the organisation?
A: Identity and access management, privileged access, and security governance should own reset assurance together. Helpdesk teams may operate the workflow, but they should not define its assurance standard. If the reset path can open access to critical systems, the control belongs in the identity security programme.
👉 Read our full editorial: SSPR identity verification is becoming a board-level control issue