Notifications
Clear all
Topic starter
15/08/2026 6:11 pm
TL;DR: Password reset abuse is now a mainstream account takeover path, with nearly 1 in 4 reset attempts reported as fraudulent and businesses expected to lose $91 billion to ATO fraud by 2028, according to Fingerprint. The control gap is not password strength but recovery governance, because attackers can hijack email, SMS, support workflows, and MFA changes to replace the real user.
NHIMG editorial — based on content published by Fingerprint: password reset attacks and how to stop them
By the numbers:
- Businesses are expected to lose $91 billion to account takeover fraud by 2028, according to Fingerprint.
- U.S. companies paid over $150 million in class-action settlements for data breaches in one six-month period, according to Fingerprint.
Questions worth separating out
Q: What breaks when password reset flows are not separately governed from MFA changes?
A: Attackers can use a single recovery event to replace both the password and the second factor, which defeats the purpose of MFA.
Q: Why do email and SMS recovery channels increase account takeover risk?
A: Because both channels can be compromised without breaking the application itself.
Q: How do security teams know whether password reset controls are actually working?
A: They should test whether resets propagate to every dependent system, whether identity verification remains strong in fallback scenarios, and whether the full event can be reconstructed during review.
Practitioner guidance
- Separate password reset from MFA changes Require an independent step-up verification flow before any recovery event can add, remove, or replace MFA factors.
- Add risk scoring to recovery requests Flag machine-like reset cadence, repeated attempts from one device, and resets that bypass normal UI paths through direct API calls.
- Harden support verification rules Stop relying on static biographical data, security questions, or easily spoofed voice and video checks for account recovery.
What's in the full article
Fingerprint's full article covers the operational detail this post intentionally leaves for the source:
- Detection patterns for abusive reset traffic, including high-volume requests, machine-like cadence, and direct API abuse
- Step-by-step guidance for separating password recovery from MFA changes and enforcing step-up verification
- Specific hardening measures for support teams handling sensitive account recovery
- Device-intelligence examples for distinguishing legitimate resets from account takeover attempts
👉 Read Fingerprint's analysis of password reset abuse and account takeover →
Password reset abuse: where account takeover controls still fail?
Explore further
15/08/2026 6:19 pm
Recovery workflows are now part of the attack surface, not a back-office convenience layer. Password reset abuse works because organisations still treat account recovery as a lower-trust path than primary authentication, even though it can override the original login controls. That assumption collapses when a reset request becomes the fastest route to account takeover. Practitioners should manage recovery as a governed identity lifecycle control, not a support exception.
A question worth separating out:
Q: Who is accountable when a customer support agent approves a fraudulent reset?
A: Accountability sits with the organisation because support workflows are part of the identity control environment. Security, IAM, fraud, and service desk owners all share responsibility for verification rules, escalation paths, logging, and review. Where regulated data or financial access is exposed, compliance and legal teams also need clear incident ownership.
👉 Read our full editorial: Password reset attacks expose the real account takeover weak point
