A former employee account can still provide a trusted foothold if it is not fully deprovisioned or if it can reach downstream administrative functions. In a multi-tenant environment, that access may be enough to generate session tokens, pivot into customer accounts, and scale a single compromise into many separate incidents.
Why former employee access becomes a cloud-wide trust problem
A former employee account is dangerous in a multi-tenant cloud service because the account may still be linked to administrative workflows, support tooling, federation paths, or privileged APIs even after employment ends. If that trust is not removed quickly and completely, a single valid login can become a standing path into systems that serve many customers.
The systemic risk comes from the way cloud tenants share the same underlying control plane while relying on strong identity separation to keep customer data and actions isolated. Once an old account can still authenticate, any exposed permissions, inherited roles, or token-issuance capability can be used far beyond the original user’s intended scope.
How one stale account can turn into many incidents
Compromise is not limited to whatever the former employee could see as a normal user. In practice, stale access often reaches more valuable paths such as support consoles, break-glass workflows, admin APIs, or approval chains. That makes it possible to generate session tokens, impersonate other principals, or move from a low-value account into customer-facing systems.
In a multi-tenant service, the blast radius is amplified because one compromised account can interact with shared platform functions that touch many tenants. Microsoft OAuth Breach illustrates how abuse of a trusted application or identity path can create persistent access, while Storm-2949 Azure Breach shows how one cloud identity compromise can expand into a tenant-wide incident. The 52 NHI breaches Report is useful background for the repeatable failure pattern: a trusted credential or token becomes the pivot point for wider abuse.
Where the former employee account still has privileged reach, the attacker does not need to break tenant isolation directly. They only need a path into the service’s own administrative fabric, then the platform does the rest. That is why one neglected account can scale into many separate customer-impacting events without the attacker needing a separate foothold for each tenant.
What to verify before you treat offboarding as complete
What to verify: Confirm that termination removed all interactive logins, API paths, delegated access, refresh tokens, and federation trust relationships, not just the primary directory entry. Also verify that any surviving service desk, emergency, or automation access cannot be used to mint new sessions or change tenant-level permissions.
What changes at scale: The more tenants, integrated tools, and support pathways a cloud service has, the more important it becomes to prove that no leftover account can reach shared control-plane actions. At scale, weak offboarding is not a single-account hygiene issue, it becomes a platform exposure issue.
Practitioner takeaway: Treat former employee access as a control-plane risk until you can demonstrate that every path for authentication, token issuance, and privilege inheritance has been removed or conclusively bounded.
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 surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Former employee accounts become systemic risk when credentials or tokens remain valid. |
| NHI-03 — Privilege and Authorization | Stale accounts are dangerous when they can still reach admin or tenant-wide functions. | |
| NHI-05 — Lifecycle and Rotation | The question hinges on offboarding failure and continued validity of old access paths. | |
| Recommendation — Revoke lingering credentials, tokens, and secrets immediately after offboarding. Reduce inherited access and enforce least privilege on all surviving account paths. Make offboarding revoke sessions, keys, and trust links as a mandatory lifecycle step. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | This risk is driven by incomplete deprovisioning and lingering authentication paths. |
| PR.AA-05 — Least Privilege Access Permissions | Systemic exposure grows when a stale account retains more privilege than it should. | |
| Recommendation — Implement timely deprovisioning and access revocation for departed users. Limit dormant and support accounts to the minimum access needed. | ||
| CIS Controls v8 | 5 — Account Management | Former employee access is fundamentally an account lifecycle and revocation problem. |
| 6 — Access Control Management | The account becomes systemic risk when it can still reach shared cloud functions. | |
| Recommendation — Automate account disabling, token revocation, and periodic access review after exit events. Enforce role removal and deny unused access paths across shared services. | ||
| ISO/IEC 42001:2023 | 4.2 — Understanding the needs and expectations of interested parties | Multi-tenant cloud services must account for tenant trust and offboarding obligations. |
| Recommendation — Define offboarding and access boundaries as part of governance expectations for the service. | ||
Related resources from NHI Mgmt Group
- Why does multi-account cloud create risk even when the architecture is intentional?
- Why do service account and API key exposures create outsized cloud risk?
- Why do stale access tokens and service account keys create outsized risk in cloud infrastructure environments?
- Why do exposed cloud service account keys create such a high operational risk when they are used for large-scale automation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
