Account Recovery and Help Desk Security Guide

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 password and MFA resets. This guide covers recovery design for workforce and customer accounts, caller verification, controls for privileged MFA resets, AI support assistants, credential re-issuance for non-human identities, and what to monitor. It is for identity, service desk and security operations teams, and owners of outsourced help desk contracts.

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.
Verify callers with evidence they cannot research. Dates of birth, employee numbers and manager names are easy to find or buy; use a registered device, a call-back to a number on file, or live identity verification instead.
Treat privileged MFA resets as privileged actions. Route them away from the first-line desk, require a second approver, and constrain help desk roles so they cannot reset administrators.
Reduce the need for recovery. Register at least two strong authenticators per person, so losing one does not require a reset.
Watch what happens straight after recovery. New devices, new MFA registrations and privileged activity in the hour after a reset are the clearest signs that a recovery was fraudulent.

Why recovery is targeted

Recovery exists for people who cannot authenticate normally, so it has to accept some other kind of evidence. NIST SP 800-63B-4 is blunt about the risk: it calls authenticator replacement "the weak point in many authentication mechanisms" and warns that human-assisted recovery is exposed to social engineering. Attackers aim here because of:

Weaker evidence by design: recovery often relies on knowledge, email or SMS, all of which can be researched, phished or hijacked through a SIM swap.
Pressure on agents: desks are measured on speed, and social engineers exploit urgency and seniority.
Third parties with broad powers: outsourced desks may hold reset rights across many customers with little local context. CISA describes Scattered Spider as targeting large companies "and their contracted information technology (IT) help desks". M&S chairman Archie Norman told MPs that attackers used "sophisticated impersonation" of one of the retailer's third-party users; see the Marks and Spencer Cyberattack 2025.
Automated support: AI assistants that can change recovery details can be talked into doing it for the wrong person, as the Meta AI Instagram Account Takeover 2026 showed.
Self-service flows that trust the user's approval: Microsoft assessed with high confidence that Storm-2949 started self-service password resets for targeted users, then posed as IT support to persuade them to approve the MFA prompts; see the Storm-2949 Azure Attack 2026.

How a help desk attack unfolds

The CISA and FBI advisory on Scattered Spider (updated July 2025) describes a layered approach that often runs over several calls. The attackers first learn what the help desk needs for a password reset, then call employees and the desk again to gather that information about a specific target, and finally call the desk to reset the password or transfer MFA to a device they control. They then register their own MFA tokens and move to single sign-on applications. The MGM Resorts Breach 2023 began with a help desk call impersonating an employee found on LinkedIn, according to vx-underground. See the Threat Actor Groups Guide for the wider group.

Attack stage (per CISA, Okta and Mandiant reporting)	What the defender can do
Gather personal data on staff with elevated access from social media, open sources and leaks	Stop using personal data as verification evidence
Probe the desk to learn the reset procedure	Restrict access to reset and MFA documentation; log calls that ask about process
Call as the target and ask for a password or full MFA reset	Positive identity verification, call-back to a number on file, privileged resets blocked at first line
Register an attacker-controlled MFA method	Restrict registration to trusted locations and compliant devices; alert on new registrations
Use the account, often from proxies or new devices, to reach the identity provider and privileged roles	Alert on sign-ins from anonymising proxies and new devices after a reset; require re-authentication for admin actions

Designing recovery

Reduce the need for recovery

NIST SP 800-63B-4 says organisations should encourage people to keep at least two separate means of authentication and must permit more than one authenticator per account. In practice:

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. See the Passwordless and Passkeys Guide.
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.

Use recognised recovery methods

NIST SP 800-63B-4 recognises four classes of recovery method and requires any alternative (such as interaction with an agent) to be based on a documented risk analysis.

Method (NIST SP 800-63B-4)	Key requirements	Watch out for
Saved recovery codes	At least 64 bits from an approved random bit generator; stored hashed; invalidated after use and replaced	Users storing codes alongside the device they protect
Issued recovery codes	At least six digits; valid for at most 10 minutes by text or voice and 24 hours by email; new recovery addresses must be confirmed first	SIM swap and mailbox takeover give the attacker the code
Recovery contacts	Trusted associates receive the code; users can view and manage contacts; annual reminder to review	Contacts who can be socially engineered themselves
Repeated identity proofing	Repeat the proofing steps at the original level and confirm the identity matches the existing account	Deepfake and injected media in remote sessions

For an account that can authenticate at AAL2, NIST requires two recovery codes obtained by different methods, one recovery code plus a single-factor authenticator already bound to the account, or repeated identity proofing. Every recovery must trigger a notification. NIST also states that one authentication factor must not be usable to obtain an authenticator of a different factor: a password alone should never be enough to get new backup codes.

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; NIST requires a new authenticator to be bound at the highest assurance level the account supports, with an independent notification.
Revoke existing sessions, refresh tokens and outstanding reset links, as the OWASP Forgot Password Cheat Sheet recommends. See the Token and Session Security Guide.
Do not rely on recovery details that were recently added or changed, and do not automatically restore superseded addresses or phone numbers (OWASP).
Apply a cooling-off period before changes to payout details, contact details or MFA methods.
Notify the user through every known channel; NIST requires at least two notification addresses and clear instructions for reporting an event the user did not make.

Help desk verification

Knowledge-based questions are easy to research or buy. NIST SP 800-63A-4 states that knowledge-based verification shall not be used for identity verification, and Mandiant's hardening guidance for UNC3944 (the group that overlaps with Scattered Spider) warns against publicly available data such as date of birth because the group often already has it.

Verification method	Strength	Notes
In-person check against photo ID	Highest	Use for administrator and break-glass accounts; Mandiant lists in-person and on-camera checks for privileged accounts
Push or passkey challenge to an already registered device	High	Only works when the person still has a device; never accept a code read out over the phone
Live video verification against ID with liveness checks	High, if well run	Okta recommends visual verification; NIST SP 800-63A-4 warns that deepfakes and injected media can defeat video sessions
Remote identity verification service	High, if well run	Document and liveness checks; NIST requires controls that detect virtual cameras and emulators
Call-back to a number in the HR system	Medium	Mandiant recommends a call-back to a registered number; weak if the number was recently changed or the phone was SIM-swapped
Manager or peer confirmation through a known channel	Medium	Use the corporate directory, not contact details the caller gives
Knowledge questions and personal data	Not acceptable alone	Ruled out for identity verification by NIST SP 800-63A-4

Where agents compare faces with ID, NIST SP 800-63A-4 requires them to be trained, assessed and reassessed annually, with good image quality and tools. See the Deepfake and AI Impersonation Guide for the synthetic media risk.

Help desk process controls

Scripted verification: agents follow fixed steps and cannot skip them under pressure. Mandiant recommends positive identity verification as the first step of any account management activity, including initial enrolment.
Privileged resets at a dedicated team: block them at the first-line desk. Okta recommends help desk roles that exclude highly privileged administrators.
Two-person approval: require a second approver for privileged MFA resets, and dual authorisation for just-in-time elevation. See the JIT Access Guide.
Permission to hang up: agents may end any call and call back on a known number, and urgency or seniority is treated as a warning sign.
Elevated threat mode: Mandiant suggests temporarily disabling self-service MFA resets during elevated threat periods and routing changes through manual workflows with more scrutiny.
Same rules for suppliers: hold outsourced desks to the same standard and audit them. See the Third-Party Access Guide.
Hardened help desk accounts: scope help desk admin roles narrowly and give those accounts phishing-resistant MFA. See the Phishing-Resistant MFA Guide.

Staff also need to know the reverse attack: Mandiant and CISA both report attackers posing as the help desk to employees, by phone, SMS or collaboration tools such as Microsoft Teams, to obtain codes or install remote access tools. See the Security Awareness and Human Risk Management Guide.

Recovery for customers

Customer recovery must work at scale for people the organisation has never met. The OWASP Forgot Password Cheat Sheet sets the baseline for self-service flows:

Return the same message, in the same time, for accounts that exist and accounts that do not, so attackers cannot enumerate users.
Rate limit reset requests per account and apply bot defence.
Use random, single-use, time-limited tokens, and do not log the user in automatically after a reset.
Avoid email-only recovery for accounts that hold money, sensitive data or control other accounts.

The OWASP Multifactor Authentication Cheat Sheet adds that changing an MFA factor should require re-authentication with an existing factor rather than trust in the active session, should be treated as a high-risk action with risk checks, and should trigger an out-of-band notification. See the Customer IAM (CIAM) Guide for the wider customer journey.

AI support assistants

Do not let support staff or chatbots change the recovery email or phone without independent verification. In the Meta case, Help Net Security reported that Meta said attackers hijacked 20,225 Instagram accounts because a bug in its AI-assisted recovery system did not check that the email supplied matched the account, so reset links went to attacker addresses. Meta disabled the tool and invalidated the reset links.

The OWASP Top 10 for LLM Applications calls this class of problem Excessive Agency (LLM06:2025): too much functionality, too many permissions or too much autonomy. Its mitigations apply directly: give the assistant no tool that changes recovery details, enforce authorisation in the downstream system rather than in the model, and require human approval for high-impact actions. See the AI Agent Authorisation Guide.

Recovery for non-human identities

Machines do not forget passwords, but NHI credentials still get lost, expire or leak. For a service account, API key or certificate, "recovery" means re-issuance, and it needs the same discipline as a human reset:

A named owner who can request re-issuance, so an attacker cannot simply ask for a new key. See the NHI Ownership Guide.
Approval and verification of the requester, as NIST SP 800-53 control IA-5 requires identity verification when authenticators are distributed and procedures for lost or compromised ones.
Automated rotation and short lifetimes, addressing OWASP NHI7:2025 Long-Lived Secrets.
Revocation of the old credential at the same time, so a leaked secret (OWASP NHI2:2025) stops working. See the Leaked Credential Response Playbook.

What to monitor

The NCSC's recommendations after the 2025 attacks on UK retailers include reviewing how the help desk authenticates staff before resetting passwords, paying specific attention to Domain Admin, Enterprise Admin and Cloud Admin accounts, and making sure the SOC can spot logins from atypical sources such as VPN services in residential ranges. See the ITDR Guide for the wider detection programme.

Signal	Why it matters	Source
All MFA factors reset for one user	The core step in the attacks Okta described against Super Administrators	Okta (event `user.mfa.factor.reset_all`)
New MFA device, app or phone number registered	Attackers register their own method straight after a reset	Mandiant, CISA, Microsoft
Same MFA method or phone number on several accounts	Points to attacker-controlled devices	Mandiant
Reset followed by sign-in from a new device, proxy or VPN	Okta saw anonymising proxies and unfamiliar devices after resets	Okta, NCSC
Reset followed by access to the identity provider admin console or privileged roles	The route from one account to the whole tenant	Okta, Microsoft
Changes to conditional access, trusted locations or federation	Used to bypass MFA or impersonate users	Mandiant, Okta
Several resets by one agent in a short period, or recovery contact changes on many accounts	Suggests a campaign or an insider	Internal process telemetry

When a reset proves fraudulent, the response is an identity incident: revoke sessions and tokens, review MFA registrations and recently enrolled devices, and check for changes to authentication policy, as Mandiant's playbook guidance sets out. See the Identity Incident Response Playbook.

Framework mapping

Mappings are to control areas whose text covers the requirement; check them against your own control set.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP
Recovery and authenticator replacement procedures	PR.AA-01, PR.AA-03	IA-5	5.17, 8.5	6 Access Control Management	-
Caller verification and re-proofing	PR.AA-02	IA-12, IA-12(3)	5.16	5 Account Management	-
Privileged reset restrictions and second approver	PR.AA-05	AC-5, AC-6	5.3, 8.2	6 Access Control Management	-
Re-authentication before factor changes	PR.AA-03	IA-11	8.5	6 Access Control Management	-
Help desk social engineering training	PR.AT-01, PR.AT-02	AT-2(3)	6.3	14 Security Awareness and Skills Training	-
Outsourced help desk requirements	GV.SC-05, GV.SC-07	-	5.20, 5.22	15 Service Provider Management	-
Monitoring resets and post-recovery activity	DE.CM-03, DE.AE-03	AC-2(12), AU-6, SI-4	8.15, 8.16	8 Audit Log Management	-
Containing a fraudulent recovery	RS.MI-01	IR-4	5.26	17 Incident Response Management	-
AI support assistants with account tools	PR.AA-05	AC-6	5.15	6 Access Control Management	LLM06:2025 Excessive Agency
NHI credential re-issuance	PR.AA-01	IA-5	5.17	5 Account Management	NHI2:2025, NHI7:2025

Common failure patterns

Knowledge questions as the gate: employee ID, date of birth and manager name are exactly what CISA says Scattered Spider gathers before calling.
First-line agents who can reset anyone: in the attacks Okta described, callers asked the desk to reset all MFA factors for Super Administrators, then used those accounts to weaken policy and add an identity provider.
Self-service resets that trust a prompt approval: Storm-2949 persuaded users to approve MFA prompts for a password reset the attacker had started, then removed their methods and enrolled its own.
Suppliers outside the standard: outsourced desks and contractors whose verification is weaker than the customer's own, as in the M&S attack.
Chatbots with write access to recovery details: a missing server-side check turned an AI assistant into a reset tool for strangers in the Meta case.
Recovery that skips session revocation: the password changes but the attacker's session, tokens and enrolled device stay valid.
Admins on legacy MFA: Mandiant recommends that administrative users cannot register or use legacy methods even where lower-tier users can. See the MFA Fatigue and Bypass Guide.

Metrics that show progress

Metric	What it shows	Target direction
Share of users with two or more strong authenticators registered	How often recovery should be needed at all	Up
Help desk resets per 1,000 users	Demand on the riskiest route	Down
Share of resets verified by registered device, call-back or identity verification	Whether weak evidence is still accepted	Up, towards 100%
Privileged resets with a second approver recorded	Whether the control is followed	100%
Recoveries followed by session and token revocation	Whether recovery closes the attacker's door	100%
Time to review alerts on resets followed by high-risk activity	Detection speed	Down
Pass rate in social engineering tests of the desk, including suppliers	Real-world resistance	Up

Implementation roadmap

Phase	Actions
First 30 days	Map every recovery route for workforce, customer and machine accounts; remove knowledge questions as a sole check; block privileged resets at the first line; turn on alerts for full MFA resets and new MFA registrations
Days 31 to 90	Introduce call-back and registered-device verification; add two-person approval for privileged resets; constrain help desk roles; revoke sessions automatically after recovery; restrict MFA registration to trusted locations and compliant devices
Days 91 to 180	Roll out a second strong authenticator for every user; add identity verification with liveness and injection controls for high-risk resets; bring outsourced desks and AI assistants under the same standard by contract and audit; run a social engineering exercise and a tabletop on a fraudulent reset

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, and exclude administrators from help desk roles.
Require re-authentication with an existing factor before any MFA change.
Revoke sessions and tokens and require new authenticator registration after every recovery.
Notify users of every recovery and factor change through all known channels.
Apply the same standards to outsourced help desks and AI support assistants.
Re-issue NHI credentials only at an owner's request, with rotation and revocation of the old secret.
Alert on resets followed by new devices, proxies or privileged activity.
Test the process with social engineering exercises.