Help desk identity verification for MSPs: stop the breach before it starts

TL;DR

Your help desk is now the easiest way into your clients' environments. Not the firewall. Not the VPN. The person answering the phone who has the power to reset a password, issue a Temporary Access Passes (TAP), or enroll a new MFA device. Attackers figured this out before most MSPs did. The fix is not training your agents to spot better social engineers - it's building technical controls they can't override and a tiered verification system where the stakes of the request match the burden of the proof. Standard users get self-service or a simple callback. Admin accounts require live video and manager sign-off. MFA resets - the highest-value transaction on any help desk - require possession of an existing factor before a new one is enrolled. And once verification passes, the execution side (the actual password reset, session revocation, and ticket closure) should happen automatically, not through a tech who might be tired, rushed, or socially engineered themselves. That's where Rallied comes in.

Why the help desk became the primary attack vector

The MGM Resorts breach in September 2023 cost an estimated $100 million. The initial access vector wasn't a zero-day or a sophisticated exploit - it was a phone call. Scattered Spider, the threat actor group responsible, called the MGM help desk, posed as an employee, and convinced the agent to reset credentials or enroll a new MFA device. What followed was ransomware that shut down casino floors, hotel check-in systems, and online booking for days.

The same technique brought down Caesars Entertainment, which quietly paid a $15 million ransom to avoid the public embarrassment MGM suffered. And these are large enterprises with full security teams. MSPs serving SMB clients - with thinner staffing, less security investment, and more accounts to manage across dozens of clients - face the same attack surface with fewer resources to defend it.

The mechanics are simple. Help desk agents have legitimate access to reset passwords, enroll MFA devices, issue Temporary Access Passes, and grant remote access. That power is exactly what attackers need. And unlike attacking technical defenses, social engineering the help desk requires no technical skill - just a good pretext and a caller who sounds convincing.

According to Mandiant's M-Trends 2026, highly interactive voice phishing ranked as the second-most-common initial infection vector at 11% of compromises, exceeded only by vulnerability exploitation. For MSPs that manage dozens or hundreds of clients, each with their own help desk contact chain, the exposure compounds fast.

"The real issue is we can't train help desk staff fast enough to spot social engineers. The attackers are better at the job than our agents. We needed technical controls, not more training." - Healthcare MSP, r/msp

They're right. Training is not the answer. Technical controls are.

What attackers actually do (and why your current verification probably fails)

Before we get to the fix, it helps to understand exactly what you're defending against - because the attacks are more methodical than most people realize.

The reconnaissance phase

Attackers rarely call blind. They typically spend one to two days mapping the target organization before the actual attack:

• Calling with real employee IDs attached to wrong names to confirm the ID format
• Testing how far partial information gets before an agent asks for proof
• Calling at different hours to reach different agents and identify who's more permissive
• Using out-of-office replies as targeting lists - employees on leave can't contradict impersonation attempts

This reconnaissance phase creates no tickets and costs the attacker nothing. By the time the real call comes, they know the verification procedure, the format of employee IDs, and which shift answers the phone.

The two-call split attack

The most common pattern is the two-call split, which Mandiant documented in detail from real UNC3944 (Scattered Spider) compromises:

1. First call: Attacker claims to be an employee whose phone died while traveling. Verification relies on weak signals - partial SSN, employee ID, manager's name. MFA reset is approved.
2. Hang up. Call back later - different agent, different shift. Claim the phone is still unavailable. Request a password reset.
3. Result: Two independently defensible decisions by individual agents combine to produce full account takeover.

Each agent made a reasonable call on a single ticket. The ticketing system never correlated the two requests because they look unrelated. By the time the organization sees the pattern, the attacker has session tokens, mail forwarding rules configured, and 30+ minutes inside the environment.

The defense requires cross-ticket alerting: any MFA reset followed by a password reset on the same account within a short window should trigger an automatic security escalation, not close as two separate resolved tickets.

Static identity data is compromised

The verification methods most help desks use today were designed in a world where personal information was private. That world is gone.

Employee IDs, dates of birth, SSN last four digits, manager names, and home addresses are all available from data breaches, LinkedIn, public records, and simple OSINT. The U.S. Department of Health and Human Services sector alert on help desk attacks in healthcare documented attackers routinely providing the last four digits of SSNs and corporate ID numbers to pass verification - and they got those details from a five-minute web search.

Ask yourself honestly: if someone calls your help desk right now, says they're an executive locked out before an important meeting, and correctly recites their employee ID, manager's name, and date of birth - what actually stops your agent from resetting their access?

If the answer is "their judgment," you have a gap. And it's exploitable today.

AI voice cloning: the concern is real, but not where you think

A 2026 Harvard Kennedy School and Meta study tested AI voice phishing against 4,100 US adults. The finding most people miss: caller persuasiveness predicted compliance better than voice realism. Agents couldn't reliably distinguish synthetic speech - but that wasn't even the primary factor. A well-built pretext with a mediocre AI voice outperformed a flawless voice clone with a weak story.

Voice detection training is wasted effort. The defense is procedural, not perceptual.

This matters for how you build your verification system. Don't try to train agents to hear deepfakes. Build procedures that work regardless of how convincing the caller sounds.

What actually works: tiered identity verification

The fundamental principle is simple: the verification bar should match the risk of what's being requested. A frontline employee resetting their own email password is not the same risk as an admin account MFA re-enrollment. Treating them the same means either you're failing most users with unnecessary friction, or you're leaving high-value accounts underprotected. Usually both.

Here's how to tier it.

Tier 1: standard users

For frontline employees with no elevated access, the goal is to get them back to work fast while removing the human judgment call from the equation.

Best approach: self-service password reset (SSPR). Move routine password resets to a self-service flow entirely. Microsoft Entra ID's SSPR supports 20+ authentication methods and integrates with Conditional Access. Users with enrolled factors reset their own passwords without calling anyone. Social engineers can't call a self-service portal. Starting September 7, 2026, Entra SSPR requires pre-enrolled authentication methods - getting your clients' users enrolled before they need a reset is now a hard dependency.

When SSPR isn't available: Email OTP to a corporate email address, sourced from the directory (not provided by the caller). Not SMS - SIM swaps make SMS verification weak. Email from a corporate address is a meaningful signal because it requires the caller to control an account that's already authenticated.

For the help desk path (exceptions only): Callback to a registered phone number from the directory. The agent initiates the call. The agent looks up the number. The caller never provides the callback number.

Tier 2: elevated access

IT staff, team leads, and anyone with access to client-facing systems or sensitive data need a harder bar.

Required: Out-of-band verification (callback to registered number from directory, or email confirmation to a corporate address verified from directory). Plus manager notification - not approval, just notification. This creates an external record and a human who will notice if the reset was unauthorized.

Account history review before approval: Did this account have a reset recently? Has the same number been used across multiple accounts? Have there been multiple contacts from this account across different agents this week? Check the ticket history before clicking approve.

Session revocation: Password reset alone doesn't evict an attacker who already has valid session tokens. Revoke all active sessions and tokens in the same action, every time.

Tier 3: admins, executives, and privileged accounts

This is where the highest-value social engineering attempts land. The verification bar here needs to be hard enough that an attacker can't fake it on a phone call.

Required proof: Live video verification with a government-issued ID or corporate badge checked against an employee photo record. Not "describe what you look like." Actual camera, actual ID, actual comparison.

Required approval: Manager confirmation through a verified channel - sourced from the directory, not provided by the caller. The manager confirms via their own authenticated channel (email from their corporate address, or a callback to their registered number).

MFA resets specifically: NIST SP 800-63 Revision 4 requires that before a new MFA factor is enrolled, the requester must prove possession of an existing enrolled factor. If an attacker can't prove they control a current factor, they can't get a new one enrolled - full stop. For privileged accounts, require FIDO2 security keys (hardware keys that can't be phished) and restrict enrollment to compliant devices on trusted networks.

A useful rule of thumb from NHIMG guidance: MFA re-enrollment is the highest-value transaction on a help desk. An attacker who successfully registers their own MFA device converts a stolen moment into persistent access that survives password changes the legitimate user makes later - because now there are two valid MFA devices and the organization doesn't know which is real.

The cross-ticket alert layer (all tiers)

No verification system works without correlation. Configure automated alerts for:

• MFA reset followed by password reset on the same account within the same window
• Same phone number or authenticator registered across multiple accounts
• Multiple reset requests for one account by different agents in a short period
• Any changes to admin or executive accounts
• Verification failures clustering on a small set of accounts

These signals individually might mean nothing. In combination, they're the signature of an active attack. When they trigger, the right response is a security escalation - not closing the ticket and moving on.

The verification failure that's coming: the passkey transition

Most MSPs aren't thinking about this yet, but they should be.

Microsoft Entra is moving to passkeys by default starting September 2026, retiring SMS and voice authentication by February 2027. Passkeys are better security - they're phish-resistant by design. But they create a verification problem at the help desk.

A passkey is device-bound. When a user loses, breaks, or can't access their device, their credential can't be self-reset. The only path back is the help desk, which must verify the person's identity and issue a Temporary Access Pass or re-enroll a new device.

More passkeys means more device-loss situations means more help desk recovery calls. And each of those calls is now a high-value social engineering target because the recovery action grants access that a phished password alone couldn't provide.

If you're migrating clients to passkeys - and you should be - getting your help desk identity verification controls right first isn't optional. It's the prerequisite.

Regulatory and insurance pressure is real

If the security argument alone doesn't move the needle, the compliance argument might.

CMMC 2.0 explicitly requires identity verification at the point of privilege escalation and credential management for defense contractors and their supply chain. Access Control (AC) and Identification and Authentication (IA) domains both apply to help desk procedures. If your clients are in the defense industrial base, your help desk verification practices are in scope.

HIPAA requires that identity verification for access resets is "adequate and appropriate." The HHS sector alert documenting coordinated healthcare help desk attacks makes clear that regulators now view weak help desk verification as a compliance gap, not just a security concern.

Cyber insurance underwriters are asking specific questions: Do you require video verification for high-risk resets? Do MFA resets require manager approval through a verified channel? Does password reset trigger session revocation? Organizations without documented controls face claim denials if a breach traces back to help desk abuse - and that's a conversation you don't want to have after a $380M incident like Clorox experienced following its Cognizant help desk compromise.

SOC 2 Type II auditors test whether help desk agents actually follow the documented verification procedure. A policy that lives in a document and gets ignored under time pressure doesn't satisfy CC6. Auditors will probe this.

What verification looks like in practice

Here's a concise look at what each request type should require:

Two things to note across every row:

1. The caller never provides the callback number. The agent looks it up in the directory.
2. Session revocation is not optional for password resets. Resetting a password without revoking sessions leaves attackers with valid tokens that bypass the new password entirely.

Handling verification failures

When a caller can't pass the verification bar, the response matters as much as the verification itself.

The agent should say something like: "This request needs additional verification. We'll follow up through [verified channel] within [X minutes]."

No accusation. No explanation of which check failed (that would teach the attacker what they still need to find). No "I'm sorry, I can't help you right now."

The failed request should become a security event, not a closed ticket. If it closes as unresolved with no follow-up, you lose the pattern detection signal. Multiple failed verifications clustering on the same set of accounts is an active probe that your team should see.

And importantly: make it culturally safe for agents to escalate. If agents who flag suspicious calls get second-guessed or chewed out for slowing the queue, they'll quietly resolve instead of escalating. The first time someone escalates a legitimate request that turns out to be fine, handle it well. The whole system depends on that moment.

Where Rallied fits in

Once identity is verified, the actual execution - the password reset, the session revocation, the ticket closure - is where things get inconsistent on human-staffed help desks. A tech who verified the caller perfectly can still skip the session revocation because they're in a hurry, or forget to log the action, or apply slightly different steps than the procedure says.

Rallied is an AI technician that takes the verified ticket and handles execution end-to-end. It connects directly to Entra ID, Okta, and JumpCloud for identity actions; to ConnectWise Manage, HaloPSA, Autotask, and SuperOps for ticket management; and to your RMM for endpoint actions. When a password reset ticket comes in flagged as verified, Rallied resets the password, revokes all active sessions, logs the action with a full audit trail, and closes the ticket - every time, in the same way, with no variation based on who's handling it.

The workflow below shows how Rallied handles an offboarding request - the same step-by-step execution model applies to password resets, account unlocks, and access provisioning.

This isn't replacing the verification step - that's still a human or a self-service flow. Rallied handles what comes after: consistent, auditable execution that doesn't depend on the tech being alert, unhurried, or remembering every step of a procedure. For MSPs trying to enforce consistent security procedures across dozens of clients, that consistency is where the real risk reduction happens.

Rallied starts in Plan Mode, posting what it would do on every ticket without making changes. Most MSPs go live in under a week - no workflow library to build, no training phase. You check its judgment against real tickets, then widen its execution scope as you gain confidence. Pricing is $150 a month for 2,000 credits, about 700 tickets in a typical month, and tickets it couldn't finish or wasn't allowed to act on are never charged.

Building toward a stronger posture: an implementation roadmap

Getting identity verification right doesn't happen overnight. Here's a realistic phased approach.

Weeks 1-4 (immediate):

• Document your current verification procedure for every request type. What actually happens today, not what the policy says.
• Identify which requests carry real risk (MFA resets, privilege escalation, admin accounts).
• Map which agents can approve which request types. Who has the keys to what?
• Implement basic cross-ticket alerting - at minimum, flag MFA + password resets on the same account.

Weeks 5-12:

• Deploy tiered verification by account risk level.
• Implement out-of-band verification (callback to registered number sourced from directory).
• Require manager notification for any sensitive reset - set up the process even if you're not requiring approval yet.
• Add session revocation to password reset workflows.
• Launch SSPR enrollment campaigns for your clients' users before they need it.

Weeks 13-26:

• Enable live video verification for admin and executive accounts.
• Integrate with an identity proofing service for recovery workflows if your client base warrants it.
• Real-time escalation to the security team for failed verifications.
• Roll out FIDO2 security keys for privileged accounts.

Weeks 27+:

• Shift routine resets to self-service paths entirely.
• Reserve the help desk for genuine exceptions - new hires, technology failures, accessibility needs.
• Run quarterly vishing simulation tests against your desk team to surface gaps before attackers do.

Try Rallied

Rallied is an AI technician that connects to your MSP stack - PSA, RMM, M365, identity, documentation - and handles the execution side of ticket resolution autonomously. Password resets, account unlocks, MFA re-enrollment after verification, onboarding and offboarding workflows - all executed consistently, with a full audit log, every time.

If your help desk is spending hours on L1 tickets that a verified request and a consistent procedure could resolve in seconds, Rallied is worth a look. Most MSPs go live in under a week, and $150 a month covers 2,000 credits, about 700 tickets in a typical month. The math tends to work out fast: 50 to 100 hours of L1 tech time freed per month, across your book of business, for one monthly price.

The identity verification problem is on you to solve - that human judgment layer is where Rallied defers to your procedures. What Rallied handles is everything that comes after: consistent, logged, auditable execution that doesn't vary by who's on shift.

To see how Rallied handles this inside your PSA, read about Microsoft 365 Management for MSPs.

Frequently Asked Questions

What is the most common identity verification method MSPs use at the help desk?

The most common methods are PIN codes stored separately from ticketing systems, out-of-band callbacks to numbers sourced from the company directory (not supplied by the caller), and email-based one-time passwords. These work for standard users. For admin or executive accounts, current best practice requires live video verification plus manager approval through a verified channel - not just a callback.

Why is asking for an employee ID or date of birth no longer enough to verify someone at the help desk?

Employee IDs, dates of birth, SSN last four digits, and manager names are all available from data breaches, LinkedIn, and public records. BeyondTrust research documents that attackers routinely gather this information during a 1-2 day reconnaissance phase before the actual attack call. Static personal data that never changes is the weakest possible verification signal - it's essentially public information.

What is a two-call split attack and how does it target MSP help desks?

A two-call split attack exploits the fact that help desk verification happens per ticket, not across tickets. An attacker calls once to reset MFA for an account, then calls back (often a different shift or agent) to reset the password. Each agent sees an independent, apparently reasonable request. The ticketing system never correlates the two calls, and by the time both succeed, the attacker has full account access. The defense is cross-ticket alerting that flags MFA and password resets on the same account within a short window.

Does moving to passkeys and passwordless authentication eliminate the help desk identity verification problem?

No - it makes the problem more acute. Passkeys are tied to a specific device. When a user loses or breaks that device, they cannot recover access on their own. The only recovery path is the help desk, which means every lost-device situation becomes a high-value social engineering opportunity. As more organizations go passwordless, the number of help desk recovery requests - and the value of each one to an attacker - goes up, not down.

How does an AI technician like Rallied help with help desk identity verification?

Rallied handles the execution side of verified tickets - once identity verification is confirmed, Rallied takes the ticket, executes the approved action (password reset, account unlock, MFA re-enrollment), revokes existing sessions, logs the action, and closes the ticket. This removes the human judgment call from the resolution step and ensures every verified reset follows the same controlled, auditable procedure. See rallied.ai for how it integrates with ConnectWise, HaloPSA, Autotask, Entra ID, Okta, and JumpCloud.