Why do help desk attacks matter to PAM and IAM teams?

Why This Matters for Security Teams

Help desk attacks matter because they target the operational layer where identity changes actually happen. PAM and IAM programs often focus on direct system logins, yet attackers know that password resets, MFA re-enrollment, device replacement, and account recovery can have the same effect as privileged access. When those workflows are not treated as security boundaries, the support function becomes a shortcut around stronger controls.

This is not a theoretical concern. In the 2024 Non-Human Identity Security Report, 88.5% of organisations said their non-human IAM practices lag behind or merely match their human IAM practices, showing how often identity governance is uneven across control planes. Attackers exploit that inconsistency by social engineering service desks, then using the resulting changes to pivot into systems, tokens, and downstream accounts. Current guidance from CISA cyber threat advisories repeatedly shows that identity abuse is an operational path, not just a technical one.

In practice, many security teams discover help desk abuse only after an account recovery event has already turned into a broader compromise, rather than through intentional monitoring of privileged support actions.

How It Works in Practice

Help desk attacks usually succeed when the service desk can alter identity state without the same friction applied to administrators. An attacker may impersonate a legitimate user, exploit rushed support processes, or chain small changes such as resetting a password, disabling MFA, or adding a new recovery channel. Once that happens, PAM and IAM controls can be bypassed without ever touching the protected target directly.

The practical fix is to treat support actions as privileged operations, with approval, logging, and verification aligned to risk. That means strong identity proofing for the requester, step-up verification for the agent, and case management records that can be reviewed later. It also means separating ordinary ticket handling from high-impact actions such as MFA reset, directory changes, or privileged account unlocks.

• Classify help desk actions by impact, not by team ownership.
• Require identity verification beyond knowledge-based questions, which are often weak or reusable.
• Log the full before-and-after state for resets, unlocks, and recovery changes.
• Apply PAM-style approvals for actions that can restore or elevate access.
• Alert on repeated reset attempts, unusual timing, or requests tied to high-value users.

For NHI-heavy environments, the same logic applies to service accounts, API keys, and tokens. The Aembit research also found that 59.8% of organisations see value in dynamic ephemeral credentials, which matters because long-lived secrets are especially vulnerable once a support path is abused. Where keys or tokens are exposed, attackers can move quickly, as shown in BeyondTrust API key breach reporting and in Anthropic’s AI-orchestrated cyber espionage campaign report, where identity abuse and tool access were central to the attack path.

These controls tend to break down in high-volume support centres with weak identity verification, outsourced service desks, or environments where one reset can immediately unlock federated apps, cloud consoles, and production secrets.

Common Variations and Edge Cases

Tighter help desk controls often increase ticket handling time and user friction, requiring organisations to balance recovery speed against abuse resistance. That tradeoff becomes harder during incidents, executive requests, or outages, when support teams feel pressure to bypass normal checks.

There is no universal standard for this yet, but current guidance suggests a tiered model: low-risk requests can use normal workflows, while high-risk changes require stronger proofing, dual approval, or out-of-band confirmation. This is especially important when the help desk can reset access for privileged admins, cloud operators, or non-human identities tied to production automation.

Edge cases include emergency access, delegated support for remote workers, and third-party-managed service desks. In those cases, the key question is not whether the request is legitimate, but whether the support action could change the identity trust state in a way that bypasses PAM, breaks auditability, or exposes credentials. NHIMG’s 52 NHI Breaches Analysis and Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same pattern: once identity recovery is weak, attackers do not need to defeat the primary control plane at all.

Related resources from NHI Mgmt Group

• How should security teams reduce enterprise risk with IAM, IGA, and PAM together?
• How should security teams choose a help desk identity verification model?
• Why do help desk attacks work even when employees are aware of phishing risk?
• Why do Shai Hulud style attacks matter to NHI governance?