Who is accountable when a third-party service desk is used to reach client systems?

Why This Matters for Security Teams

When a third-party service desk is used to reach client systems, the risk is not just remote support. It is delegated access into an environment that the client still owns, governs, and must defend. That means the buyer has to validate authentication, approval, session monitoring, and rapid revocation, even if the service desk operates the toolset. OWASP’s OWASP Non-Human Identity Top 10 is useful here because the real control problem is identity and privilege, not vendor status.

NHI Management Group research shows the scale of exposure is often underestimated: 92% of organisations expose NHIs to third parties, which makes supply chain access a routine governance issue rather than an edge case. The same pattern appears in incidents tied to exposed support tooling, where secrets, tokens, and service accounts become the practical path into client systems. See the The 52 NHI breaches Report for examples of how identity sprawl turns into breach paths.

In practice, many security teams discover the accountability gap only after a support session is abused, rather than through intentional third-party access review.

How It Works in Practice

Accountability should be mapped across three layers: the client that permits access, the third-party service desk that performs support, and the control plane that logs and constrains the session. The client remains responsible for the access it accepts, while the vendor is responsible for operating within the agreed boundary. Current guidance from zero trust and identity governance says the buyer should not rely on trust in the provider alone; it should require explicit authentication, just-in-time approval, scoped access, and revocation when the task ends.

Practically, that means service desk access should be treated like any other privileged pathway:

• Use named, federated identities rather than shared support accounts.
• Require step-up authentication and MFA for every support session.
• Enforce time-bound access with clear expiry and auto-revocation.
• Record sessions, commands, and ticket linkage for auditability.
• Separate request approval from execution so no single operator can self-authorise.

Where this becomes important is identity lifecycle control. If the service desk uses API keys, remote management tokens, or NHI-style automation accounts, those secrets must be rotated, monitored, and offboarded like any other privileged credential. The Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which is exactly the kind of gap that makes delegated access linger after a contract or ticket has ended. That is why the control objective is not just “vendor management” but full access lifecycle enforcement, including logs that can prove who did what and when. The right operating model also aligns with least privilege and zero standing privilege, so the service desk can reach only the systems and functions needed for the approved case. These controls tend to break down in flat network environments with shared admin credentials because attribution, scope enforcement, and revocation all become unreliable.

Common Variations and Edge Cases

Tighter third-party access controls often increase operational overhead, so organisations have to balance faster support against stronger containment. That tradeoff becomes visible in incident response, after-hours maintenance, and emergency break-glass use cases, where teams sometimes accept broader access to restore service quickly.

Best practice is evolving for whether clients should rely on vendor-managed PAM, client-managed PAM, or a hybrid model. There is no universal standard for this yet, but current guidance suggests the client should retain approval authority, logging access, and the ability to revoke support paths independently of the provider. For high-risk environments, a session broker, jump host, or remote support gateway is usually preferable to direct inbound access.

Edge cases matter. If the third-party service desk supports multiple clients from one operator console, support accounts and tokens become high-value NHIs that need segmentation and frequent rotation. If access is delivered through automation, treat it as machine identity, not just a contractor workflow. The Reviewdog GitHub Action supply chain attack illustrates how quickly trusted tooling can expose secrets when governance is weak. In short, the client owns the risk acceptance, even when the vendor owns the keyboard.

Related resources from NHI Mgmt Group

• Who is accountable when a compromised machine identity is used to reach sensitive systems?
• Who is accountable when third-party cloud access is abused in a data breach?
• Who is accountable when third-party access remains active after the task is complete?
• Who is accountable when a third-party notices suspicious identity activity first?