Who should own service desk identity proofing in an IAM programme?

Why This Matters for Security Teams

Service desk identity proofing is not a routine helpdesk task. It is a trust decision that can raise or lower the assurance attached to an account, which means a weak process can turn a password reset into full compromise. That is why identity governance, IAM, and service desk leadership all have a stake in the design. Current guidance from the NIST Cybersecurity Framework 2.0 supports clear accountability for identity processes, while NHIMG research shows how often identity controls lag in practice. In the Ultimate Guide to NHIs, 91.6% of secrets remain valid five days after notification, which illustrates how quickly delayed or weak recovery actions extend risk.

The operational mistake is treating proofing as a clerical verification step rather than a privileged security function. Once a caller is accepted, the workflow may unlock reset, recovery, and account rebind actions that bypass normal access paths. In practice, many security teams encounter the consequences only after an attacker has already used the service desk to change trust state, rather than through intentional testing of the recovery path.

How It Works in Practice

The cleanest model is shared ownership with clear separation of duties. Service desk operations should run the call, ticket, and evidence workflow, but IAM or identity governance should define the proofing standard, decide what evidence is acceptable, and set escalation thresholds for high-risk cases. That includes scripted verification steps, fraud indicators, callback rules, manager approval for sensitive recoveries, and logging requirements that preserve the full chain of custody.

Practitioners should also classify recovery actions by risk. A routine password reset is not the same as resetting MFA, changing a recovery factor, or reactivating a dormant account. The higher the assurance impact, the more the workflow should align with NIST Cybersecurity Framework 2.0 identity governance expectations and with the broader control patterns described in the 52 NHI Breaches Analysis, where identity trust failures repeatedly become breach enablers.

• Define proofing standards centrally, then make the service desk execute them exactly.
• Treat high-risk recovery as a privileged workflow, not a convenience workflow.
• Require ticketing, evidence capture, and immutable logging for every trust-state change.
• Escalate anything anomalous to IAM, security operations, or fraud review before action is granted.

This approach works best when the organisation has a mature identity governance function and a well-integrated service management platform. These controls tend to break down in outsourced or follow-the-sun support environments because local agents improvise under pressure and drift from the approved proofing standard.

Common Variations and Edge Cases

Tighter proofing often increases call times and support cost, so organisations must balance user recovery speed against account assurance. That tradeoff becomes sharper for executives, contractors, privileged users, and shared service accounts, where the impact of a mistake is much higher than for standard workforce accounts. Best practice is evolving, but there is no universal standard for this yet, especially across regulated and global environments.

For low-risk resets, some organisations allow automated or self-service recovery with step-up checks. For privileged access, current guidance suggests a much stronger model: dual approval, stronger evidence, and additional review by IAM or security. The same logic appears in breach case studies such as the Cisco DevHub NHI breach and the JetBrains GitHub plugin token exposure, where identity misuse and token abuse show how quickly trust can be converted into access.

Where this guidance gets weaker is in decentralised service desks, multilingual support centres, and outsourced operations with inconsistent training. In those settings, control design must be simple enough to follow under pressure, or the proofing policy will exist on paper but fail at the first real incident.

Related resources from NHI Mgmt Group

• Who should own accountability for AI agent misuse in the identity programme?
• Who should own cloud identity decisions when security architecture and IAM overlap?
• Where does cross-environment agent discovery fit in an IAM programme?
• Who should own third-party access risk in a banking GRC programme?