Who is accountable if an MSP onboarding workflow creates excessive access?

Why This Matters for Security Teams

MSP onboarding is not just a provisioning task, because it often becomes the moment where excessive access is normalised and left in place. When a client supplies directory data, that does not transfer accountability for how access is requested, approved, scoped, or removed. The MSP is still responsible for the access model it operates, especially where privilege boundaries affect shared tenants, admin portals, and remote support tooling. Current guidance in the OWASP Non-Human Identity Top 10 treats over-privileged identities as a recurring failure mode, not a one-time mistake.

NHI Management Group research shows the scale of the problem: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs from NHI Mgmt Group. That is directly relevant to MSP onboarding because over-access created at onboarding often survives long after the original business need has changed. In practice, many security teams encounter privilege creep only after a client audit, incident review, or contract dispute rather than through intentional governance.

How It Works in Practice

Accountability should be designed around the workflow, not around who technically entered the data. A secure MSP onboarding model assigns clear ownership for approval, implementation, exception handling, and revocation. The MSP may consume the client’s directory source, but it must still validate whether the requested access is appropriate for the service being delivered. That means a workflow should define the access purpose, the minimum required role, approval authority, and expiry conditions before provisioning occurs.

Practitioners increasingly separate identity source from access authority. The directory can provide attributes, but authorisation should be evaluated against MSP policy at request time. This aligns with Zero Trust thinking and the OWASP Non-Human Identity Top 10, which emphasises least privilege and lifecycle control for non-human access. For MSP workflows, that usually means:

• documenting who can approve elevated access and under what conditions
• using just enough privilege for the support task, not a reusable broad admin role
• setting expiry or review checkpoints for every exception
• maintaining revocation authority even when the client owns the source directory
• logging who approved, who provisioned, and who validated the access

Where possible, access should be time-bound and tied to a business ticket or service event, rather than permanently assigned to an onboarding group. The 52 NHI Breaches Analysis is useful here because it reinforces a consistent pattern: identities and permissions that outlive their original purpose create avoidable exposure. These controls tend to break down in heavily customised MSP stacks because multiple customer-specific exceptions make revocation workflows inconsistent and difficult to audit.

Common Variations and Edge Cases

Tighter onboarding controls often increase friction for service delivery, requiring organisations to balance speed against verification. That tradeoff is real for MSPs that support urgent incidents, shared admin models, or legacy client environments where access has historically been broad. Current guidance suggests that exceptions are acceptable only when they are explicit, time-limited, and reviewable, but there is no universal standard for exactly how much privilege an MSP should retain in every scenario.

One common edge case is the client-owned directory with MSP-managed administration. In that model, the client may be the data owner, but the MSP still owns the operational decision to accept, scope, and keep access active. Another edge case is delegated administration across multiple tenants, where a single onboarding workflow can silently create cross-customer overreach. In those environments, the best practice is evolving toward separate approval paths for baseline access and elevated access, with periodic recertification by both parties.

Operationally, the most important question is not who supplied the directory input, but who can prove that access was necessary, approved, and later removed. When revocation is ambiguous, accountability usually lands with the party running the workflow because that party controlled the mechanism that created the excess access.

Related resources from NHI Mgmt Group

• Who is accountable when an MSP-managed access path is abused?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?
• Who is accountable when automated deprovisioning does not happen after access review?