Account recovery is a second way into every account, and attackers increasingly prefer it to the front door. When someone loses a phone or forgets a password, a recovery flow or a help desk agent has to decide whether they are really who they claim to be. If that decision is weaker than normal sign-in, it becomes the easiest path to a takeover. Groups such as Scattered Spider have built whole campaigns around calling help desks, impersonating staff and asking for MFA resets. This guide explains how to design recovery for workforce and customer accounts, how to verify callers, how to protect MFA resets for privileged users, and what to monitor.
Key takeaways
- Recovery must be as strong as the authentication it replaces. A phishing-resistant sign-in with an SMS recovery path is only as strong as SMS.
- Help desk staff should verify identity with evidence the caller cannot easily obtain, not with personal details an attacker can research.
- Treat MFA resets for privileged users as privileged actions, with extra verification and a second approver.
- Give people more than one strong factor at enrolment, so losing one does not require a reset.
- Monitor recovery events and what happens straight after them: new devices, MFA registrations and privileged activity.
Why recovery is targeted
- It is designed for people who cannot authenticate normally, so it has to accept weaker evidence.
- It often relies on channels such as SMS and email, which attackers can hijack.
- Help desk agents are measured on speed and customer satisfaction, and social engineers exploit that.
- Outsourced and third-party help desks may have broad reset powers and less context. The Marks and Spencer attack involved impersonation of a third-party user.
- Automated support, including AI chatbots, can be manipulated. The Meta AI support assistant takeover saw attackers ask a chatbot to link their email to other people's accounts.
- Self-service password reset tied to a phone number can be abused. See the Storm-2949 attack.
Designing recovery
Reduce the need for recovery
- Register at least two strong authenticators per person, such as a passkey on the laptop and a security key or a passkey on the phone.
- For customers, encourage a second passkey and store verified recovery contacts.
- Issue single-use recovery codes where the platform supports them, and treat them like passwords.
Match recovery to the account's risk
| Account type | Suggested recovery route |
|---|---|
| Privileged and administrator accounts | In-person or live video verification against a registered photo ID, with manager or security approval and a fresh hardware authenticator |
| Standard workforce accounts | Verification through an existing second factor, manager confirmation through a known channel, or remote identity verification |
| High-value customer accounts | Re-proofing with document and liveness checks rather than email or SMS alone. See the Identity Proofing and KYC Guide |
| Low-risk customer accounts | Verified email or phone plus risk signals, with a cooling-off period before sensitive changes |
Limit what recovery grants
- After recovery, require the user to register a new strong authenticator in the same session.
- Revoke existing sessions and refresh tokens.
- Apply a cooling-off period before changes to payout details, contact details or MFA methods.
- Notify the user through every known channel that recovery happened.
Help desk verification
Knowledge-based questions (date of birth, employee ID, manager's name) are easy to research or buy. Stronger options include:
- Push or passkey challenge to a device the person has already registered, when they still have one.
- Call-back to a number on file in the HR system, not the number the caller gives.
- Manager or peer confirmation through a separate, known channel.
- Live video verification against the photo on file or a government ID, with liveness checks. Be aware that deepfake video is now a real risk; see the Deepfake and AI Impersonation Guide.
- Remote identity verification through a proofing service with document and liveness checks.
- In-person verification for the highest-risk resets.
Help desk process controls
- Script the verification steps and do not allow agents to skip them under pressure.
- Block resets for privileged accounts at the first-line help desk; route them to a dedicated team.
- Require two-person approval for privileged MFA resets.
- Give agents the right to end a call and call back, and make clear that urgency is a warning sign.
- Record calls and reset actions, and review a sample regularly.
- Apply the same rules to outsourced and third-party help desks, and audit them.
- Scope help desk admin roles narrowly, and give help desk accounts phishing-resistant MFA themselves.
Recovery for customers
- Avoid email-only recovery for accounts that hold money, sensitive data or control other accounts.
- Do not let support staff or chatbots change the recovery email or phone without verification. AI support assistants should have no tool that changes recovery details without an independent check.
- Rate limit recovery attempts and apply bot defence.
- Watch for linked attributes, such as one new recovery email added to many accounts.
The Customer IAM (CIAM) Guide covers the wider customer journey.
Recovery for non-human identities
Machines do not forget passwords, but NHI credentials still get lost, expire or leak. The "recovery" process is re-issuance, and it needs the same discipline: an owner who can request it, an approval, automated rotation, and revocation of the old credential. See the NHI Ownership Guide and the Leaked Credential Response Playbook.
What to monitor
- MFA resets and new authenticator registrations, especially for privileged users.
- Recovery or reset followed quickly by sign-in from a new device or location.
- Recovery followed by access to email, file shares, the identity provider admin console or privileged roles.
- Multiple resets handled by the same agent in a short time.
- Recovery contact changes on many accounts from similar sources.
Practitioner checklist
- Map every recovery route for workforce and customer accounts and rate each against the sign-in it replaces.
- Register at least two strong authenticators per person.
- Replace knowledge questions with verification through a registered device, call-back to a known number or identity verification.
- Route privileged resets to a dedicated team with two-person approval.
- Revoke sessions and require new authenticator registration after every recovery.
- Apply the same standards to outsourced help desks and AI support assistants.
- Alert on resets followed by high-risk activity.
- Test the process with social engineering exercises.
Standards and references
- NIST SP 800-63B-4: Authentication and Authenticator Management (2025), including authenticator event management and recovery
- NIST SP 800-63A-4: Identity Proofing and Enrollment (2025)
- CISA and FBI advisory AA23-320A: Scattered Spider (updated 2025)
- OWASP Forgot Password Cheat Sheet
Related NHI Mgmt Group resources: MFA Guide · Workforce Identity Security Guide · Identity Provider and SSO Security Guide · Deepfake and AI Impersonation Guide
