A help desk that resets a password or re-registers MFA on the strength of a convincing phone call hands the attacker the account, along with every control that sat behind it. The joint FBI and CISA advisory on Scattered Spider describes attackers using voice calls to get help desk staff to reset passwords and MFA tokens, leading to account takeover in single sign-on environments. This template gives you a ready-to-adapt policy for verifying anyone who asks the service desk to change credentials, authentication methods or access. It covers verification tiers, extra rules for privileged users, MFA reset and enrolment, video checks, third-party help desks, escalation and records, and maps the controls to ISO/IEC 27001:2022 and NIST CSF 2.0. The background and the reasoning sit in the Account Recovery and Help Desk Security Guide; this page is the policy document itself.
How to use this template
- Replace text in square brackets, such as [Organisation], [Service Desk] and [Security Operations], with your own names, and set the values shown as [X] to suit your risk appetite.
- "Must" is mandatory; "should" is recommended, and any deviation needs a recorded reason.
- Pick verification methods your tooling can actually support. If you cannot send a push challenge to a registered device, do not list it as a Tier 1 method.
- Give the policy to outsourced service desk providers as a contractual requirement, not as guidance.
- Pair it with the Help Desk Social Engineering Incident Playbook so agents know what happens after they refuse or report a suspicious call.
- Review it at least annually and after any social engineering incident.
1. Purpose
This policy sets the minimum identity verification that [Service Desk] must complete before changing any credential, authentication method or access right for a user of [Organisation] systems. Its purpose is to prevent account takeover through impersonation of employees, contractors, executives or IT staff, while still letting genuine users recover access quickly.
2. Scope
This policy applies to every request, through any channel (telephone, chat, email, ticket, walk-up or video), to:
- Reset or unlock a password or passphrase.
- Register, reset, remove or replace an MFA method, including authenticator apps, phone numbers, hardware security keys and passkeys.
- Issue a temporary access code or bootstrap credential.
- Change a recovery email address, phone number or other recovery attribute.
- Grant, elevate or restore access rights, group memberships or privileged roles.
- Re-enrol or replace a device that holds credentials, such as a managed laptop or phone.
It applies to all staff of [Service Desk], to any third party that provides service desk or identity support to [Organisation], and to administrators who perform these actions outside the service desk.
3. Definitions
- Requester: the person asking for the change. The requester is untrusted until verified.
- Subject: the account owner whose credentials or access would change.
- Verification: confirming that the requester is the subject, using methods in section 5.
- Registered device or method: an authenticator or device already bound to the subject's account before the request was made.
- Out-of-band channel: a contact route taken from [Organisation]'s authoritative directory or HR system, never from details the requester supplies during the call.
- High-risk account: any account listed in section 6.
- Temporary access credential: a short-lived code used to sign in once and register a new authentication method, for example a Microsoft Entra Temporary Access Pass.
4. Roles and responsibilities
- [Service Desk] agents: follow this policy for every request, record the verification performed, and may refuse any request without penalty when verification is incomplete.
- [Service Desk] team leads: approve Tier 3 actions, review a sample of completed verifications each week, and coach agents.
- Line managers and sponsors: respond to verification call-backs and confirm the identity of their staff when asked.
- [IAM team]: configure identity tooling to enforce this policy, including self-service recovery, temporary access credential settings and alerting.
- [Security Operations]: receive suspicious request reports, monitor credential changes, and lead response.
- [CISO]: owns this policy and approves exceptions.
5. Verification tiers
5.1 Agents must verify every requester before acting, and must apply the tier that matches the action requested and the account involved. Where more than one tier applies, the higher tier wins.
5.2 Knowledge that can be found or bought, such as employee number, date of birth, manager's name, office location or the last four digits of a phone number, must not be used as the sole or main verification for any tier.
| Tier | Actions covered | Minimum verification (all listed) |
|---|---|---|
| Tier 1: standard | Password reset or unlock for a standard account where the user still has a working registered MFA method | Successful challenge to a registered MFA method (push with number matching, or code from a registered authenticator app), initiated by the agent from the identity platform |
| Tier 2: elevated | Any MFA method reset, removal or new registration; changes to recovery attributes; password reset where no registered method works; device re-enrolment | Out-of-band call-back to the number in the authoritative directory, plus one of: live video check against the HR photo with photo ID shown on camera, confirmation from the line manager reached through the directory, or in-person check at a [Organisation] site |
| Tier 3: high risk | Any credential or MFA change for a high-risk account (section 6); any privileged role grant; any request that fails or partly fails Tier 2 | In-person verification with photo ID at a [Organisation] site, or live video verification with photo ID plus manager confirmation, plus approval from a [Service Desk] team lead and notification to [Security Operations] before the change |
5.3 Agents must initiate verification themselves. A requester who offers their own call-back number, sends a photo of an ID, or asks the agent to accept a code they read out must be treated as unverified.
5.4 Where [Organisation] has a document-based or biometric identity verification service, it should be used for Tier 2 and Tier 3 instead of manual photo comparison. See the Workforce and Help Desk Identity Verification Buyer's Guide.
5.5 If any verification step fails, the agent must stop, must not explain which step failed, and must follow section 10.
6. High-risk accounts
6.1 The following accounts are high risk and always require Tier 3:
- Members of privileged directory and cloud roles, for example Global Administrator, Privileged Role Administrator, Domain Admins and cloud organisation administrators.
- Identity platform, PAM and security tooling administrators.
- [Service Desk] staff with permission to reset credentials.
- Executives and their assistants, finance approvers and staff with payment authority.
- Accounts with access to [crown jewel systems].
6.2 Administrators should hold a separate administrative account. Credential resets for administrative accounts must not be performed by first-line agents; they must be routed to [IAM team] and verified under Tier 3.
6.3 The list of high-risk accounts must be maintained by [IAM team], reviewed every [quarter], and flagged in the service desk tool so agents see it when they open the record.
7. MFA reset and enrolment rules
7.1 MFA methods must not be reset, removed or added during the same call that raised the request, unless Tier 2 or Tier 3 verification has been completed in full.
7.2 After verification, the user should register the new method themselves using a temporary access credential. Temporary access credentials must be one-time use, valid for no more than [1 hour], and delivered through the verified out-of-band channel or in person, never read out to an unverified caller.
7.3 Agents must not register an authenticator, phone number or security key on the user's behalf, or accept a code the requester reads out, as a substitute for the user enrolling directly.
7.4 Phone numbers newly added for SMS or voice must not be usable for recovery for [72 hours] where the platform supports a hold period.
7.5 After any credential or MFA change, the identity platform must notify the user through all previously registered channels, and the user's existing sessions and refresh tokens must be revoked.
7.6 [Organisation] should move users to phishing-resistant methods (FIDO2 security keys or passkeys) over time; CISA notes that FIDO/WebAuthn and PKI-based MFA resist phishing, push bombing and SIM swap attacks. Recovery for phishing-resistant methods should use a second registered key or in-person issue. See the Passkey account recovery guide.
8. Video verification
8.1 Video checks must be live, initiated by the agent through [approved video platform] using the subject's directory identity, and must not use a link or meeting supplied by the requester.
8.2 The agent must compare the person on camera with the HR photo, ask them to show photo ID on camera, and ask them to perform a simple live action chosen at random by the agent, such as turning their head or holding the ID beside their face.
8.3 Because synthetic video and voice can defeat a casual check, a video check must always be combined with a second factor from section 5 and must never be the only Tier 3 control. See the Deepfake-Resistant Identity Verification Guide.
8.4 Video sessions must not be recorded unless [Organisation]'s privacy notice covers it; the agent records the outcome and the ID type checked, not an image of the document.
9. Third-party and outsourced help desks
9.1 Providers must apply this policy in full, and contracts must give [Organisation] the right to audit verification records.
9.2 Provider agents must not hold privileged roles beyond what their tasks require, and Tier 3 actions must be performed or approved by [Organisation] staff.
9.3 Requests from people claiming to be provider staff, vendor engineers or contractors must be verified against the contracting organisation through a known contact, not through details given on the call.
10. Suspicious requests and escalation
10.1 Agents must treat the following as warning signs: pressure or urgency, claims of seniority, requests to skip steps, calls outside normal hours, a requester unable to use any registered method, a new phone number, background noise inconsistent with the claimed location, and several requests for the same account or team in a short period.
10.2 Where verification fails or warning signs are present, the agent must politely end the request, must not make any change, must place a [temporary hold] flag on the account, and must report the request to [Security Operations] within [15 minutes] through [reporting channel].
10.3 [Security Operations] must contact the genuine subject through the out-of-band channel, review recent sign-ins and changes to the account, and invoke the incident playbook where impersonation is confirmed.
10.4 No agent will be disciplined for refusing a request that turns out to be genuine, where they followed this policy.
11. Records and monitoring
11.1 Every credential, MFA or access change must be linked to a ticket that records the requester, channel, tier applied, verification methods used and outcome, approver (Tier 3) and the agent.
11.2 [Security Operations] should alert on: MFA method registration shortly after a help desk password reset; temporary access credential creation for high-risk accounts; several resets by one agent in a short period; and sign-ins from new devices or locations straight after a reset.
11.3 [Service Desk] team leads must review at least [5%] of Tier 2 and all Tier 3 verifications each month and report results to [CISO].
12. Training
12.1 All agents must complete training on this policy and on voice social engineering before handling credential requests, and refresher training at least every [12 months].
12.2 [Organisation] should run simulated impersonation calls against the service desk at least [twice a year], with prior approval from [CISO]. See the Vishing and Help Desk Social Engineering Awareness Guide.
13. Exceptions
Exceptions must be approved in writing by [CISO], time-limited to no more than [90 days], recorded in the exception register with compensating controls, and must never remove the out-of-band call-back for MFA changes.
14. Compliance and framework mapping
Breaches of this policy are handled under [Organisation]'s disciplinary process. The policy supports the following controls:
| Policy section | ISO/IEC 27001:2022 Annex A | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| 5 Verification tiers | A.5.16 Identity management | PR.AA-02 Identities are proofed and bound to credentials | IA-12 Identity Proofing |
| 6 High-risk accounts | A.5.18 Access rights | PR.AA-01 Identities and credentials are managed | AC-2 Account Management |
| 7 MFA reset and enrolment | A.5.17 Authentication information | PR.AA-03 Users, services and hardware are authenticated | IA-5 Authenticator Management (identity verified at authenticator distribution; procedures for lost or compromised authenticators) |
| 10, 11 Escalation and monitoring | A.5.24 Information security incident management planning and preparation | DE.CM-03 Personnel activity and technology usage are monitored | AC-2, IA-2 |
| 12 Training | A.6.3 Information security awareness, education and training | PR.AT-01 Awareness and training | AT-2 Literacy Training and Awareness |
The attacker behaviours this policy targets appear in MITRE ATT&CK as T1566.004 Spearphishing Voice, T1598 Phishing for Information, T1078.002 Domain Accounts, T1199 Trusted Relationship and T1621 Multi-Factor Authentication Request Generation.
15. Related documents
- [Organisation] Access Control Policy
- [Organisation] Incident Response Plan and the help desk social engineering playbook
- [Organisation] Privileged Access Management Standard
- [Service Desk] verification work instructions and scripts
16. Review
[CISO] reviews this policy every [12 months], after any social engineering incident, and when identity tooling changes. Version: [x.y]. Approved by: [name, role]. Date: [date].
Implementation guidance
- Measure the current state first. Pull three months of reset and MFA change tickets and record how callers were verified. Most organisations find knowledge questions doing most of the work.
- Build the tooling before the rule. Agent-initiated MFA challenges, a directory phone number view, a high-risk flag in the ticket form and one-time temporary access credentials need to exist before agents can comply. In Microsoft Entra, for example, Temporary Access Pass supports a one-time use setting and lifetimes from 10 minutes up, and only the Privileged Authentication Administrator role can create one for administrators.
- Push volume to self-service. Every reset a user can complete with an existing registered method is one the help desk does not have to verify. See the Self Service Password Reset and Help Desk Verification buyer's guide.
- Pilot Tier 2 and Tier 3 with one team for two to four weeks, track call handling time and refusal rates, then adjust scripts before wider rollout.
- Brief executives in advance. Tier 3 will slow down executive resets on purpose; get leadership to support that publicly so agents are not overruled.
- Test it. Run an approved impersonation exercise after rollout and track the results as a metric.
Lessons from incidents: in the MGM Resorts breach, the attackers claimed (MGM has not confirmed the detail) that a help desk call impersonating an employee found on LinkedIn led to identity platform admin access. In the Co-op cyber attack, reporting described an employee password reset obtained through social engineering. Both point to the same control: verification that public information cannot satisfy.
Metrics to track: share of MFA changes completed with Tier 2 or above (target 100%); share of resets done through self-service; median time to verify for Tier 2; suspicious requests reported per month; impersonation test pass rate; Tier 3 changes made without [Security Operations] notification (target zero).
Standards and references
- CISA and FBI: Scattered Spider advisory AA23-320A
- NIST: SP 800-63B-4 Digital Identity Guidelines: Authentication and Authenticator Management
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- Microsoft Learn: Configure Temporary Access Pass
- MITRE ATT&CK: Spearphishing Voice
Related NHI Mgmt Group resources: Account Recovery and Help Desk Security Guide · Help Desk Social Engineering Incident Playbook · Scattered Spider Threat Actor Profile · Workforce and Help Desk Identity Verification Buyer's Guide