Notifications
Clear all
Topic starter
06/06/2026 2:30 am
TL;DR: Strong MFA and SSO can still be bypassed when attackers socially engineer service desk password resets, a gap the source article says persists because many recovery flows rely on weak identity checks and inconsistent analyst judgment. The real control problem is that recovery is often treated as operations, even though it functions as an identity trust decision.
NHIMG editorial — based on content published by Imprivata: guidance on self-service password reset and service desk identity verification
By the numbers:
- Social engineering remains a primary breach vector, accounting for 60% of data breach incidents.
Questions worth separating out
Q: How should security teams reduce risk in service desk password reset flows?
A: Move routine resets into self-service flows with strong authentication and policy enforcement, then reserve human handling for exceptional cases.
Q: Why do service desk resets weaken otherwise strong authentication controls?
A: Because the attacker does not need to defeat the login stack if they can persuade a human analyst to restore access through a weaker recovery path.
Q: What do organisations get wrong about identity verification during account recovery?
A: They treat verification as a support preference instead of a security boundary.
Practitioner guidance
- Remove analyst-dependent password resets Shift routine reset requests into self-service flows that use stronger authentication factors and policy enforcement rather than manual approval.
- Standardise recovery proofing thresholds Define one minimum identity assurance standard for every account recovery event, then enforce it across all support channels and shifts.
- Review help desk access as an identity risk surface Map which account types, applications, and downstream systems can be reached after a reset, then prioritise the highest-impact recovery paths for tighter proofing and logging.
What's in the full article
Imprivata's full article covers the operational detail this post intentionally leaves for the source:
- Practical guidance on replacing human-mediated password resets with self-service recovery flows
- Discussion of stronger identity verification methods for service desk interactions and why weak proofing fails
- Details on how existing enterprise access management workflows can be extended to support recovery controls
👉 Read Imprivata's guidance on strengthening service desk password reset security →
Service desk resets: what IAM teams are missing in recovery flows?
Explore further
06/06/2026 4:13 am
The service desk is an identity control plane, not a back-office function. Once recovery actions can override MFA and SSO, the help desk becomes part of the authentication architecture whether or not the organisation treats it that way. That means service desk process design now belongs in IAM governance, access risk reviews, and security architecture decisions. Practitioners should stop assuming recovery sits outside the identity boundary.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should own service desk identity proofing in an IAM programme?
A: IAM and security teams should co-own it, because the decision changes account trust state and can enable full account takeover. Service desk operations executes the workflow, but identity governance should define the proofing standard, escalation rules, and logging requirements. That keeps recovery aligned with the rest of the access control model.
👉 Read our full editorial: Service desk resets expose the weak link in identity security
