Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Account takeover protection for help desks focuses on verifying recovery requests before a new password or MFA factor is issued, because attackers increasingly exploit the reset path rather than the login path, according to Trusona. The control gap is not authentication strength alone, but whether help desk workflows can be socially engineered into issuing a legitimate factor to the wrong person.
NHIMG editorial — based on content published by Trusona: How to evaluate account takeover protection for IT help desks
By the numbers:
- Attackers attempt access within an average of 17 minutes after AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing access credentials.
Questions worth separating out
Q: What breaks when help desk recovery is not protected against account takeover?
A: The reset process becomes the attack path.
Q: Why do recovery workflows matter as much as primary MFA?
A: Because attackers often target the fallback path when the main authenticator is strong.
Q: How should security teams reduce the impact of social engineering on human accounts?
A: Use layered controls that assume a person can be fooled.
Practitioner guidance
- Map every factor-issuance path Inventory password reset, MFA re-enrollment, and account recovery flows across help desk, service desk, call center, and delegated admin paths.
- Remove judgment-only verification from high-risk resets Replace knowledge-based checks for privileged users, remote workers, alumni, contractors, and support-sensitive populations with request-time proofing tied to an authoritative identity record.
- Eliminate agent override without audit If an exception is unavoidable, require explicit reason codes, immutable logging, and post-event review so the exception path cannot become the normal path.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step comparison of knowledge-based, enrolled-factor, and identity-proofing recovery flows.
- Detailed evaluation questions for help desk and call center deployments, including override handling and audit evidence.
- Implementation specifics for ServiceNow, Zendesk, Jira, Ivanti, and Freshdesk workflows.
- Examples of how request-time proofing changes the reset workflow for users without an enrolled device.
👉 Read Trusona's analysis of account takeover protection for IT help desks →
Help desk recovery attacks: are your account takeover controls enough?
Explore further
25/08/2026 6:11 pm
Help desk recovery is now part of identity perimeter design. The old assumption was that authentication was the hard problem and recovery was a service function. That assumption no longer holds because attackers target the actor with reset authority, not the password itself. The implication is that account recovery must be governed as a privileged identity workflow, not treated as a convenience layer.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, or revealing access credentials, according to AI Agents: The New Attack Surface report.
- 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when a reset workflow is abused?
A: Accountability usually spans IAM owners, help desk leadership, and the business owner for the affected identity. If the reset path lacked assurance, the issue belongs to governance, not only to the individual operator. Frameworks such as the NIST Cybersecurity Framework 2.0 expect clear control ownership and response responsibility.
👉 Read our full editorial: Account takeover protection for help desks starts at recovery
