The help desk is the perimeter: what October's vishing cases say about verifying callers

A help desk that can reset a password or an MFA method can issue a working credential for any account in the company, so it belongs inside the security boundary and should be held to the same standard as the identity provider. In October 2026 three companies disclosed breaches that began with people being persuaded over the phone or by impersonation, and none involved a software flaw. The fix is the same in both: verify a caller with something an attacker cannot look up or say, and treat every reset as the security event it is.

Key takeaways

• An MFA reset is credential issuance. Whoever approves it holds the keys to every account they can reset.
• Knowledge checks fail because the answers are for sale. Verification has to rest on a channel or device the organization already controls.
• A displayed caller name, including India's new network-asserted CNAP, identifies a SIM registration. It cannot tell you who is speaking.
• Every reset should be logged and correlated with the sign-in that follows it, because that pairing is the clearest signal of a successful attack.
• The passkey migration will raise recovery volume, and attackers are already using it as a pretext.

What October added to the record

ASOS. The UK retailer told BleepingComputer on October 8 that "an unauthorised party gained access to an ASOS employee account by impersonating a trusted contact" to obtain login credentials, then used them on certain third-party platforms, which ASOS said may have exposed customer names and contact details. ASOS said payment cards and account passwords were not accessed. Our news post has the timeline.

Dexcom. The glucose monitor maker said in an October 10 statement that "targeted vishing events" led to unauthorized access to limited information in certain internal documents, with no impact on its products or operations. Dexcom has not said who was called or what they were asked to do. By October 18 at least three proposed class actions had been filed against it in federal court in San Diego, Top Class Actions reported, one of them citing a ShinyHunters claim of responsibility that Dexcom has not confirmed. See our coverage.

CSX. The US freight railroad began mailing breach notices on October 20. Its filing with the New Hampshire attorney general traces unusual activity in an employee's account to the employee responding to a vishing call on May 29, 2026, after which an outsider took files from its Microsoft 365 environment until June 9. Some files held names, Social Security numbers, driver's license numbers and bank details. The gap matters as much as the call: almost five months passed between the call and the letters.

The longer pattern. These follow a summer in which ShinyHunters reached McKesson by calling employees while posing as IT, then used their Okta credentials and SSO session to reach Salesforce and Snowflake, and RingCentral by voice-phishing one employee's password. CISA's Scattered Spider advisory has described both versions since 2023: posing as IT or help desk staff to get credentials and one-time codes from employees, and calling help desks to "convince IT help desk personnel to reset passwords and/or transfer MFA tokens."

The attack runs in both directions, so defend both: verify callers who claim to be employees, and tell employees in advance how IT will and will not contact them.

A reset is an issuance

Our help desk social engineering brief puts the failed assumption precisely: help desks verify facts about an employee, while the real question is whether the caller controls something only the employee has. Name, employee ID, manager and start date are all available from a profile, a previous breach or a short phishing exchange. The McKesson data, as our follow-up noted, contained dates of birth, addresses, phone numbers and employers, which is a ready-made answer sheet for the next round of calls.

Once a reset goes through, phishing-resistant MFA, conditional access and device checks all accept the new credential, because the organization issued it.

A verification ladder

Match the strength of the check to what the request can open. Clearing a lockout can tolerate less than a request that creates a new way in.

Two rules sit across the whole ladder. A help desk agent should never read a code to a caller or ask a caller to read one back. And the agent should be able to refuse a reset without escalation risk to themselves. A process that punishes caution will lose to a caller who sounds senior and annoyed.

What caller ID can and cannot tell you

India's Department of Telecommunications has ordered all access providers to switch on Calling Name Presentation on 4G and later networks from November 1, 2026. Unless the recipient has saved the number, the phone will show the name from the originating operator's subscriber record, or a verified trade name for business callers (our news post).

That should make cold calls posing as a bank or the police harder. For a help desk it changes little. The displayed name says who registered the SIM. It says nothing about who is holding the phone, it does not yet cover 2G, 3G or fixed lines, and it does not apply to calls placed through internet messaging apps. If the caller's own phone is lost, stolen or SIM-swapped, the name on screen will be exactly right and the person will be wrong. Keep the displayed name out of the verification decision, here and in every other country.

The passkey migration will test this

Microsoft Entra ID made passkeys the default on September 1, 2026. According to Microsoft's retirement guide, from February 1, 2027 most users whose only method is Microsoft-delivered SMS or voice will hit a blocking prompt to register a passkey (our SMS off-ramp plan covers the migration). Organizations moving off SMS on that timeline should expect more calls about new phones, lost devices and failed registrations, which is exactly the traffic a social engineer hides in.

Attackers are already using the migration as cover. Microsoft described a campaign, active since May 2026, in which callers posing as IT told employees to update their passkey or MFA settings, sent a link to a fake sign-in page, and then registered their own authentication method for persistence. The FIDO Passkey Index 2026 analysis covers the rollout side; the help desk side is to publish, before the first migration email goes out, the exact ways IT will contact staff and the ways it never will.

Recovery is also where a passkey program keeps or loses its value. If losing a passkey can be fixed by a phone call that asks for an employee ID, the organization has phishing-resistant sign-in in front of a phishable reset. Make the "all factors lost" path the hardest one on the ladder, and make it rare by registering at least two passkeys or a passkey plus a hardware key for each person.

What to measure

• Resets followed by a new-device sign-in within an hour. The most useful correlation, tracked through ITDR or your SIEM.
• Resets per agent and per pretext. A cluster of "new phone, urgent" calls across several employees in a day is a campaign.
• Verification method used. If the ticket says "verified by employee ID," the control failed even if the caller was genuine.
• Time to report. How long it takes an employee who received a suspicious "IT" call to tell security. Our identity habits post has a version for non-security teams.

The agents who take these calls see the weakest point in the program every day, which is also why the help desk is a good place to start a career in IAM.

Related reading

• Help desk social engineering and OTP relay social engineering
• Scattered Spider and the help desk
• Vishing, SIM swap and phishing-resistant MFA in the glossary
• MFA fatigue and push bombing