They should treat lifecycle events as governed state changes, not manual reminders. That means using one process for joiners, movers and leavers across all clients, then tying revocation and licence reclamation to the same workflow so change is handled at the moment it occurs.
Why MSP access has to move with the client, not around it
For an MSP, access management fails when it is treated as a static account list instead of a living service state. Clients add tools, remove apps, switch vendors, and reshuffle users continuously, so the control point has to be the lifecycle event itself. That is why joiner, mover, and leaver handling should be designed as one governed process, with revocation and licence reclamation tied to the same change.
The practical goal is consistency across tenants and services: when a user changes role, a contract ends, or an application is retired, the access decision should update immediately and predictably. When that does not happen, the MSP inherits stale access, duplicate licences, and fragmented ownership across client environments.
How to operationalise joiners, movers and leavers across many clients
The strongest model is to make lifecycle handling event-driven and centrally governed, then apply it per client policy. That means one intake path for changes, one authoritative record of the current state, and one workflow that can provision, modify, suspend, or remove access without relying on manual reminders or separate spreadsheets for each account type.
IAM and IGA basics are useful here because the MSP problem is not just authentication, it is entitlement governance across changing populations. The same workflow should also support licence reclamation, because access removal and software entitlement recovery are usually the same operational event from the service desk perspective.
For MSPs, the discipline is to separate access reviews and certification from event handling. Reviews are periodic validation; joiner, mover, leaver processing is immediate state change. If those two are mixed, teams either delay removal while waiting for the next review cycle or rubber-stamp access that should already have been withdrawn.
This model also needs to work for non-human access paths. Cloud workload identity guidance matters because client change often includes apps, automations, and service connections that are easy to forget when the team focuses only on user accounts. If the MSP handles those identities separately, revocation becomes incomplete and the retained access survives the human offboarding event.
What breaks when lifecycle control is manual
Manual handling creates three common failure modes. First, revocation lags behind the business change, leaving access alive after a move or exit. Second, entitlement sprawl grows because old permissions are carried forward when a user changes team, supplier, or scope. Third, licence recovery is missed because no one owns the link between access removal and commercial cleanup.
The same weakness shows up when multiple clients are managed by shared operational teams: unless the process records which tenant, application, and role changed, teams can remove the wrong access or fail to remove the right access. In practice, the problem is less about forgetting an individual account and more about losing the relationship between the person, the application, and the client boundary.
That is why the workflow should be designed to close the loop. A change request should trigger the access update, the removal should be confirmed, and the reclaimed licence should be recorded or reassigned. Without that confirmation step, the MSP only knows a change was requested, not that exposure was actually reduced.
Risk and Threat Considerations
When access does not follow lifecycle change, stale privileges become a standing exposure. In an MSP environment, that exposure is amplified because one missed removal can affect several client systems, and a retained service account or user token can outlive the business need that justified it.
Failure mechanism: manual or disconnected offboarding leaves active entitlements, shared accounts, or app access in place after the user or client state has changed, creating a path for unauthorised reuse, overreach, or lateral movement across tenant boundaries.
Impact: the MSP can inherit audit findings, licence waste, and avoidable breach exposure, especially when access is inherited through old assignments, legacy integrations, or overlooked application-specific permissions.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Lifecycle-driven access changes and revocation map directly to account provisioning, modification and removal. |
| IA-5 — Authenticator Management | The question includes ongoing access change, which depends on timely credential and secret lifecycle control. | |
| AC-6 — Least Privilege | Constant client and role changes require permissions to stay narrowly scoped as state changes. | |
| Recommendation — Automate account changes and disablement when joiner, mover or leaver events occur. Rotate or invalidate credentials when access ownership or employment state changes. Recompute entitlements on each lifecycle event and remove excess access immediately. | ||
| CIS Controls v8 | CIS-5 — Account Management | MSP access handling depends on managed account lifecycle, especially joiner, mover and leaver processing. |
| Recommendation — Centralise account lifecycle handling and remove stale access without waiting for manual follow-up. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The subject is access governance across changing users, apps and client environments. |
| Recommendation — Define access rules that change with client state and enforce them consistently. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Constantly changing clients and apps make missed offboarding a direct access-risk mechanism. |
| Recommendation — Tie offboarding events to immediate revocation and verify no lingering access remains. | ||
Practitioner Guidance
What to verify: Confirm that every access change is tied to a lifecycle trigger, not a ticket reminder. The workflow should prove what was revoked, when it was revoked, and whether the associated licence, role, or application entitlement was reclaimed.
Implementation sequence: Start with the highest-risk paths, user departures, role changes, client offboarding, and application retirement. Then extend the same process to automations, integrations, and delegated service access so the MSP does not create a human-only control model.
Common mistake: treating licence management as a finance task and access removal as a separate security task. In managed services, they should be one operational event because the underlying business change is the same.
Practitioner takeaway: The right question is not whether access can be updated eventually, but whether the MSP can prove that change-driven access removal happened at the moment the business state changed.
Related resources from NHI Mgmt Group
- What is the difference between rotating a secret and revoking access?
- How should organisations handle access when employees change roles internally?
- Why do shadow IT apps create identity risk even when users still have valid SSO access?
- How should MSPs centralise identity governance across users, devices, and SaaS apps?