You protect the help desk from social engineering by testing the real reset process, then engineering a verification step that no one on the phone can skip. Policies and training still matter, and on their own they rely on one person making the right call under pressure.
The stakes are public. In 2025, Clorox sued its IT services provider for $380 million, alleging that help desk staff reset credentials for an attacker without verifying the caller’s identity (CSO Online).
Why it matters
- The help desk can hand over identity. A password or MFA reset gives access to whoever asked for it.
- Policy describes intent. A documented reset procedure shows what should happen, and only a test shows what does happen.
- Guardrails hold under pressure. A verification step built into the workflow works even when the caller is convincing.
- Outsourcing keeps the risk with you. You can outsource the function, and the consequence stays with your organization.
On this page
Why don’t policy and training stop help desk social engineering?
Audits and training create a record that the policy exists and that staff saw it. They still depend on a person making the right decision every time, often while a caller creates urgency or claims to be an executive.
Our post on the limits of policy describes this as a compliance fix applied to an engineering problem. The root cause is a design that lets one human decision become the point of failure.
| Question | Audit and train | Engineered guardrail |
|---|---|---|
| What does it check? | That the policy exists and staff completed training | That the reset process holds against a real impersonation attempt |
| What does it rely on? | A person making the right call under pressure | A step in the workflow the agent cannot bypass |
| What does it produce? | A compliance record | Test evidence and a control ready to deploy |
What guardrails protect password and MFA resets?
Callback verification
The system calls the employee back on their registered number before the reset goes ahead.
Approval notifications
A manager or security approver is notified, and the reset waits for approval.
Multi-step authorization
An MFA reset needs confirmation through more than one channel before it is processed.
Escalation for privileged accounts
A reset on a privileged account notifies the security team and goes through identity governance review.
The agent never has the authority to skip the step, however urgent the request sounds. Engineering the person out of that decision is what makes the control dependable.
How do you test and fix help desk verification?
We call this approach the Active Assurance Model. It moves the conversation from whether a policy exists to whether the process holds.
- Validate with a controlled test. Run authorized social engineering tests against the actual reset process, through phone, email and ticket channels.
- Stage the guardrail. Use the finding to configure the verification control in a test environment, document it and have it ready to deploy.
- Govern with proof. Report the finding, the staged control and a remediation roadmap together, so leadership sees the risk and the fix in one place.
Staging also helps when the fix reaches the change advisory board, because you bring a tested control instead of a proposal. Read The Change Management Wall, and for the full playbook see The Help Desk Is Now a CISO-Level Liability.
What if your help desk is outsourced?
A contract and an audit report describe what a provider agreed to and which controls existed when it was audited. Neither shows what the agent answering the phone will do today.
- Test the provider like you test yourself. Run the same controlled reset tests against the provider’s help desk.
- Keep the guardrail on your side. Have the provider work through your identity tools, where you enforce verification.
- Compare events with policy. Check actual reset events against the procedure in your contract.
- Escalate privileged resets. Make sure resets on privileged accounts notify your security team.
Our post Why You Can’t Outsource Risk explains why the consequence of a vendor failure stays with you.
Where to go next
The Identity Governance Assessment tests help desk verification across phone, email and ticketing channels with controlled social engineering, stages a verification control ready for your approval, and delivers a 90-day remediation roadmap. If the help desk is run by a provider, the IT Operations Security Audit tests whether outsourced teams follow your security protocols.
For the identity side of Entra ID, read how to find risky app registrations and service principals.
If an outside provider runs your help desk, read how to verify an outsourced IT provider follows your security controls. For getting a new verification step approved, read how to get a security control approved by the change advisory board.
Frequently asked questions
How do you protect the help desk from social engineering?
Test the real reset process with authorized social engineering attempts, then build a verification step into the workflow that the agent cannot skip, such as a callback to the employee’s registered number or an approval notification. Keep the evidence of the test and the fix for leadership and auditors.
Is security awareness training enough to stop help desk social engineering?
Training is necessary, and it still depends on a person making the right call under pressure. A verification step built into the reset workflow holds even when the caller is convincing.
How do you test whether the help desk follows reset procedures?
Run authorized, controlled social engineering tests against the real process through the same channels an attacker would use, and compare actual reset events with your documented policy.
What if our help desk is outsourced?
The function can be outsourced, and the business impact of a failure stays with your organization. Test the provider’s reset process the same way you test your own, and keep verification on identity tools you control.