Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Help-desk social engineering has become a board-level identity risk because one call can trigger password or MFA resets, bypass controls, and produce multimillion-dollar losses, according to Trusona’s analysis of recent breaches, regulatory pressure, and board oversight expectations. The real failure is treating human verification as a procedural step instead of a governed access control.
NHIMG editorial — based on content published by Trusona: Blog Board-Level Question: What’s Your Help Desk Social Engineering Defense? Cybersecurity risk has become a top concern for corporate boards
By the numbers:
- Nametag reports that 50-90% of attacks involve social engineering.
Questions worth separating out
Q: How should security teams protect helpdesk reset workflows from social engineering?
A: Security teams should treat reset workflows as privileged access paths.
Q: Why do service desk recovery processes remain vulnerable even with MFA?
A: Because MFA protects the login path, while service desk social engineering targets the exception path.
Q: What breaks when help-desk identity proofing depends on caller confidence or familiar voices?
A: Voice, tone, and familiarity do not reliably distinguish a legitimate user from a trained attacker using spoofing or cloning.
Practitioner guidance
- Redesign help-desk reset authority Classify password resets, MFA re-enrolment, and recovery changes as privileged actions with explicit approval, logging, and post-event review.
- Replace knowledge-based verification Use device-bound proofing, callback-to-file checks, and phishing-resistant MFA instead of static questions or conversational trust signals.
- Script the reset workflow Require agents to follow a fixed call script, record the interaction, and stop any reset that lacks the required out-of-band verification step.
What's in the full article
Trusona's full blog post covers the operational detail this post intentionally leaves for the source:
- Board reporting examples that translate help-desk reset risk into business impact and oversight language.
- Specific identity proofing patterns for password and MFA resets, including government-ID, selfie, and device checks.
- Workflow controls such as call-backs, multi-party approval, and reset recording for high-risk accounts.
- Guidance on monitoring reset attempts and using anomaly thresholds to flag suspicious support activity.
👉 Read Trusona’s analysis of help-desk social engineering defenses and board oversight →
Help desk social engineering: is your identity proofing enough?
Explore further
25/08/2026 6:11 pm
Help-desk social engineering is really a human IAM failure disguised as support fraud. The control being abused is identity recovery, not merely caller trust. When reset workflows can override stronger authentication, the help desk becomes a privileged pathway into the enterprise. Practitioners should treat this as a governance problem across identity, support, and privileged access management.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
A question worth separating out:
Q: Who is accountable when a help desk reset leads to account takeover?
A: Accountability sits with the organisation that owns the recovery process, not just the individual agent who approved the action. Security, IAM, and service owners should define the controls, evidence standards, and escalation paths before resets can restore trust. If the process can be abused, the process owner owns the risk.
👉 Read our full editorial: Help desk social engineering exposes a board-level identity gap
