How should MSPs govern SaaS access across multiple client tenants?

Why This Matters for Security Teams

For MSPs, saas access governance is not a single identity problem. It is a multi-tenant control problem where delegated administration, shared tooling, and client-specific approvals can easily collapse into a blurred responsibility model. That is exactly where non-human identities become risky: service accounts, API keys, tokens, and automation paths often outlive the tenant context they were created for. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a serious warning sign for any provider managing multiple customer environments.

The practical risk is that one operator, one workflow, or one mis-scoped approval can affect several clients at once. That creates audit ambiguity, weakens offboarding, and makes entitlement reviews harder to defend when a tenant asks who approved what and why. Security teams also need to account for the fact that SaaS permissions are often granted through integrations rather than interactive logins, which means standard joiner-mover-leaver processes are not enough. The OWASP Non-Human Identity Top 10 is useful here because it frames the control failures that appear when machine access is treated as a side issue instead of a governed identity class. In practice, many MSPs discover cross-tenant overreach only after an offboarding failure or customer audit has already exposed it.

How It Works in Practice

MSPs should govern SaaS access by tenant, by application, and by delegated function. The goal is to ensure every access path maps to a specific client owner, a specific business purpose, and a specific revocation path. That means access requests should carry tenant metadata, approval records should be tenant-bound, and entitlements should be reviewed against the actual SaaS app rather than against a generic MSP admin role. Current guidance suggests this should be treated as a control-design problem, not just an operations task.

A workable model usually includes:

• Tenant-scoped RBAC or ABAC so delegated admins cannot grant broad access across customers by default.
• Per-tenant service accounts or app registrations for automation, with separate secrets and short review cycles.
• Documented ownership for who approves, who changes, and who revokes each entitlement.
• Offboarding runbooks that disable both human and non-human access per tenant, not just the shared MSP console.
• Central logging that preserves tenant context so audits can distinguish MSP action from client action.

This aligns well with the NIST Cybersecurity Framework 2.0 emphasis on governance and access control, but the implementation detail matters more than the label. NHIMG’s Lifecycle Processes for Managing NHIs research reinforces that lifecycle management is where most control failures surface, especially when credentials are reused across environments. MSPs should also track high-risk integrations, because shared OAuth apps and cross-tenant automation can quietly inherit more privilege than intended. These controls tend to break down when a single SaaS tenant is administered through a shared super-admin account because attribution, approval, and revocation all become ambiguous at the same time.

Common Variations and Edge Cases

Tighter tenant isolation often increases operational overhead, requiring organisations to balance stronger segregation against support speed and tool complexity. That tradeoff is real for MSPs, especially when clients expect rapid provisioning and low-friction administration. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: shared access should be exceptional, time-bound, and explicitly documented.

One common edge case is the “central console, distributed authority” model, where the MSP uses one platform to manage many tenants but still needs separate approval chains and revocation paths per customer. Another is emergency support access, which may require temporary elevation across a tenant boundary; in those cases, just-in-time access and ticket-linked approvals are safer than standing permissions. A third is outsourced co-management, where the client retains ownership but the MSP executes changes. Without tenant-level review evidence, that model often fails audit scrutiny even when the technical access looks correct.

For organisations with many SaaS integrations, NHIMG’s Top 10 NHI Issues and the Regulatory and Audit Perspectives sections are useful reminders that control evidence matters as much as control intent. In practice, MSPs usually feel the weakness of cross-tenant governance when a customer requests an access audit or an urgent offboarding and the provider cannot cleanly prove who had authority in each tenant.

Related resources from NHI Mgmt Group

• How should MSPs govern technician access across multiple client environments?
• How should organisations govern SaaS licenses alongside identity access reviews?
• How should security teams manage access reviews across multiple compliance frameworks?
• How should teams govern lifecycle changes across SaaS applications?