What breaks when MSPs do not rotate passwords and revoke access after staff leave?

Why MSP offboarding breaks the access model

When a former staff member still has valid credentials, the MSP is no longer operating on current employment status, it is operating on stale trust. That breaks the basic assumption that access follows role, need, and ownership. In practice, the same account may still open client portals, cloud consoles, ticketing systems, password vaults, or admin tools long after the relationship has ended.

That failure is not just administrative. It means the control plane still recognises someone who should no longer be authorised, so every downstream system that accepts those credentials inherits the same mistake. The weakest point is often not the password itself, but the lack of coordinated revocation across all systems that were reachable through it.

For offboarding to work, the MSP has to treat departure as a lifecycle event, not a local password change. If access is removed in one place but not everywhere, the remaining path becomes the active one.

What lingering passwords actually enable

Rotating passwords after staff leave does more than close a single account. It cuts off reuse, session continuation, and opportunistic access from any environment where the old secret was cached, mirrored, or copied. Without that rotation, the former user may still authenticate through shared tools, synchronized password managers, browser autofill, API clients, or long-lived tokens tied to the same trust relationship.

This is why prompt revocation matters as much as password change. A revoked employee can still act under old privileges if the password remains valid, if linked secrets were not updated, or if secondary access paths were never tied back to the individual. The result is lingering exposure that can persist even when the original human account looks inactive.

Organisations should also expect accountability to degrade. Once access outlives employment, audit trails no longer clearly distinguish authorised administration from stale access, which makes later investigations and client assurance much harder.

Why client trust and operational hygiene both suffer

MSPs are judged on their ability to protect many customers through a shared operating model. When access is not rotated and revoked, one departed staff member can become a residual trust anchor across multiple client environments. That weakens segmentation, increases the blast radius of a missed deprovisioning step, and makes the MSP look less reliable even if no abuse is detected.

The problem is amplified when the same credential pattern is reused across systems. A password change in the vault does not help if the underlying account, SSH key, API token, or cloud login was left active elsewhere. Good hygiene therefore depends on inventory, ownership, and coordinated removal, not just on the act of changing a secret.

For MSPs, this is also a governance issue. If access paths are not promptly closed, the organisation cannot credibly prove least privilege, timely offboarding, or controlled delegation to clients and internal teams.

Risk and Threat Considerations

Residual access after staff departure creates a straightforward but serious exposure: a credential that should be dead may still be accepted by client systems or internal tooling. If the former user is malicious, compromised, or simply careless, that stale access can be used for unauthorised administration, data access, or lateral movement before anyone notices.

Failure mechanism: Offboarding is incomplete when password rotation, token invalidation, and access removal are not coordinated across every system that the departing worker could reach. Shared vaults, cached sessions, and duplicated secrets let the old access path survive the personnel change.

Impact: The MSP inherits preventable account-takeover risk, weaker incident attribution, and broader customer exposure because old credentials can remain valid after employment ends.

Practitioner Guidance

What to verify: Confirm that offboarding removes access at the identity source, in the password manager, and in every downstream system that may have received the secret. If one control point is changed but another still authenticates the user, the revocation is not complete.

Decision rule: If the departing staff member had any path into client production systems, treat the event as a full credential and session revocation exercise, not a simple password update. Where access was shared or reused, force rotation on every dependent secret rather than assuming one reset is enough.

Practitioner takeaway: The real test is whether any former employee can still authenticate anywhere they should no longer reach, because one surviving access path is enough to defeat the offboarding control.

Related resources from NHI Mgmt Group

• What breaks when teams do not revoke social media access quickly after staff or agencies leave?
• What breaks when employees share passwords or keep access after they leave?
• What breaks when organisations do not continuously revoke SaaS access after role changes or offboarding?
• Why does a completed access review still leave organisations exposed after reviewers revoke access?