Most vishing defenses assume the attacker is after a password. The campaigns causing the most damage in 2026 rarely ask for one. Instead, they persuade a help desk representative to enroll a new phone number or convince a user to approve a connected application. The login that follows appears legitimate because, in the narrow technical sense, it is. Today’s most effective vishing tactics bypass authentication rather than attack it directly.

That shift changes what enterprises need to defend. The question is no longer whether someone can purchase or steal a credential. It is whether support processes and recovery workflows can be manipulated into doing the attacker’s work.

What the 2025 and 2026 data shows about vishing

Voice phishing stopped being a fringe tactic sometime over the past two years. Mandiant’s M-Trends 2026 reported that highly interactive voice phishing accounted for 11% of observed initial infection vectors in 2025, making it the second most common vector in its dataset.

Google Cloud’s Cloud Threat Horizons Report H1 2026 found voice-based social engineering in 17% of the cloud incidents it examined. These are incident response statistics rather than a census of every intrusion, so they should be viewed as directional rather than representative of market share. Even so, the trend is consistent across vendors. CrowdStrike, Microsoft, Palo Alto Networks’ Unit 42, and the Federal Bureau of Investigation (FBI) all describe live-operator phone attacks as an established path into enterprise environments rather than an emerging threat.

What has changed is not only the frequency of these attacks. It is also where the phone call lands. Attackers no longer call to steal a password. They call to manipulate the workflow that grants access in the first place.

Vishing targets the broader identity workflow, not just passwords

One of the clearest public examples comes from the FBI’s September 2025 Advisory on the criminal groups ShinyHunters and Scattered Spider. Threat actors called Salesforce users, walked them through approving a malicious connected application, often a modified version of Salesforce’s own Data Loader, and allowed the platform to issue OAuth tokens to that application. Once granted, much of the traditional security stack had nothing to detect. The authorization was legitimate because the user approved it.

Google’s Threat Intelligence Group traced what happened next. In The Cost of a Call, it documented operators using compromised Salesforce credentials to pivot into other platforms, including Okta and Microsoft 365, before timing their extortion attempts against the victim. A phone call became a foothold, and that foothold enabled lateral movement across the environment.

The same pattern appears even when no SaaS application is involved. Microsoft’s incident responders described a November 2025 intrusion in which attackers repeatedly placed Microsoft Teams calls while posing as support personnel until a user launched Quick Assist, giving them remote control of the device. Mandiant has also reported successful red team exercises in which service desks were convinced to reset credentials or modify multi-factor authentication (MFA) settings. In other words, the help desk has become part of the attack surface.

Palo Alto Networks Unit 42 provides additional context. Its 2025 Incident Response Report found that social engineering initiated 36% of all investigations. More than one-third of those cases involved techniques other than email phishing, including direct manipulation of help desk personnel. These incidents resulted in data exposure 60% of the time, well above the overall baseline. The common thread is clear. Human-operated identity workflows have become a primary access surface, and the phone remains one of the most effective ways to reach them.

What MFA protects and what it doesn’t

MFA is designed to render stolen passwords ineffective, and for credential stuffing and traditional phishing attacks, it largely succeeds.

The challenge is that most MFA methods are not resistant to social engineering. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63B defines phishing resistance as preventing authentication secrets and valid authenticator outputs from being disclosed to an impostor verifier without relying on the user to recognize the attack. Many common MFA methods fail that definition as soon as a user can be persuaded to facilitate a login or recovery process. Reading a one-time passcode over the phone defeats the factor without technically breaking it. The same applies when a user approves a push notification under pressure or when a convincing caller persuades a help desk representative to reset MFA.

Salesforce acknowledged this reality in its post-compromise guidance, noting that push notifications, SMS codes, and authenticator apps can all be bypassed when users are manipulated into assisting an attacker. The U.S. General Services Administration’s Phishing-Resistant Authenticator Playbook goes one step further by recommending that agencies eliminate phishable methods entirely, including from backup and recovery workflows, not just primary authentication.

Recovery is where many security programs underestimate their exposure. An enterprise may deploy phishing-resistant authentication at the front door while leaving a phishable recovery path wide open behind it. If an attacker can call the help desk, claim a lost device, and re-enroll a weaker authentication factor, the strength of the primary authenticator becomes irrelevant. The true measure of phishing resistance is whether enrollment and recovery processes can also withstand social engineering.

A defense playbook for 2026 vishing tactics

None of this suggests that MFA is no longer essential. It simply means MFA alone is not enough. Organizations must also secure the workflows that surround authentication.

Make both primary and recovery authentication phishing resistant. Deploy phishing-resistant methods such as passkeys or hardware security keys. Then audit every recovery and re-enrollment workflow to ensure it cannot fall back to SMS, voice calls, or knowledge-based authentication. Recovery is often where otherwise phishing-resistant deployments remain vulnerable.

Rebuild help desk verification around evidence a caller cannot simply recite. Replace knowledge-based questions with out-of-band verification tied to a trusted device, manager approval, or another independently verified channel. Require additional controls for high-risk actions such as MFA resets or new device enrollment. Personal information has become inexpensive to obtain and can no longer serve as reliable proof of identity.

Treat OAuth and connected application approvals as privileged actions. Limit who can authorize third-party applications, require review before new connected applications are approved, and continuously monitor token grants. Once authorized, an application can access and exfiltrate data without requiring another password.

Constrain where and how sessions can be used. Bind sessions to managed devices or trusted networks, shorten session lifetimes for privileged users, and require re-authentication when risk conditions change. These controls limit the usefulness of stolen session tokens.

Monitor behavior after authentication, not just during it. Deploy identity threat detection and risk mitigation capabilities that identify accounts behaving abnormally after successful authentication. Examples include large-scale data exports, unusual privilege use, impossible travel, or access from unfamiliar devices. Identity-based attacks are particularly damaging because they often appear legitimate at login, leaving little opportunity for traditional authentication controls to detect them.

Conclusion

Most of this playbook must operate in real time, correlating signals that are often scattered across separate security teams and disconnected systems. Many organizations lack the visibility needed to assemble that complete picture.

ID Dataweb addresses this challenge through identity threat detection and risk mitigation. The ID Dataweb platform continuously evaluates identity risk signals, including telecom intelligence that detects ported or recycled phone numbers, device and network reputation, behavioral analytics, velocity patterns, and credential intelligence. Those signals are combined into a comprehensive risk assessment for every identity interaction.

That assessment drives adaptive identity verification. Low-risk interactions proceed without unnecessary friction, while higher-risk requests trigger step-up verification that matches the level of risk. Depending on the situation, that may include possession verification, biometric authentication, or document and liveness verification rather than applying the same challenge to every user. Organizations can configure their own risk thresholds through a no-code policy engine and apply those assessments consistently across the entire identity lifecycle, including onboarding, login, password resets, call center verification, and high-risk transactions.