Help Desk Identity Verification for MFA Resets

You can hold a clean CMMC Level 2 assessment, deploy phishing-resistant MFA across every user, and still lose a privileged account before lunch — because someone called the help desk, said their phone died, and a technician who wanted to be helpful reset the password and re-enrolled the MFA factor. That is why help desk identity verification for MFA resets deserves its own documented procedure, separate from your general security awareness program.

Attackers mostly aren’t breaking MFA as cryptography. They ask a human to issue them a new factor.

For a defense contractor, the downstream consequences are different from a commercial shop. The account in question may touch CUI. The person being impersonated may be cleared. And the procedure your help desk followed — or didn’t — becomes something an assessor can ask you to show on a ticket-by-ticket basis.

How do attackers bypass MFA by calling the help desk?

They don’t bypass it. They get it reissued to a device they control.

Obsidian Security defines help-desk social engineering as attackers manipulating support staff to gain unauthorized access, commonly by impersonating legitimate users and using pretexting or AI voice cloning to reset passwords, swap MFA devices, or extract confidential information — exploiting human process rather than a technical flaw.

In real-world cases Obsidian analyzed, the attacker contacted the help desk to reset the target user’s password and reset the MFA device tied to the account. Obsidian says that pair of actions is what it sees in most help-desk attacks. That combination is the signature worth alerting on.

Obsidian also reports that over a 12-month period it observed attackers subverting MFA in 70% of SaaS breaches. Read that as a statement about enrollment and recovery workflows, not about the strength of the factor itself.

One more thing from Obsidian’s research that changes day-to-day practice: it explicitly cites AI-driven voice cloning used to mimic executives and employees. So “I recognized her voice, we talk every week” is not verification. It never really was, but it is now demonstrably unreliable, and it is the kind of reasoning that shows up in a post-incident timeline.

Is asking for employee ID and date of birth enough to verify a caller?

No. Those are not identity verification — they are knowledge collection.

Name, employee ID, date of birth, hire date, manager’s name, last four of an SSN: an attacker can buy, scrape, or infer all of it. Your org chart is on LinkedIn. Your email format is predictable. Past breach dumps fill in the rest. A caller who answers three knowledge questions correctly has proven only that they did research.

The distinction that matters is whether verification depends on something the caller supplies or something you already hold about that person — a number of record, a registered device, a photo in the HR system, a manager account you can independently reach.

What should a help desk identity verification policy include?

A workable policy is short, specific, and leaves the technician no room to improvise under pressure. Ten items to build from:

1. Never accept caller-supplied contact details. Call back only to the number or address of record in your HR system of truth.
2. Require second-channel or in-band verification. A video call with camera on and a visual match to the HR photo, or an attestation from a manager’s verified account.
3. Push a time-boxed one-time verification code to a pre-registered device or to the user’s manager. Never read a code to the caller.
4. Treat MFA re-enrollment as higher privilege than a password reset, with its own approval path.
5. Enforce a mandatory hold and sign-in risk review before any privileged or admin account reset.
6. Ban knowledge-based questions as sole verification — DOB, last four, employee ID, manager name, hire date.
7. Write hard-stop escalation rules. No exceptions for urgency, executive pressure, travel, or a bid deadline. The exception is the attack.
8. Log every reset with the verification method used, and alert when a password reset and an MFA change hit the same account inside a short window.
9. Verify identity at first enrollment, not only at reset — new hires, returning employees, remote onboarding.
10. Apply the same rules to outsourced help desks and to any subcontractor who can touch your tenant.

Notice that none of this is a product. It’s a procedure, which is why it’s cheap to fix now and expensive to fix after an incident.

Does CMMC require identity verification before a password reset?

We’re not going to quote a practice ID or requirement number here — numbering differs between NIST SP 800-171 revisions, and misquoting a control in front of a GovCon audience does more harm than the citation is worth. Confirm the current text with your compliance reviewer, C3PAO, or counsel.

What we will say plainly: identification and authentication controls only make sense if authenticators are issued and reissued to the verified correct person. A help desk that re-enrolls MFA on the strength of a caller’s name and employee ID has a control on paper and not in practice.

Treat verification as an evidence problem. If a DoD assessor or a DCMA DIBCAC team asks about your last several MFA resets, you should be able to produce three things: the documented procedure, who is trained and authorized to follow it, and per-ticket proof of which verification method was used. Frame this as supporting compliance evidence — not as a claim that a written SOP satisfies any specific clause.

What should you check in a GCC High or DoD-community tenant?

Check how many recovery paths you actually have, and how many of them are manual.

This is worth verifying in your own environment rather than assuming: in GCC High and DoD-community tenants, you may find fewer self-service recovery options and more break-glass admin accounts than you’d have in a commercial tenant. Confirm both against your tenant configuration and Microsoft’s current documentation.

If that’s what you find, more recovery volume is moving through human-mediated paths — which makes those paths a control of last resort, deserving the scrutiny you’d give an emergency-access account.

It’s also reasonable to assume that cleared and CUI-handling personnel are higher-value impersonation targets than the average user, which means the accounts most worth protecting are the ones an attacker is most motivated to talk their way into. Rank your reset procedures accordingly.

What about your outsourced help desk and your subcontractors?

This risk can flow up the supply chain, not just down.

Start with a question about your own flow-down chain: do your subcontractors share Teams and SharePoint access with the prime? If they do, a help-desk failure at a Tier 2 supplier can surface as a CUI exposure at the prime — which is a good reason to ask suppliers what their verification standard is, not just whether they have one.

Same question in the other direction. Your prime is assuming your support desk is hardened. If you outsource support, your verification standard is whatever your provider’s standard is — so put it in writing and test it.

Which tools help, and which decisions can’t be automated?

Tooling narrows the window; it doesn’t replace the procedure.

Microsoft documents Entra ID capabilities relevant here — Temporary Access Pass for verified onboarding and recovery, self-service password reset policy hardening, authentication strengths in Conditional Access, sign-in risk signals, and privileged role separation. Confirm current behavior and GCC High availability against Microsoft’s documentation before you design around any of them; feature parity gaps in government clouds are real.

For what happens after a suspected takeover: Fortinet and Sophos offer network and endpoint containment capabilities, CrowdStrike and SentinelOne offer identity-adjacent detection and response, and Veeam and Acronis offer recovery capabilities when a takeover leads to data destruction or ransomware. Those are vendor capabilities, described as such. palmiq is an Acronis Platinum partner (top 1% globally) and a Microsoft Gold partner, and we run a 24/7 SOC with a 15-minute response SLA on critical issues — which matters most in the hour after someone realizes the reset shouldn’t have happened.

Where does your help desk stand right now?

A quick self-check, not a compliance determination: if you’d answer “no” to three or more of items 1 through 6 above, your help desk can probably be talked out of an MFA factor today. If you can’t produce the verification method used on your last five resets, you have an evidence gap as well as a security gap.

Either answer is worth a real look rather than a guess. The first version of this fix is usually a one-page procedure: who verifies, how, what’s forbidden, and where it gets logged.

Next step

If your help desk procedure is currently “we ask a few questions and use judgment,” that’s a good thing to talk through before someone tests it. We’re happy to walk you through what a documented verification procedure looks like in a GovCon environment and what evidence assessors tend to ask for. Book a discovery call.

---

Source: Obsidian Security, “Dissecting Real World Help Desk Social Engineering Attacks” — https://www.obsidiansecurity.com/blog/dissecting-real-world-help-desk-social-engineering-attacks