Your Help Desk Is an Authentication Endpoint and It Has No MFA

Every organisation with a mature identity programme can tell you the strength of its login: phishing-resistant MFA, conditional access, device compliance, session limits. Almost none can tell you the strength of its reset.

That gap is not theoretical. In Google Cloud’s Threat Horizons H1 2026 report, 17% of observed cases involved voice-based social engineering — vishing — in the platform-agnostic initial access trends. The report names the mechanics directly: the financially-motivated group UNC3944 impersonated employees to trick IT help desk staff into resetting credentials and multi-factor authentication. A separate group, UNC6040, ran the same play from the other direction, using persistent vishing to impersonate help desk staff and convince employees to authorise a legitimate tool — Salesforce Data Loader — which it then used to extract large volumes of data through bulk API operations.

Note what is not happening in either case. No exploit. No credential stuffing. No MFA bypass in the cryptographic sense. The attacker asked a human being to issue a valid credential, and the human being did.

An account is only as strong as its weakest issuance path

Here is the structural point, and it is worth stating plainly because most identity architecture diagrams do not contain it.

An account’s real authentication strength is not the strength of its login. It is the minimum of two numbers: the strength of the login path, and the strength of every path that can replace the login. Password reset, MFA re-enrolment, recovery-email change, new device registration, break-glass access — each of these is a way to obtain valid credentials without possessing the old ones. Each is, functionally, an authentication endpoint.

Now compare how the two categories are governed.

The login endpoint is rate-limited, logged in a SIEM, monitored for impossible travel, protected by hardware-backed factors, and subject to conditional access policy. The reset endpoint is a person on a phone, working from a script, measured on ticket resolution time, with a strong professional instinct to be helpful to a colleague who says they are locked out and late for a client call.

Both endpoints issue the same credential. Only one of them is instrumented.

This is why “we deployed phishing-resistant MFA” has stopped being a sufficient answer. FIDO2 makes the front door extremely expensive to attack. It does nothing about a process that hands out new keys on request — and attacker economics respond to that immediately. When the cheapest route to a valid session runs through a service desk queue, that is the route.

Why knowledge-based verification is already defeated

Most help desk verification still rests on knowledge: employee ID, manager’s name, date of birth, last four digits, department, start date.

Every one of those facts is either published on a corporate directory page, inferable from LinkedIn, or sitting in a breach corpus. Knowledge-based verification assumes the attacker does not know things about the employee. In 2026 that assumption has no basis. The attacker frequently knows more verifiable detail than the genuine employee can recall under pressure — which produces the perverse outcome that a well-prepared impersonator passes verification more smoothly than the real person.

Worse, the failure is silent. A successful impersonation closes as a normal ticket with a normal resolution time. There is no alert, no anomaly, no failed-attempt counter. The control does not fail loudly; it succeeds at the wrong thing and reports success.

Impact assessment

Risk rating: High. The affected surface is every organisation operating a service desk with credential or MFA reset authority — which is essentially all of them above a few hundred seats.

• Blast radius follows the account, not the help desk. A single successful reset against a privileged or federated identity yields an authenticated session that then passes every downstream control legitimately. SSO amplifies this: one reset can traverse dozens of SaaS applications.
• Detection lag is measured in days, not minutes. Because the resulting session is genuinely valid, standard identity detections stay quiet. Discovery typically comes from the impersonated employee noticing their own access broke, or from data-exfiltration volume downstream.
• The UNC6040 pattern shows the exfiltration does not need malware. Bulk API operations through an authorised, legitimate data tool produce traffic that looks like an integration doing its job.
• Regulated sectors carry additional exposure, since a reset that bypasses documented identity-proofing may itself constitute a control failure independent of any resulting breach.

The CloudShieldSecure perspective

Most tooling in this space treats identity events as configuration facts — who holds which entitlement, which policy applies. That view cannot see today’s problem, because after a malicious reset every configuration fact is correct. The entitlement is legitimate. The policy applied. The MFA is enrolled. It is simply enrolled to the wrong person.

What makes the difference is treating credential issuance as a monitored event class in its own right, not as an administrative side effect. In CloudShieldSecure we surface reset and re-enrolment activity alongside the entitlement it unlocks — so an MFA re-enrolment on an account holding production or administrative access is not a tier-1 ticket that closed cleanly, it is a high-signal event correlated with what that account can subsequently reach. The question the platform is built to answer is not “is this identity configured correctly” but “did the authority this identity holds change hands, and does anything downstream reflect that.”

That framing matters because the remediation is cheap and the detection is where the difficulty sits. Nobody needs convincing that help desk resets are risky. What they lack is a signal that distinguishes the four hundred routine resets from the one that mattered.

Recommended actions

A practical sequence, ordered by effect per unit of effort.

1. Make the reset insufficient on its own. This is the single highest-value control and it is the one Google’s own guidance emphasises: bind access to device posture so that even when a password is reset through a help desk request, access is denied unless the device meets health, security posture, and location compliance requirements. An attacker who wins the phone call still holds nothing usable.
2. Replace knowledge-based verification with something the breach corpus cannot supply. Google’s recommendation is explicit — require visual verification by video call, or secondary manager approval, for identity-sensitive requests. Verified digital credentials work equally well. The test to apply is simple: could someone who has read every public and breached fact about this employee pass this check? If yes, it is not verification.
3. Treat MFA re-enrolment and device registration as high-risk events, not routine ones. Require out-of-band confirmation through a channel already registered to the account, rather than the channel the caller is currently using.
4. Route high-risk resets to a narrow, trained queue. Privileged, executive, and service-account resets should not be actionable by any tier-1 agent. Concentrating the authority concentrates the training.
5. Log the verification, not just the reset. Record ticket ID, agent ID, verification method used, and approval path. Without the method field you cannot audit the control at all — you can only confirm that resets happened.
6. Add a mandatory delay or callback for out-of-hours and high-privilege requests. Vishing pressure depends on urgency. A documented waiting period removes the attacker’s main lever at almost no cost to legitimate users.
7. Run the exercise from the attacker’s side. Social-engineering testing against your own service desk is the only way to learn whether the written policy survives a confident caller at 4:50pm on a Friday.

A note on the figures in this analysis

One statistic that appears in secondary coverage of this report has been deliberately excluded here. The primary document attributes the same 2.9% H1 2025 baseline both to third-party software-based entry reaching 44.5% and to remote code execution reaching 13.6% — two different growth claims from one baseline figure. The share values are reported as published; the growth framing built on that baseline is not reproduced, because the source is not internally consistent on it.

Similarly, a widely circulated figure putting service desk bypass at the top of organisational risk rankings has been omitted, as the underlying study could not be verified against a primary document at the time of writing.

Reporting a number you cannot reconcile is how a good analysis becomes a bad citation three articles downstream.

Sources and references

• Google Cloud — Cloud Threat Horizons Report H1 2026 — primary source for the 17% vishing share, the 12% email phishing share, UNC3944 and UNC6040 activity, and the help desk verification and device-posture recommendations
• Google Cloud / Mandiant — UNC6040 Proactive Hardening Recommendations — detailed hardening, detection and logging guidance for SaaS application compromise
• Google Cloud — Cloud Threat Horizons Report H2 2025 — prior-period baseline for initial access vector trends

CloudShieldSecure is built by CloudKonsult Limited. Learn more at cloudshieldsecure.cloudkonsult.cloud.