TL;DR: A terminated credit union employee allegedly deleted 21.3GB across 20,000 files and nearly 3,500 directories two days after being fired, according to Britive, after retained cloud access left a short but sufficient window for destructive activity. Off-boarding that relies on delayed revocation instead of immediate privilege removal turns resignation and termination into an identity control problem.
At a glance
What this is: This is a cloud off-boarding case showing how delayed revocation and standing privileges can let a terminated employee access and delete corporate data after separation.
Why it matters: It matters because IAM, PAM, and NHI lifecycle teams need off-boarding that removes access immediately across cloud environments, not after the damage window has already opened.
Context
Off-boarding is the point at which identity governance either closes access cleanly or leaves a residual path into systems and data. In cloud environments, that failure is amplified because users may hold standing access across multiple applications and file stores rather than a single bounded system. The article’s core issue is not revenge as a motive, but the governance gap created when revocation lags separation.
For identity teams, the lesson applies across human accounts and other non-human access paths that survive longer than they should. When privileges remain active after termination, the programme is no longer managing joiner-mover-leaver risk as a lifecycle control. It is managing a breach window.
Key questions
Q: What breaks when offboarding does not remove cloud access promptly?
A: When offboarding does not remove cloud access promptly, former employees or contractors may retain a direct path into sensitive resources and data. The failure is operational as much as technical: teams may assume access has ended, while permissions remain active across cloud services, roles, and identities. That gap leaves an open door until every standing entitlement is discovered and revoked.
Q: Why do standing cloud privileges increase insider risk after termination?
A: Standing privileges keep access alive by default, so an ex-employee does not need to obtain anything new to act after separation. The risk is not hypothetical abuse of future access; it is continued use of existing rights that were never removed fast enough. That makes lifecycle timing the security control that matters most.
Q: How do security teams know whether offboarding is actually working?
A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.
Q: When should organisations replace standing privilege with just-in-time access?
A: Organisations should replace standing privilege with just-in-time access whenever elevated access is not required continuously. JIT reduces the time window in which credentials can be abused, especially for admin tasks, break-glass use, and sensitive automation. It works best when paired with approval, expiry, and logging so temporary access does not become another form of standing privilege.
Technical breakdown
Why standing cloud privileges survive termination
Standing privilege means access remains continuously available until someone removes it. In cloud estates, that often spans multiple consoles, file servers, and application permissions, so a terminated user may still retain enough access to browse and act before off-boarding completes. The problem is not just slow process flow. It is the architectural assumption that access can remain open safely between HR termination and IAM cleanup. In practice, that assumption fails when revocation is delayed even briefly and destructive actions can happen inside the gap.
Practical implication: remove standing access from cloud roles and accounts as a termination event, not as a follow-up task.
How delayed revocation turns off-boarding into a breach path
Off-boarding is meant to revoke authentication and authorization together. If credentials remain valid after separation, the former user can still authenticate, reach shared resources, and perform actions that appear legitimate to the platform. That is especially risky when file access is not separately constrained by task, time, or device state. The failure mode is a control-plane lag: the organisation assumes access disappears at the same pace as employment status, but identity systems often update more slowly than the user can act.
Practical implication: tie termination workflows to automated credential revocation and session invalidation across every cloud control plane.
Why zero standing privilege changes the off-boarding model
Zero standing privilege removes permanent access and grants permissions only when needed for a specific task. In off-boarding, that matters because the safest account is the one that cannot be reused after the employment relationship ends. This is a lifecycle control, not just a privileged access feature: if there is no persistent privilege to revoke, the post-termination exposure window shrinks dramatically. The broader lesson is that JIT access shifts security from cleanup speed to access design.
Practical implication: design off-boarding around just-in-time access so terminated identities have no persistent privilege to exploit.
Threat narrative
Attacker objective: The objective was to damage the employer by destroying corporate and customer-related data after termination.
- Entry occurred after termination when the former employee still had valid remote access to the file server and could authenticate into the cloud environment.
- Credential use and access persistence allowed the user to open confidential files before revocation completed, showing that the account remained active during the post-separation window.
- Impact followed when the user deleted 21.3GB of data, including 20,000 files and almost 3,500 directories, causing direct corporate data destruction.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Off-boarding delay is a governance failure, not an administrative inconvenience. The article shows that the real risk is the time between separation and revocation, when a former employee can still act inside the environment. That is a joiner-mover-leaver weakness in cloud identity governance, not merely a HR process miss. Practitioners should treat every minute of residual access as exposure.
Standing privilege is the condition that turns departure into a security event. Access that persists by default creates a breach path the moment trust changes. In cloud environments, that persistence is especially dangerous because permissions are often broad, distributed, and hard to inspect quickly. The practitioner conclusion is simple: permanent access and clean off-boarding do not coexist safely.
Zero standing privilege is the right structural answer for post-employment risk. If access only exists when explicitly granted for a current task, off-boarding stops being a race to revoke dormant rights. That does not eliminate insider risk, but it removes the assumption that inactive accounts can remain harmless until someone remembers them. The operational implication is that lifecycle design must replace cleanup dependence.
Cloud off-boarding needs the same discipline as privileged access governance. This case is not unique to one employer or one platform. It reflects a broader pattern in which identity programmes separate account administration from privilege governance, even though the exposure is created by the combination of both. Teams should therefore review whether JML, PAM, and cloud entitlement controls are actually operating as one lifecycle.
Credential persistence after separation is the failure mode this article exposes. The account remained usable long enough to support destructive access after termination, which means the governance assumption that access ends when employment ends was false. Practitioners should read that as a control-boundary problem: access lifecycle and employment lifecycle were not synchronized.
What this signals
Residual access windows are the real off-boarding risk. Identity programmes still fail when they assume a human departure is an administrative event instead of an access-control event. The practical shift is to measure how long permissions remain usable after separation, then redesign workflows so the answer is effectively zero.
JML and privileged access management cannot be run as separate disciplines. The article’s underlying problem is not just account lifecycle, but the overlap between employment status, cloud entitlements, and destructive privilege. Teams that split those controls end up with gaps between ownership and revocation, which is where insider damage happens.
For practitioners
- Compress termination-to-revocation workflows Trigger access removal from cloud file stores, consoles, and admin paths as part of the separation event, not as a later ticket in the queue.
- Eliminate standing privileges from user access Replace always-on permissions with just-in-time access so former employees do not retain dormant access paths that survive off-boarding.
- Validate cloud off-boarding coverage Check that every application, storage layer, and federated identity connector is included in the revocation workflow and session kill process.
- Review privileged file access separately Audit which users can still reach sensitive file servers after employment changes and confirm that privileged access is removed in the same control path.
Key takeaways
- The article shows how a terminated employee can still do damage when cloud access survives separation long enough to be used.
- The evidence in the case includes 21.3GB deleted across 20,000 files and almost 3,500 directories after termination.
- Immediate revocation, standing privilege removal, and JIT access design are the controls that close the exposure window.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on delayed revocation after employment ends. |
| NHI-05 — Overprivileged NHI | The article links harm to broad standing cloud access that was not needed at rest. | |
| NHI-07 — Long-Lived Secrets | Residual access after separation reflects credentials that remain valid too long. | |
| Recommendation — Map termination workflows to NHI-01 and remove access before the account can be reused. Reduce persistent cloud entitlements and align access scope to current task need. Shorten credential lifetime and revoke any secret that can survive a role change or termination. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle handling is the central operational weakness in the case. |
| Recommendation — Enforce account lifecycle controls so terminated users lose access across every cloud system. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential revocation after termination maps directly to authenticator lifecycle management. |
| Recommendation — Apply IA-5 to revoke authenticators immediately when employment ends. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about access remaining active beyond the allowed lifecycle. |
| Recommendation — Review entitlements continuously and remove access when authorisation no longer applies. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The case demonstrates valid credential use leading directly to destructive impact. |
| Recommendation — Track post-separation access as credential-abuse activity and contain systems before impact escalates. | ||
Key terms
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Off-boarding: Off-boarding is the process of removing a departing user’s access, credentials, and related entitlements from the environment. In mature IAM programmes, it also includes reviewing sessions, shared secrets, delegated roles, and linked non-human identities so that exit events do not leave behind hidden access paths.
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org