How should MSPs govern access across multiple SaaS tenants?

Why This Matters for Security Teams

Managed service providers often assume that one control plane can safely govern many customers, but tenant sprawl changes the risk model. A single operator may have legitimate access to dozens of SaaS environments, which makes mis-scoped roles, weak approval paths, and poor logging into cross-tenant exposure risks rather than mere admin inefficiencies. The governance problem is not centralisation itself, but whether the model preserves separation of duties across customer boundaries. That is why the NIST Cybersecurity Framework 2.0 emphasis on governance, access control, and auditability maps well to MSP operations.

For NHI and service-account driven access, the same problem appears repeatedly in incident analysis. NHIMG’s Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for MSPs managing access at scale. When tenant context is not explicit, one credential or admin role can quietly outlive the support request that justified it. In practice, many security teams encounter cross-tenant misuse only after a support action has already touched the wrong customer environment, rather than through intentional governance design.

How It Works in Practice

Effective MSP governance starts by treating every SaaS tenant as its own policy boundary, even if the MSP uses one management platform. That means the access model should be client-scoped, time-bound, and attributable. Each technician or automation account should have a distinct identity, with tenant-specific entitlements rather than broad platform-wide privileges. The OWASP Non-Human Identity Top 10 is useful here because the same failure patterns recur with service accounts, API keys, and delegated admin tokens.

Practically, strong MSP controls usually include:

• Separate tenant roles for onboarding, break-glass support, billing, and security operations.
• Approval workflows for any action that crosses tenant boundaries or changes delegation scope.
• Per-tenant logging that preserves who acted, which account was used, and what customer data was touched.
• Short-lived credentials or just-in-time access for support actions instead of standing admin grants.
• Periodic review of dormant tenant access, especially for former clients and inactive engagements.

Where possible, use automation to enforce expiration and revocation so access is removed when the ticket closes, not when someone remembers to clean it up. NHIMG’s Lifecycle Processes for Managing NHIs aligns well with this approach because the operational issue is lifecycle control, not just initial provisioning. For MSPs, the governance workflow should also distinguish between read-only visibility and write access, since many support tasks need observation without the ability to change tenant configuration. These controls tend to break down when a single engineer is allowed to reuse a shared admin credential across tenants because attribution and revocation both become ambiguous.

Common Variations and Edge Cases

Tighter tenant separation often increases operational overhead, requiring organisations to balance support speed against auditability and blast-radius reduction. That tradeoff becomes visible in high-volume MSP environments where engineers need rapid response across many customers.

There is no universal standard for MSP tenant governance, but current guidance suggests a few patterns. Shared jump accounts and delegated admin groups can work if the tenant context is enforced at runtime and all actions are fully logged, but they become risky when support staff can pivot from one customer to another without re-approval. In regulated environments, cross-tenant access may also need customer-specific contractual approval and stronger evidence retention.

For service providers using automation, the same rule applies to non-human identities. A bot that manages multiple SaaS tenants should not have one long-lived credential with universal scope. Instead, each tenant workflow should use its own workload identity, limited secret scope, and explicit revocation path. NHIMG’s Top 10 NHI Issues is a useful reminder that privilege creep and weak offboarding are common failure points, especially when provider teams optimise for scale before control. Where MSPs support customers with different data residency or compliance requirements, separate logging and retention policies may also be necessary because a shared operational model can unintentionally merge evidence that should remain isolated.

Related resources from NHI Mgmt Group

• How should MSPs govern SaaS access across multiple client tenants?
• 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?