Who is accountable for identity governance when an MSP manages client environments?

Why This Matters for Security Teams

When an MSP manages client environments, identity governance often becomes a boundary problem rather than a tooling problem. The client owns the risk, but the MSP may hold the operational levers that enforce access, document evidence, and trigger revocation. If those responsibilities are not written down, privileged access can remain active long after the work is complete, and neither party will notice until an audit, incident, or customer complaint forces the issue.

This is especially important for non-human identities, where service accounts, API keys, and automation tokens can outlive the project or tenant they were created for. NHI Management Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which magnifies the accountability gap when third parties are involved. Current guidance in the NIST Cybersecurity Framework 2.0 and other governance models still assumes clear ownership, even when operations are outsourced.

In practice, many security teams encounter over-privileged third-party access only after an access review fails or a secret is discovered in a place that no one thought they owned.

How It Works in Practice

The cleanest model is dual accountability with explicit task ownership. The client retains decision authority for who may access the environment, what level of privilege is acceptable, and when access must be removed. The MSP is operationally responsible for carrying out approved actions, producing evidence, and escalating anything that falls outside policy. That separation matters because governance fails when approval, enforcement, and review are spread across ticket queues with no named owner.

For NHI and privileged access workflows, the client should define policy; the MSP should execute controls against that policy. That usually means the MSP administers PAM workflows, maintains logs, validates time-bound access, and supports offboarding, while the client approves exceptions and signs off on recurring reviews. NHI Management Group’s Lifecycle Processes for Managing NHIs emphasizes that offboarding and revocation are lifecycle functions, not one-time cleanup tasks. If the MSP is also managing secrets or service accounts, those assets need explicit tagging, expiration, and evidence of revocation.

Practical controls usually include:

• RACI definitions that name the client approver, MSP operator, and audit owner for each identity class.
• JIT access with time-bound approval and automatic expiry for privileged sessions.
• Named evidence artifacts for access requests, exceptions, and revocation actions.
• Quarterly recertification that the client, not the MSP, signs off on.
• Exit procedures that remove all MSP-held access when the contract ends.

Industry research from The State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which is consistent with weak ownership boundaries. These controls tend to break down when the MSP manages multiple tenants with shared tooling because entitlement evidence becomes fragmented across systems.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance auditability against delivery speed. That tradeoff becomes sharper when the MSP also hosts identity tooling, runs shared admin accounts, or provides incident response services that need emergency access.

Best practice is evolving for shared-responsibility models, but the core rule is stable: the client should never outsource accountability, even if it delegates administration. Where a contract gives the MSP authority to approve its own access, that should be treated as an exception and documented with compensating controls. For high-risk environments, the client may also require separate approval paths for production access, secrets access, and break-glass access.

Edge cases often appear in regulated or multi-jurisdictional environments. If the MSP uses its own monitoring stack, the client still needs retained access to evidence and logs. If the MSP is responsible for rotating credentials, the client should set the rotation standard and validate completion. Where there is no universal standard for this yet, current guidance suggests applying zero trust principles and least privilege consistently, then proving revocation rather than assuming it happened. The NHI Management Group Top 10 NHI Issues resource is useful here because it frames lifecycle gaps, excessive privilege, and visibility failures as governance defects, not just operational misses.

These controls tend to break down when MSP access is inherited from legacy admin practices because the contract says “support” while the environment still treats the MSP like a permanent superuser.

Related resources from NHI Mgmt Group

• Who should be accountable for AI identity governance?
• Who is accountable for identity governance in a growing startup?
• Why do MSP relationships increase identity governance risk?
• Why is it important to integrate identity and data governance?