Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Workforce and services marketplace platform |
| Company Size | Roughly 300 employees, with contractors and interns joining and leaving |
| Cloud Environment | AWS, production and non-production accounts onboarded |
| Identity Provider | Google Workspace, feeding AWS IAM Identity Center |
| Access Model | Just-in-time requests for cloud and database access |
| Compliance | ISO 27001 and SOC 2 |
| Concern | What happens to open grants, pending requests, and old keys when someone leaves |
| Focus Area | Joiner-mover-leaver for time-boxed access and IAM hygiene |
The Situation: JIT Handles the Window. Who Handles the Person?
Just-in-time access solves a clear problem: no one holds production rights when they are not using them. A request is approved, a window opens, and it closes on its own.
That model is strong, but it quietly leans on an assumption: the person asking is still who they were when they were approved. In real organizations that assumption breaks often. Engineers leave. Contractors finish and roll off. Interns end their placement. People move teams and no longer need the access they requested last quarter. Each of these events happens in the identity provider, in this customer’s case Google Workspace, and usually through an HR-driven process that never touches the cloud account directly.
This team asked a precise question that auditors also ask: if an identity is deactivated, what happens to the requests and grants that identity still has open? Specifically, they wanted pending and active JIT requests to end when the identity became inactive, mirroring how the database side already behaves. A session scheduled for a future window, a long-duration grant approved before someone resigned, or an approval waiting in a queue should not outlive the person it was meant for.
Alongside that sits the older, less glamorous layer of identity hygiene. AWS accounts accumulate IAM users, access keys, and service accounts over years. A key created for a one-off task is still active. A service account is mixed into a list of human users. A role nobody remembers is still assumable. Time-boxed access governs the new path, but the old path remains until someone cleans it up.
The Core Tension
Offboarding in most companies is a checklist run by people: disable the directory account, revoke the VPN, remove the repositories. Cloud access sits awkwardly in the middle. IAM users and access keys do not disappear when a directory account is disabled. Federated sessions end, but long-lived keys, scheduled grants, and open approvals can survive.
JIT reduces the amount of standing access, but it also introduces new state: requests, approvals, schedules. If that state isn’t tied to the identity’s lifecycle, you replace one kind of lingering access with another. The question is not only “is access time-boxed?” but “is it bound to a person who is still entitled to it?”
Where the Gaps Were
Open Requests Outliving Their Requesters
A request created before someone left, or approved for a future window, could still be live after the person’s directory account was disabled. In the narrow case, the grant would fail at sign-in because the identity is gone. In the wider case, a grant to a shared or federated role could still be exercised through another route.
Approvals Waiting on Someone Who Had Moved On
Approval queues that reference a departed approver stall requests. Engineers wait, then work around the process, which defeats the point of having one.
Stale Keys and Unused IAM Users
Long-lived access keys, inactive for months, remain valid. IAM users belonging to people who left are still present. Service accounts sit in lists of human principals and are reviewed by nobody. These are classic findings in an ISO 27001 or SOC 2 access review.
Mixed Human and Non-Human Identities
When service accounts and people appear in the same lists, reviewers cannot tell which entries should have a manager, an end date, and a justification, and which are automation that needs different controls.
Evidence of Clean Offboarding Was Manual
Proving to an auditor that a leaver’s access was fully removed meant checking several systems by hand and assembling screenshots.
How Cloudanix Addresses This Situation
Grants Follow the Identity’s State
Cloudanix JIT works at the identity layer. When an identity is deactivated or removed in the identity provider, the JIT system treats it as inactive: its open and scheduled requests are terminated rather than left to run. This means a departing engineer’s future-dated grants are cancelled, an unused approved window cannot be activated, and an approval that was pending for that person is closed. The behavior is the same principle the database access flow already follows, now applied to cloud access requests as well.
Validity Checks Before Access Is Changed
Before a scheduled change or downgrade runs, the system checks that the underlying entity is still valid. If the user, group, or account the request refers to no longer exists or is no longer active, the action is stopped and recorded instead of failing silently or applying to the wrong target.
Leaver Process Becomes Short
With JIT as the route to production, a leaver’s offboarding reduces to the step that already exists: disable the directory account. There’s no standing permission-set assignment to find and remove, because none persisted. The directory change plus the termination of open requests closes the loop.
CIEM Sweeps the Legacy Layer
For the older layer of IAM users and keys, Cloudanix CIEM provides the inventory and signals:
- Inactive access keys: Keys unused beyond a threshold are flagged.
- Unused IAM users and roles: Identities with no recent activity are surfaced.
- Human versus non-human separation: Service accounts are identified and reviewed as non-human identities, instead of mixed into human lists.
- Over-privilege: Permissions granted but never used are highlighted for right-sizing.
Teams can then remove, rotate, or convert these to short-lived access. Where a workload truly needs a credential, Agentic JIT can replace the long-lived key with a short-lived one.
Evidence Without Screenshot Hunts
Every request, approval, termination, and revocation is recorded with the identity involved and stored in the customer’s own account. For an auditor asking “show me what happened to this person’s access when they left,” the record shows the date their identity was deactivated, the requests that were closed as a result, and the keys and IAM users that were reviewed.
What a Clean Leaver Looks Like
- HR triggers offboarding. The user is suspended in Google Workspace.
- The identity is marked inactive in the JIT system.
- Pending requests from the user are cancelled; scheduled future grants are removed.
- Any approvals waiting on the user are re-routed to a delegate or flagged.
- Active sessions end at their natural expiry, or an administrator revokes them immediately.
- CIEM flags any IAM user, access key, or role associated with the person for removal.
- The audit trail shows each step with timestamps.
For movers, the same logic applies in smaller form. When a person changes teams, group membership changes in the directory, and their ability to request roles tied to the old group changes with it.
What to Know Before You Start
- Termination depends on the identity provider reflecting the change. Offboarding processes that update HR systems but not the directory will not trigger it, so keep the directory as the source of truth.
- Sync is not instant. After directory changes, allow time for the data to refresh in Cloudanix. For an urgent leaver, an administrator can also revoke access directly.
- Revoking an active database session takes up to about 15 minutes to take effect, so for high-risk departures, combine revocation with a directory suspension.
- Cloudanix flags stale keys and unused users but does not delete them automatically. Removal is a decision for your team, which matches the preference many security leads have for human review before changes.
- Offboarding the person does not remove credentials that were copied elsewhere. Short-lived credentials limit that exposure; long-lived keys remain until rotated.
Platform Impact
| Dimension | Before | After |
|---|---|---|
| Open requests when someone leaves | Could remain live | Terminated with the inactive identity |
| Scheduled future grants | Could still activate | Cancelled |
| Standing permission assignments to remove | Manual hunt | None; access was never standing |
| Stale keys and unused IAM users | Found at audit time | Flagged continuously by CIEM |
| Human vs service accounts | Mixed | Separated and reviewed as non-human |
| Offboarding evidence | Manual screenshots | Dated trail of requests, closures, and reviews |
Key Outcomes
- ✅ Access Ends With the Identity: Open and scheduled requests close when the person is deactivated.
- ✅ Short Offboarding Checklist: Disable the directory account; there is no standing access to hunt down.
- ✅ Legacy Hygiene Under Control: Stale keys and unused IAM users surfaced by CIEM.
- ✅ Cleaner Reviews: Human and non-human identities reviewed separately.
- ✅ Audit Evidence on Demand: A dated record of what happened to a leaver’s access.
When Someone Leaves, What Happens to Their Access?
If your answer depends on a checklist and someone remembering it, your offboarding is only as strong as the last person to run it. Cloudanix binds time-boxed access to the identity’s lifecycle and surfaces the stale keys behind it.
Book a Free Assessment to see leaver handling and CIEM hygiene on your own AWS accounts in under 30 minutes.
Related Resources
- CIEM for Multi-Account AWS: Making Sense of Read and Admin Identities Without JIT
- Why Excel Is the Biggest Security Risk in Your User Access Review
- Closing the Audit Trail Gap: From Missing Logs to Complete JIT Access Auditing
- Mastering Third-Party Access with the Just-In-Time Approach
- What is Zero Standing Privilege?
