Who should own access governance when MSSP analysts need viewer or editor access into customer tenants?

The MSSP and the customer both have a role, but the customer should approve the access boundary and the MSSP should operate strictly within it. Access must be scoped by role, tenant, and business need, with clear auditability and permission review. That reduces overreach while preserving the service model and accountability.

Who Owns the Boundary When an MSSP Needs Tenant Access?

Ownership should sit with the customer, because the access boundary is ultimately their risk decision and their tenant. The MSSP can administer within that boundary, but it should not define the boundary itself. That distinction matters most when viewer and editor permissions can cross from harmless visibility into actions that change data, alerts, configurations, or evidence.

In practice, the customer owns approval, scope, and review of who can access which tenant, at what role level, and for what purpose. The MSSP owns operational execution inside that approved scope, including how access is used, logged, and revoked. That split preserves accountability while still allowing outsourced operations to function.

A clean operating model usually answers three questions up front: who approves access, who can change it, and who reviews it after the fact. If those responsibilities are blurred, the MSSP can become both operator and de facto policy maker, which weakens separation of duties and makes permission creep harder to detect.

When the access is for a managed service, the customer should still be able to explain why a viewer or editor role exists, why it is needed for that tenant, and why it is not broader than the business need. A service relationship does not remove the need for scoping; it just changes who executes the work.

How Viewer and Editor Access Should Be Scoped

The right control boundary is role, tenant, and task. Viewer access should be limited to observation and troubleshooting, while editor access should be reserved for changes that the customer has explicitly accepted as part of the service model. If the MSSP needs both, those permissions should be separated rather than bundled into a broad operational account.

Tenant separation is just as important as role separation. An MSSP that supports multiple customers should not rely on shared access patterns that make it difficult to prove which analyst accessed which tenant and why. The more sensitive the environment, the more important it is that access decisions remain tenant-specific and time-bound.

Auditability is not a nice-to-have here, it is the mechanism that makes shared operations defensible. The customer should be able to see who approved access, when it was used, what role was granted, and whether the permission was still necessary at review time. If that evidence cannot be produced, the access model is too loose for a managed service environment.

For broader governance context, NHIMG’s Ultimate Guide to NHIs and the NHI lifecycle management section are useful because they tie access governance to visibility, review, and revocation. The same operating principle applies even when the actor is a human MSSP analyst rather than a machine account.

Why This Becomes a Governance Problem, Not Just an Access Problem

Once an MSSP can see or edit customer systems, the question is no longer only technical access, it is governance over delegated authority. The customer must retain policy ownership, because the service provider’s efficiency should never override the customer’s risk appetite or compliance duties. That is especially true where editor access can affect logs, alerts, retention settings, or security controls.

The main failure mode is overreach: a valid service relationship expands into standing access that is broader, longer-lived, or less observable than intended. Another common failure is review debt, where permissions are approved once and then never revisited after the operational need changes. In both cases, the account may still “work,” but the governance model has already failed.

For that reason, access governance should be documented as a customer-owned decision with MSSP-operated enforcement. The practical line is simple: the customer decides what is acceptable, and the MSSP proves it stayed inside the decision. Where access reviews, audit trails, and revocation discipline are weak, the risk becomes indistinguishable from unmanaged privileged access.

NHIMG’s 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than a human employee doing the same job, which is a useful warning signal for this topic: delegated access tends to expand unless someone explicitly owns the boundary.

Failure mechanism: The MSSP is granted a generic support role, and over time that role becomes the default path for broader tenant visibility, more change capability, or shared credentials that are hard to review and harder to revoke.

Impact: Customer accountability weakens, permission creep increases, and one analyst or one compromised support path can affect more tenants or more functions than the service model intended.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Access Governance	Customer-owned role and tenant scoping directly control delegated access to support identities.
	NHI-02 — Lifecycle Management	MSSP access must be time-bounded, reviewed, and revoked as part of identity lifecycle control.
	NHI-05 — Least Privilege	Viewer and editor roles should be separated so the MSSP only gets the minimum required authority.
Recommendation — Define tenant-specific approvals, role limits, and review cadence for delegated support access. Use time-bound access and revoke support permissions immediately when the business need ends. Grant the smallest role that supports the support task and separate read from change capability.
CIS Controls v8	6 — Access Control Management	This topic centers on approving, scoping, and reviewing access to customer tenants.
	5 — Account Management	MSSP analyst access depends on controlled account issuance, review, and removal.
Recommendation — Restrict and recertify MSSP access by business need, role, and tenant. Provision named accounts, review usage, and disable support access when it is no longer required.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	The customer must define and enforce who can access its tenant and at what privilege level.
	GV.RM — Risk Management Strategy	Ownership of the access boundary is a risk decision that belongs to the customer.
Recommendation — Enforce role-based, tenant-specific access approvals and periodic entitlement review. Assign access decisions to the customer’s risk appetite and document the approved operating boundary.
NIST Zero Trust (SP 800-207)	SP 800-207 — Zero Trust Architecture	Tenant access should be continuously evaluated and limited by explicit policy rather than provider convenience.
Recommendation — Require explicit policy checks for every support access path and keep trust narrowly scoped.

Practitioner Guidance

What to prioritize: Put the customer on record as the approver of tenant scope, role scope, and exception scope. The MSSP should request and operate access, not authorise its own reach.

What to verify: Confirm that every viewer or editor entitlement maps to a named tenant, a named purpose, and a review date. If any of those three are missing, the permission is too vague to trust.

Common mistake: Treating “managed service” as justification for standing access. Managed does not mean open-ended; it means delegated work under customer-defined constraints.

Practitioner takeaway: The ownership question is solved correctly only when the customer owns the boundary and the MSSP owns disciplined execution inside it, because that is the only split that preserves both accountability and operational usefulness.