Who is accountable when a third-party help desk is tricked into granting access?

Why This Matters for Security Teams

A third-party help desk is often the last mile of access governance, but it does not become the owner of the risk simply because it executes the step. The enterprise still owns the identity lifecycle, the verification standard, and the business impact when a fraudster social engineers an approval. NHI Management Group’s Ultimate Guide to NHIs shows how often identity control fails when secrets, service accounts, and delegated access are not governed with the same rigor as human access.

This is also a third-party and supply chain problem, not just a help desk problem. OWASP’s OWASP Non-Human Identity Top 10 reinforces that identity abuse usually exploits weak process boundaries, not just technical flaws. If a service desk can reset credentials, approve MFA recovery, or reissue access without strong verification and auditability, the enterprise has created a control point that can be manipulated. In practice, many security teams discover this only after a fraudulent reset has already been used to reach production systems.

How It Works in Practice

Accountability should follow the authority to grant access, not the party that performed the click. The enterprise sets the policy, defines acceptable proofing, approves exception handling, and retains the obligation to verify that the third-party help desk is following those rules. Contract language matters, but operational enforcement matters more: approval workflows, step-up verification, dual control for high-risk actions, and logging that ties each access change to a named approver and a specific ticket.

For privileged or sensitive access, the control model should align to NIST SP 800-53 Rev. 5 Security and Privacy Controls expectations for access enforcement, audit logging, and accountable authorization. In NHI environments, the same logic applies to service accounts, API keys, and break-glass credentials: the help desk may trigger a reset, but the enterprise still owns rotation policy, offboarding, and post-incident review. That is why NHI Management Group’s research on the 52 NHI Breaches Analysis is so relevant: delegated processes become attack paths when verification is weak and secrets remain valid too long.

• Define which actions the third-party desk can perform, and which require enterprise approval.
• Require strong identity proofing before password resets, MFA resets, or privilege changes.
• Log ticket ID, approver identity, verification method, and time of action.
• Test vendor processes with red-team style social engineering scenarios.
• Revoke or rotate secrets immediately after high-risk access events.

These controls tend to break down in high-volume support environments where speed is prioritised over verification, because agents and vendors start bypassing the intended approval path.

Common Variations and Edge Cases

Tighter verification often increases support friction, requiring organisations to balance faster recovery against stronger proofing. That tradeoff is real, especially for executive accounts, emergency access, and outsourced global service desks operating across time zones. Current guidance suggests treating high-risk resets as exceptional events, not routine service actions, but there is no universal standard for exactly where that threshold should sit.

One common edge case is shared responsibility across multiple vendors. If an MSP runs the service desk and a separate IAM provider runs the directory, accountability can become fragmented unless the enterprise retains end-to-end policy ownership. Another edge case is recovery for privileged accounts used by automation or NHI workflows, where a reset by help desk staff may inadvertently break downstream systems. In those cases, the enterprise needs an explicit recovery runbook, not an improvised support script. For broader governance of delegated identity risk, NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference point.

Best practice is evolving toward evidence-based verification, strict offboarding obligations, and periodic vendor testing. The enterprise remains accountable even when the vendor makes the mistake, because the control framework, not the contractor, defines whether the access should have been granted at all.

Related resources from NHI Mgmt Group

• Who is accountable when third-party exposure is discovered late?
• How should organisations govern third-party access in continuous monitoring programmes?
• Who is accountable when passport enrolment data is captured at accredited third-party sites?
• Why do VPNs make third-party access harder to govern?