The Phone Call Your Help Desk Will Answer

Your phishing simulation ran last quarter. Forty percent of staff clicked the link, twelve percent entered credentials, and you sent the clickers to mandatory awareness training. The security awareness metrics look defensible.

Nobody called your help desk.

Vishing is voice phishing: social engineering conducted over the phone rather than through email. It works differently from email-based attacks, it reaches different targets, and it consistently delivers some of the most consequential access in a security assessment. Most social engineering testing programs measure click rates and credential submissions. They do not include a phone.

Why Vishing Is a Different Threat Model

Email phishing relies on volume and urgency. A convincing message sent to ten thousand recipients will succeed against some fraction of them. Vishing is targeted and interactive. The attacker has a conversation, adjusts in real time to what the target says, and exploits human instincts that email cannot reach: the discomfort of leaving someone on hold, the authority of someone who sounds like they know what they are talking about, the helpfulness that customer service culture instills in people who answer phones professionally.

An email can be deleted. A phone call puts a real person under social pressure in real time. People who would never click an attachment will reset a password for someone who sounds appropriately urgent and technically credible.

The help desk is the canonical target because it exists to help people, which means its success metric is being helpful. An operator who hangs up on callers gets flagged in quality reviews. An operator who resets a password for someone who cannot log in is doing their job. Building a security culture that overrides that instinct requires deliberate work that most organizations have not done.

What a Vishing Scenario Looks Like

The most reliable scenarios in assessments follow a structure: establish credibility, create urgency, make a small request.

An attacker calls your IT help desk, identifies themselves as a senior director whose name appears in a company directory or on LinkedIn, and says they are locked out of their account before an urgent board call. They know the director's manager's name. They know what meeting software the company uses. They ask for a temporary password and promise to reset it immediately after the call. The operator, who has been trained to be helpful and has a queue of tickets to close, helps them.

The variations are endless. The basic shape is consistent: a caller with plausible context, a legitimate-sounding need, and enough specific detail to clear the verification bar the organization actually operates at under real conditions.

That last phrase is the important one. The verification bar documented in your policies is not the same as the bar your help desk actually uses under call volume pressure. The gap between those two things is where vishing lives.

What the Assessment Actually Tests

A vishing assessment is not a technical test. It is a measurement of your people, your processes, and how they hold up under realistic adversarial conditions.

The questions it answers: What does your help desk actually do when it cannot verify a caller's identity through normal channels? What alternative verification methods are in use, and are they consistent across operators? What information will staff confirm over the phone to a caller who sounds credible? How does call volume affect verification compliance? Is there a pathway to reset credentials or grant access without a ticket trace?

Organizations that have never run a vishing assessment are often surprised by what their help desk does by default. Not because the operators are negligent, but because the default behavior in a helpdesk-culture environment is to solve the problem the caller presents. Nobody trained them on what to do when the verification path fails.

The Scope Most Programs Miss

Email phishing testing has a vendor ecosystem. Tools exist to run simulations at scale, track results, and feed failures into training programs. The infrastructure is built out and the methodology is understood.

Vishing testing exists as a component of full social engineering assessments, which are typically run less frequently than phishing simulations and scoped for specific targets rather than broad organizational measurement. As a result, most organizations have years of click rate data and no baseline at all for how their help desk performs against a caller who should not have access.

The targets extend beyond the help desk. Any function that takes incoming calls and has access to sensitive information or systems - payroll, accounts payable, executive assistants, HR - is within scope for an adversary running a pretexting campaign. Business email compromise often begins with a phone call to verify the CEO's travel schedule before moving to a fraudulent wire transfer request. The call is the reconnaissance phase. Most organizations are not testing it.

What Good Controls Look Like

A help desk that performs well against vishing is not one staffed by suspicious people. It is one with clear process behind it.

A defined escalation path for calls where standard verification fails, rather than a default action of resetting the credential anyway. Documented alternatives to password reset requests made over the phone that do not require in-person verification. Call recording and ticket logging requirements that make unapproved verification bypasses visible in audit review. Regular tabletop exercises on social engineering scenarios, distinct from awareness training that focuses on email.

The technical controls do not help much here. Multi-factor authentication complicates post-access attacks. It does not prevent a help desk operator from resetting a password for someone who called in with a convincing story, at which point the attacker sets up their own MFA enrollment and proceeds from there.

Running the Assessment

A vishing assessment requires explicit scoping and authorization against defined targets. The assessment should cover your help desk and at least one or two other high-value phone targets. Callers should attempt several distinct scenarios, testing different pretexts and verification bypass approaches. Results should be documented at the scenario level, not just as an aggregate pass/fail.

The results are not a performance review of the operators who answered. They are a measurement of the process. When operators fail the test, it is usually because the process either did not tell them what to do when verification fails, or gave them implicit incentives - call closure metrics, helpfulness culture - to solve the problem rather than reject the caller.

One assessment is not the goal. The goal is a remediation plan built from the findings. That plan looks like process documentation, escalation procedures, and role-specific training for people who answer sensitive calls. Not more phishing simulation hours. The phone is a different attack surface and it needs different defenses.