Notifications
Clear all
Topic starter
12/06/2026 9:35 pm
TL;DR: Help desk attacks increasingly target users who cannot present a registered authenticator, including contractors, partners, and workers replacing lost devices, leaving organisations to fall back on weak manual checks, according to RSA Security. The real issue is not just authentication failure, but a verification gap that undermines auditable, phishing-resistant identity control across extended workforces.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
A: They should route those requests through a formal fallback proofing path, not an informal exception.
A: Because the organisation often assumes every caller can complete the same identity proofing flow, but contractors, partners, and recovery cases frequently cannot.
Q: How do you know if help desk identity verification is actually covering your highest-risk users?
A: Test the workflow against users without registered devices, users with lost authenticators, and users in external workforce roles.
Practitioner guidance
- Map help desk verification coverage across all user classes Identify where your current support workflow assumes the user has a registered authenticator, then test contractors, partners, temporary staff, and recovery scenarios to expose the gaps.
- Formalise a fallback proofing path for authenticator loss Define a policy-controlled branch for users who cannot complete the primary verification flow, and require that branch to preserve audit evidence instead of relying on knowledge-based questions or ad hoc exceptions.
- Tie verification strength to request risk Use context such as location, request sensitivity, and behavioural signals to route higher-risk help desk actions into stronger verification paths rather than giving every request the same treatment.
What's in the full announcement
RSA Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The exact help desk verification flow, including how the admin console receives and validates the user code
- The policy settings that route authenticator-based users and ID Verification users into different assurance paths
- The operational examples for high-risk requests such as wire transfers, privilege escalation, and VPN recovery
- The deployment notes for extending coverage inside an existing RSA ID Plus environment
👉 Read RSA Security's analysis of closing the help desk identity verification gap →
Help desk identity verification for contractors and partners?
Explore further
12/06/2026 11:45 pm
Help desk verification is now part of the identity boundary, not a back-office support detail. The article shows that attackers do not need to break the authentication stack if they can exploit the gap between a user’s actual assurance state and the workflow the help desk expects. That turns support interactions into governed identity events, especially where contractors, partners, and recovery cases are involved. Practitioners should treat the help desk as an access boundary with its own assurance policy.
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 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 is accountable when a support workflow lets an impersonation attempt succeed?
A: Accountability sits with the organisation that allowed an ungoverned verification exception to replace a controlled identity proofing process. Security, IAM, and help desk ownership must share the control boundary, because a support interaction can create the same access consequences as a login event. Governance should define who owns the fallback path before an incident occurs.
👉 Read our full editorial: Closing the help desk identity verification gap for extended workforces
