Customer Account Takeover Support Script Template

When a customer calls to say their account has been taken over, the support agent is either the fastest route back to safety or the attacker's second way in. The caller may be the genuine customer in distress, or the person who took the account and now wants the recovery email changed. The FBI's November 2025 public service announcement on account takeover fraud describes criminals posing as customer and technical support to collect one-time passcodes, then resetting passwords to take full control, with more than 5,100 complaints and over $262 million in reported losses since January 2025. This template is the agent-facing script for phone and chat: what to say, what to verify, what to do in the console, and when to escalate. It is written for contact centre leads, fraud teams and customer identity (CIAM) owners. Prevention controls and the incident-level response sit elsewhere; see the Account Takeover Prevention Guide and the Account Takeover Response Playbook.

How to use this template

Replace the placeholders: [Organisation], [Fraud Team], [CIAM console], [X minutes] and similar. Map every console action named here to the exact button or API call in your tooling before go-live.
Keep the order: the script is sequenced so that containment never depends on verification succeeding, and so nothing the attacker might control (current email, current phone, new device) is trusted for recovery.
Script lines are in quotation marks: agents may rephrase for tone, but must not skip a verification step or reveal account data before verification.
Pair it with your policy: the verification rules here are the customer equivalent of the Help Desk Identity Verification Policy Template; background is in the Account Recovery and Help Desk Security Guide.
Train with role play: run the script against a mock attacker caller who is friendly, urgent and well informed, because that is what real ones sound like.

1. Purpose and scope

1.1 This script tells [Organisation] support agents how to handle any contact, by phone, chat, messaging or email, where a customer reports or suspects that someone else has accessed or changed their account.

1.2 It covers: opening the contact, safe holding containment, verification, recovery of access, clean-up of attacker changes, escalation and closing. It does not cover fraud refund decisions, which follow [refund and reimbursement policy], or workforce account takeover, which follows the internal incident playbook.

1.3 Agents may refuse or pause any request without penalty when verification is incomplete. Speed targets never override this script.

2. Golden rules for agents

Never ask for a password, PIN or one-time code. Tell customers this on every call. The FBI PSA notes that companies generally do not contact customers to ask for a username, password or one-time passcode.
Never use contact details that changed recently. If the email, phone number or MFA method changed in the last [X days], treat it as attacker-controlled until proven otherwise.
Never read out account data to an unverified caller. Not the email on file, not the last four digits of a card, not recent orders. Ask the caller to tell you; never confirm or correct.
Contain first, verify second, recover third. Locking an account harms nobody for long; recovering it for the wrong person is the incident.
Call back on a number you already hold. Do not trust caller ID or a number the caller gives you during the contact.
Escalate, do not improvise. If the situation is not in this script, transfer to [Fraud Team].

3. Opening the contact

3.1 Agent: "I'm sorry this has happened. I'm going to help you secure the account first and then get you back in. For your safety, I will never ask for your password or any code sent to you, and nobody from [Organisation] will."

3.2 Record in the case: channel, time, the number or handle the contact came from, the reason given, and the account identifier the caller supplied. Do not search for and read back the account before section 5.

3.3 Triage questions, asked in this order:

"What made you think someone else is in your account?" (alert email, changed password, unknown order, locked out, message from a contact).
"Can you still sign in right now?"
"Has anyone contacted you recently claiming to be from [Organisation], your bank or technical support, or asked you for a code?"
"Has money, points, stored value or an order been sent anywhere?"

3.4 If the answer to question 3 is yes, warn the customer: "If anyone calls you saying they are from us, hang up and call the number on our website or app."

4. Safe holding containment (before verification)

4.1 Agents may take the protective actions below on the account identifier supplied, without completing verification, because they do not grant access to anyone:

Action	Allowed before verification?	Why
Place a temporary account hold or freeze on sign-in	Yes	Stops further attacker activity; reversible
Freeze outbound payments, payouts, withdrawals, gift card or points redemption	Yes	Protects value while the case runs
Revoke all active sessions and refresh tokens	Yes	Removes attacker sessions; a password change alone may not
Flag the account for [Fraud Team] review	Yes	Triggers monitoring and blocks self-service changes
Reset password, change email or phone, remove or add MFA	No	Grants control; needs section 5 first
Confirm any account detail to the caller	No	Leaks data an attacker can reuse

4.2 Agent: "I've placed a protective hold on the account and signed out every device. Nobody, including you, can sign in until we finish the next steps. This is temporary."

4.3 If a genuine customer could be harmed by a hold (for example a critical service), escalate to [Team Lead] rather than skip it.

5. Verification

5.1 Verification must not rely on anything the attacker may now control or may have harvested. Use the method table below in order and stop at the first that succeeds.

Order	Method	Acceptable when	Do not use when
1	Sign-in with a passkey or authenticator registered before the suspected takeover	Customer still holds the original device	The method was added or changed after the earliest suspicious event
2	Saved recovery code issued to the customer at enrolment	Code not used before	Customer received the code during this contact
3	Issued code to a recovery address on file before the suspicious event, at least [X days] old	Address verified and unchanged	Address changed recently or is the one the attacker added
4	Call-back to a phone number on file before the suspicious event	Number unchanged and no SIM swap or port-out flagged	Number changed recently or carrier flags a recent port
5	Repeated identity proofing: document and selfie check through [proofing service], matched to the identity established at onboarding	The account was identity-proofed at onboarding	Onboarding did not collect comparable evidence
6	Escalation to [Fraud Team] for manual review with transaction and device evidence	Nothing above succeeds	Never skip to this to save time

5.2 NIST SP 800-63B-4 section 4.2 names four classes of account recovery (saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing) and states that recovery must be confirmed consistent with the previously established account. Configure your accepted methods to match the assurance level the account was given.

5.3 Knowledge-based questions (date of birth, postcode, last order, mother's maiden name) must not be used as the deciding factor. They may be used only to locate the account. Data from breaches and social media makes these answers easy for attackers.

5.4 Red flags that require escalation to [Fraud Team] even if a method passes:

The caller pushes to change the email or phone before anything else.
The caller has unusual detail about the account but cannot complete a method in the table.
Background coaching, long pauses after each question, or a third party speaking for the account holder without delegated access on record.
Multiple contacts about the same account across channels within [X hours].
The caller asks the agent to read back a code, or says "I've just received a code, shall I tell you it?" (stop them: "Please don't share it with me.").

5.5 If verification fails: "I'm not able to complete recovery on this contact, but the account stays protected. Here is what happens next: [Fraud Team] will contact you on details we already hold within [X hours]." Never tell the caller which step failed.

6. Recovery and clean-up

6.1 After successful verification, the agent must complete every step below, in order, and tick each in the case:

Review the account change log with the customer from the earliest suspicious event: email, phone, password, MFA methods, passkeys, recovery codes, delivery addresses, payment methods, linked apps and authorised devices.
Remove every authenticator, address and payment method the customer does not recognise. Restore the original email and phone if the attacker changed them.
Invalidate all outstanding reset links, codes and recovery codes, and issue new recovery codes through the verified channel only.
Send the customer a password reset link to the verified email or a one-time sign-in link through the app; never set a password for them or tell them one.
Ask the customer to register a passkey or authenticator app and save new recovery codes: "Let's add a passkey now so a stolen password alone can't get in again."
Revoke third-party app grants and API tokens the customer does not recognise.
Lift the hold set in section 4 only after steps 1 to 6 are complete.

6.2 NIST SP 800-63B-4 requires that account recovery causes a notification to the subscriber, sent to all notification addresses except postal, with instructions in case the recipient repudiates the event. Confirm the notification has gone to the old and new addresses.

6.3 Agent: "You'll get a message confirming what we changed. If you ever receive one you don't recognise, contact us using the number in the app, not the one in the message."

7. Advice to give the customer

7.1 Read out, or send as a follow-up message, the points below. They follow the NCSC's guidance on recovering a hacked account:

Check your email account for forwarding rules or filters you did not set up.
Change the password on any other account where you used the same password.
Turn on 2-step verification on your email and banking accounts.
Update the software on your phone and computer.
Tell your contacts if messages may have been sent from your account.
Check bank statements for unauthorised payments and contact your bank through its official number.
Report losses: in the UK to Report Fraud, in the US to the FBI's IC3, or to your national reporting centre [insert].

8. Escalation matrix

Situation	Escalate to	Target time
Money, stored value or points moved out	[Fraud Team] and [Payments Operations] for recall	[Immediately, within X minutes]
Verification failed or red flags present	[Fraud Team]	[X hours]
Several accounts reported in a short period, or a spike in takeover contacts	[Security Operations]: possible credential stuffing or platform issue	[Immediately]
Caller claims to be law enforcement, a lawyer or a relative	[Legal / Data Protection Officer]	[X hours]
Personal data exposed (address, ID documents, payment data)	[Data Protection Officer] for breach assessment	[Same day]
Vulnerable customer or distress	[Vulnerable Customer Team]	[Same contact]

8.1 A spike in takeover contacts is a detection signal. Report it to [Security Operations] and see the Credential Stuffing Attack Response Playbook.

9. Closing and case record

9.1 Agent: "Your account is secured. To recap: we signed out every device, removed [items], and you've set up [passkey/authenticator]. Your case reference is [ref]."

9.2 The case record must contain: contact channel and source number; triage answers; containment actions with timestamps; verification method used and result (never the code or answer itself); attacker changes found and reversed; escalations; and notifications sent. Records are retained for [period] under [records policy].

10. Quality, metrics and review

10.1 [Team Lead] reviews [X]% of takeover contacts weekly and every contact where recovery was granted on method 5 or 6.

10.2 Measures: time from first contact to containment; share of recoveries that used a pre-incident authenticator or recovery code; repeat takeover of the same account within 30 days; recoveries later found to be fraudulent; and escalations closed within target.

10.3 This script is reviewed at least annually and after any recovery granted to an attacker.

Implementation guidance

Build containment into the console. A single "protect account" action that holds sign-in, revokes sessions and freezes payouts makes section 4 fast enough that agents use it every time.
Show change history to agents. Agents cannot apply the "recently changed" rule without seeing when email, phone and MFA methods last changed. Surface it on the case screen.
Give customers better recovery options. Saved recovery codes and passkeys make the top of the verification table usable. See the Passkey account recovery guide.
Train for the attacker caller. The FBI and CISA advisory on Scattered Spider describes social engineering of help desks to reset passwords and MFA; customer support faces the same pattern. See the Help Desk Social Engineering Incident Playbook.
Common failure patterns. Resetting the password but leaving sessions and attacker MFA methods in place; sending the reset link to the email the attacker added; confirming account data to "help" the caller; and agent targets that reward short handling time over completed verification.

Customer Account Takeover Support Script Template: Recovery Without Re-Compromise