Feature Incident Response
AI-Powered Vishing at the Help Desk: The Authentication Controls NYDFS Is Now Requiring
Vishing attacks surged 442% in H2 2024 and now dominate social engineering engagements. NYDFS issued its first vishing-specific advisory on February 6, 2026. Here's the authentication control framework — challenge protocols, identity verification procedures, and incident response steps — that regulators now expect to see.
Table of Contents
TL;DR
- Vishing attacks surged 442% in H2 2024 and now account for more than 60% of phishing-related incident response engagements targeting financial institutions
- NYDFS issued a vishing-specific advisory on February 6, 2026 — the first US financial regulator to issue threat-specific guidance — requiring identity verification procedures, training, and access management reviews
- Scattered Spider confirmed targeting of US financial institution IT help desks using MFA push bombing, SIM swapping, and help desk impersonation; CISA and FBI issued an updated joint advisory in July 2025
- AI voice cloning now requires only 3 seconds of audio to replicate a specific person’s voice with 85% accuracy — every executive earnings call and conference keynote is potential training data
Three months before NYDFS issued its February 2026 vishing advisory, a US bank experienced exactly the attack the advisory describes. An attacker called the bank’s IT help desk, identified himself as a branch operations manager, explained he’d been locked out during a system rollout, and provided enough correct account details — full name, employee ID, last four of SSN — to pass the standard verification questions. The help desk reset his MFA, creating a valid access window. The attacker had obtained all the verification information from a previous data breach.
By the time the real employee tried to log in and flagged the lockout, the attacker had been inside for two hours.
This is Scattered Spider’s playbook. And it works because help desks are specifically designed to solve the problem of employees who can’t access their accounts — which is precisely the social condition attackers fabricate.
The Threat Landscape: Why Vishing Surged and Why Help Desks Are the Target
Vishing attacks surged 442% in H2 2024 compared to the first half of the year and now account for more than 60% of phishing-related incident response engagements. That number is being driven by two compounding factors: AI voice cloning tools that can replicate a specific person’s voice from three seconds of publicly available audio, and the same organized criminal groups — notably Scattered Spider — applying systematic help desk social engineering across financial institutions and other high-value targets.
AI voice cloning changes the threat in a specific way. Before, vishing attacks relied on the attacker’s own voice and social skills. Now, an attacker can use audio from an executive’s earnings call, conference presentation, or media appearance to construct a convincing impersonation. The 45% of financial services organizations that experienced AI-powered cyberattacks in the 12 months leading into mid-2025 are dealing with a threat that was not realistic 24 months earlier.
The help desk is the preferred entry point because it has the right combination of access privileges and social pressure. Help desk staff are trained to be helpful to employees in distress. They receive calls from stressed users who’ve forgotten passwords, triggered lockouts, and gotten stuck during system upgrades. An attacker who can simulate that scenario convincingly — with enough verification data to pass standard questions — faces a counterparty whose professional instinct is to help.
The FBI and CISA documented this dynamic explicitly in their July 2025 joint advisory on Scattered Spider. Scattered Spider actors impersonate employees or IT staff, deploy push bombing to exhaust MFA fatigue, conduct SIM swaps to intercept SMS codes, and use the resulting access to move laterally into sensitive infrastructure. The MGM International, Caesars Entertainment, and Okta attacks all used variants of this same sequence. Financial institutions are confirmed targets.
What NYDFS Is Now Requiring
The NYDFS Cybersecurity Advisory issued February 6, 2026 is the first threat-specific vishing advisory from a US financial regulator. It described an “ongoing cyberthreat campaign involving vishing” where threat actors pose as IT help desk staff to steal login credentials and gain unauthorized access to information systems.
DFS-regulated entities received three specific requirements:
1. Identity verification procedures for credential resets. Entities must implement procedures for personnel to confirm the identity of individuals requesting credential resets, remote access, or other activity associated with information system access — specifically, procedures that do not rely on Caller ID. Caller ID spoofing is trivial; the verification system cannot depend on it.
2. Employee training on vishing tactics. Personnel must be trained on social engineering tactics including the specific technique of threat actors impersonating IT help desk staff and service providers. Generic cybersecurity training that covers email phishing without addressing voice-based impersonation does not satisfy this requirement.
3. Access management reviews. Entities must regularly review access permissions to confirm that account access is limited to what is necessary and appropriate for job functions. The purpose is reducing the damage radius when a credential compromise does occur.
Additionally, the advisory specified that vishing attempts that result in unauthorized access must be reported to DFS under 23 NYCRR Section 500.17 and to the FBI’s Internet Crime Complaint Center at ic3.gov.
For DFS-regulated entities that haven’t yet updated their authentication procedures to reflect this advisory, that gap is now documentable and examiner-visible. Part 500 Phase 3 compliance — which became effective in November 2025 — already requires universal MFA and privileged access management; the February advisory layer-adds specific procedural requirements for help desk authentication.
The Authentication Control Framework
The controls NYDFS is requiring — and that FFIEC’s 2021 Authentication and Access Guidance implicitly supports — break into three layers:
Layer 1: Pre-Call Procedures (Before the Verification Conversation Happens)
The most effective deterrent is having an established protocol that help desk staff know, trust, and are empowered to follow — even when a caller is insistent or creates urgency.
Challenge-Response Protocol. Every help desk request involving credential reset, MFA change, or account recovery should follow a documented challenge-response procedure. The procedure should specify:
- What questions are asked and in what order
- What answers are acceptable versus require escalation
- What happens when a caller cannot satisfy the verification — specifically, that access is not granted
Pre-Registered Out-of-Band Callback. For high-privilege users and requests involving administrative credentials, implement a callback requirement using a number pre-registered in the HR or directory system — not the number the caller provides. The callback must happen on that number before any credential action is taken. This breaks the Scattered Spider playbook: the attacker can provide correct verbal answers, but they cannot receive a callback on the actual employee’s registered number.
Code Word Protocol for Sensitive Requests. For executives, technical administrators, and employees with privileged access, a rotating shared code word provides an additional verification layer. The code word is known to the employee and the help desk supervisor — but not included in any publicly accessible record. An attacker impersonating an executive cannot provide a code word they’ve never been told.
Layer 2: MFA Hardening
Push-notification MFA is vulnerable to the specific attacks Scattered Spider deploys — push bombing and social engineering an employee into approving a malicious push. The FFIEC 2021 guidance recommended phishing-resistant MFA. In the vishing context, this means:
FIDO2 / Hardware Security Keys. FIDO2 authentication binds the credential to the physical device and requires presence verification. An attacker who socially engineers a password reset still cannot access the account without the physical hardware token. This is the most effective MFA approach against vishing-based credential attacks.
Disable SMS OTP for Administrative Resets. SIM swap attacks — where an attacker convinces a carrier to move a victim’s phone number to an attacker-controlled SIM — allow interception of SMS OTP codes. For any help desk process involving credential reset or MFA recovery, SMS OTP should not be an option.
Authenticator App with Number Matching. For organizations not yet on FIDO2, number matching (where the MFA push shows a code the employee must match against what’s displayed on their login screen) significantly reduces push bombing effectiveness. It is not as strong as FIDO2 but substantially better than standard push approval.
Layer 3: Detection and Response Triggers
Even well-designed authentication controls will occasionally fail. The detection layer captures that failure before significant damage occurs.
| Signal | Detection Action | Owner |
|---|---|---|
| MFA reset for high-privilege account | Immediate notification to account owner and security team | SIEM / Security Ops |
| Multiple failed verification attempts before a successful reset | Flag for security review within 24 hours | Help Desk / Security |
| Account access from new device or location immediately post-reset | Require re-verification, alert security | Identity Platform |
| Password reset request immediately followed by privileged action | Automated session hold, manual review | Security Ops |
When Vishing Succeeds: The Incident Response Timeline
If a vishing-based credential compromise is discovered, the response sequence matters.
Immediate (0-2 hours):
- Disable the compromised credential and all associated active sessions
- Preserve any call recordings from the time window of the attack — these are primary evidence
- Document the caller’s phone number, the caller ID displayed, and any URLs they directed staff to
- Initiate a forensic review of all actions taken on the compromised account since access was granted
Within 24 hours:
- Notify the affected employee and begin HR coordination
- Determine the scope of access: what systems the compromised credential could reach, what data it could access, what actions were taken
- Assess whether a NYDFS 500.17 notification or FFIEC 36-hour notification is triggered based on whether nonpublic information was accessed or the institution’s normal operations were affected
Within 72 hours (if unauthorized access confirmed):
- DFS-regulated entities: submit incident report under 23 NYCRR Section 500.17
- FFIEC-regulated institutions: assess whether the 36-hour computer security incident notification rule is triggered
- File with the FBI’s IC3 at ic3.gov — include the phone number, caller ID, and any other attacker identifiers
Post-Incident:
- Complete a root cause analysis: which verification control failed and why
- Update the help desk authentication procedure if the incident exposed a gap
- Provide targeted training to help desk staff involved
- Document what the attacker knew that allowed them to pass verification — and assess whether that information is still at risk in other accounts
For the broader framework on managing cybersecurity incidents through notification and reporting, see Ransomware Incident Response Playbook and Account Takeover Incident Response.
What Examiners Will Ask
The NYDFS February 2026 advisory is dated and documented. For DFS-regulated entities, examiners will ask what the institution did in response to it. The answers they’re looking for:
- Written, documented challenge-response procedure for help desk credential resets that does not rely on Caller ID
- Evidence of employee training on vishing tactics — specifically the help desk impersonation technique — delivered after February 2026
- Access permission review showing accounts are scoped to job function (documented output, not just a policy statement)
- MFA configuration records showing phishing-resistant MFA is in place or a documented timeline for implementation
- Part 500 Phase 3 compliance on MFA coverage — reviewed against the NYDFS Part 500 Phase 3 analysis
For FFIEC-regulated institutions not covered by Part 500, the 2021 Authentication and Access Guidance is the benchmark — and the Scattered Spider advisory from CISA and FBI creates a parallel documented obligation to assess and respond.
So What?
The February 6, 2026 NYDFS advisory created a dated, documented regulatory expectation: DFS-regulated entities must have procedures for verifying help desk callers that don’t rely on Caller ID.
For deepfake-adjacent content, see the Deepfake Voice Cloning Fraud playbook — which covers the scenario where vishing is combined with voice synthesis to impersonate executives in wire transfer fraud. The authentication controls are the same; the downstream damage is larger.
The threat is not hypothetical. Scattered Spider targeted a US bank’s help desk. NYDFS documented it as an active campaign. The controls required aren’t new technology — they’re procedures, training, and MFA configuration. The gap is in whether those procedures are written down, trained to, and enforced before the next call.
Ready to build or stress-test your incident response program? The Incident Response & Breach Notification Kit includes response playbooks, state breach notification requirements for all 50 states, and tabletop exercise scenarios — including social engineering scenarios designed for the help desk authentication failure pattern.
Sources:
- NYDFS Cybersecurity Advisory: Targeted Vishing Attacks (February 6, 2026) — New York Department of Financial Services
- CISA and Partners Release Updated Advisory on Scattered Spider (July 29, 2025) — CISA
- Authentication and Access to Financial Institution Services and Systems: Interagency Guidance (2021) — FFIEC
- AI-Powered Social Engineering in Financial Services: 2026 CISO Guide — Arsen
- Social Engineering Risk Report for Financial Services 2026 — Arsen
◆ Need the working template?
Start with the source guide.
These answer-first guides summarize the required fields, evidence, and implementation steps behind the templates practitioners search for.
◆ Related template
Incident Response & Breach Notification Kit
Step-by-step incident response playbooks and breach notification templates for all 50 states.
◆ Immaterial Findings · Weekly
Sharp risk & compliance insights. No fluff.
◆ FAQ
Frequently asked questions.
What is vishing and how is it different from phishing?
What did the NYDFS February 2026 vishing advisory require?
What is Scattered Spider and why are they targeting help desks?
How should incident response for a successful vishing attack differ from a standard credential compromise?
What authentication controls are most effective against help desk vishing attacks?
Do FFIEC authentication guidelines address vishing specifically?
Author
Rebecca Leung
Rebecca Leung has 8+ years of risk and compliance experience across first and second line roles at commercial banks, asset managers, and fintechs. Former management consultant advising financial institutions on risk strategy. Founder of RiskTemplates.
◆ Related framework
Incident Response & Breach Notification Kit
Step-by-step incident response playbooks and breach notification templates for all 50 states.
◆ Keep reading
Related posts.
Incident Response
Incident Response Decision Log: Document Why a Notification Clock Did—or Did Not—Start
When a cyber event hits, every regulator wants the same thing: proof you made a good-faith materiality determination without unreasonable delay. Here's the decision log structure that creates that proof—whether the clock started or not.
Jul 24, 2026
Incident Response
Four Months Late: What the NYDFS Healthplex $2M Penalty Says About When the Notification Clock Actually Starts
NYDFS fined Healthplex $2 million in August 2025 for notifying 4+ months after a breach. The failure wasn't forensics — it was a misunderstanding of when the 72-hour clock starts. The same mistake trips up banks under the FDIC's 36-hour rule.
Jul 23, 2026
Incident Response
Three Clocks, One Incident: How to Manage the Overlapping Cyber Notification Timelines Under OCC, NYDFS, and SEC Rules
When a cyber incident hits, you're not managing one notification obligation — you're managing six, with different triggers, different recipients, and different clocks. The OCC's 36-hour rule, NYDFS's 72-hour requirement, the SEC's 4-business-day materiality window, GLBA customer notices, FinCEN SAR filing, and bank partner contractual obligations all run simultaneously. Here's how to track them without missing one.
Jul 18, 2026