Who should own access risk when MSPs manage multiple customer environments?

Why This Matters for Security Teams

When an MSP manages multiple customer environments, access risk is not just a local admin problem. It becomes a cross-tenant governance problem that can hide in shared tooling, delegated admin roles, and inconsistent review workflows. The team that owns the risk needs enough context to see identity posture, data sensitivity, and exception handling across customers, not just within a single tenant. That is why NHI Management Group’s guidance in the Ultimate Guide to NHIs treats visibility and lifecycle control as core governance tasks, not optional hygiene.

This matters even more because compromised non-human identities are already a routine failure mode. In the 2024 ESG Report: Managing Non-Human Identities, Oasis Security & ESG found that 72% of organisations have experienced or suspect they have experienced an NHI breach. For MSPs, fragmented ownership can turn one weak exception process into repeated exposure across many customers. In practice, many security teams encounter the problem only after a shared administrative path has already been abused, rather than through intentional governance design.

How It Works in Practice

Access risk ownership should sit with a role that can reconcile three things at once: who the identity belongs to, what data it can touch, and how exceptions are documented across tenants. In MSP environments, that usually means a central security or governance function with mandatory input from customer-specific service owners, rather than letting each tenant manage access in isolation. Current guidance suggests that this is less about centralising all decisions and more about centralising correlation, review, and escalation.

A practical operating model usually includes:

• one authoritative register of privileged identities, service accounts, API keys, and delegated admin roles
• tenant-level approvals for business context, with MSP-level oversight for cross-customer patterns
• scheduled access reviews that compare effective permissions against expected scope
• exception tracking with expiry dates, ticket references, and named owners
• evidence collection for audit that shows who approved access, when it was reviewed, and when it was revoked

This aligns with the control logic in the NIST Cybersecurity Framework 2.0, which emphasises governance, risk management, and access oversight as continuous functions. It also matches the visibility-first approach in the Ultimate Guide to NHIs, especially where excessive privilege and poor offboarding drive sustained exposure. The point is not to make one team approve every technical change, but to make one team accountable for whether access risk is understood end to end. These controls tend to break down when MSPs rely on customer-by-customer spreadsheets or separate ticket queues because no one can see privilege drift across the full managed estate.

Common Variations and Edge Cases

Tighter central control often increases review overhead, requiring organisations to balance stronger assurance against slower tenant-specific operations. That tradeoff is real in MSP settings, especially where customers have different regulatory obligations or incident response expectations. Best practice is evolving, but current guidance does not support a model where the MSP holds technical admin power while the customer retains all risk ownership without shared evidence and escalation paths.

One common edge case is a co-managed model, where the customer approves access and the MSP executes changes. In that case, risk ownership still needs a named function that can aggregate reporting across both sides, because the operational split does not remove the need for accountability. Another edge case is emergency break-glass access. Those accounts should be treated as exceptional NHIs with short-lived approval, explicit logging, and post-use review. The OWASP Non-Human Identity Top 10 is useful here because it frames excessive privilege and weak lifecycle control as recurring failure patterns rather than isolated mistakes. MSPs that cannot produce a unified access story across customers usually discover the gap during audit, after an incident, or when a revoked entitlement still remains effective in a secondary tenant.

Related resources from NHI Mgmt Group

• How should MSPs reduce risk from privileged access across customer environments?
• Why do non-human identities create audit risk in modern environments?
• When does JIT access create more risk than it reduces?
• How can organizations manage the risk of credential leaks in MCP frameworks?