After a role change or departure: revoke old sessions and download access
Revocation is complete only when the agreed access paths enforce the new state, including sessions and files created before the administrator made the change.
On this page5 sections
Disabling an employee account starts the revocation process; it does not prove that every existing access path has stopped. Address active sessions, API access, cached authorization, background work and file retrieval, then retest using the original signed-in state. Agree the starting time, the permitted enforcement deadline for each path and what happens if propagation fails. A rejected new login alone is not evidence that old access has ended.
Define whether you are revoking identity, a role or a project grant
A departure usually requires closing overall access. A role change may remove the former department's records, approvals and export rights while preserving the new role. An expiring project grant may affect only one scope. Keep the initiator, approval basis, effective time, affected systems and successor in one revocation record instead of treating every event as account deletion.
Retain stable identity references for authorship and previous actions. Preventing login should not erase responsibility for business records. Transfer outstanding work through the business process. The access scope can follow the existing group organization and tenant permission design; this article concerns how that change reaches entry points already in use.
Trace one revocation event across five locations
| Location | Existing access to test | Evidence to retain |
|---|---|---|
| Account and identity provider | New login and token renewal | Disable result and application receipt |
| Sessions and APIs | Open pages and previously issued tokens | Denial or the revised data scope |
| Authorization caches | Old scope on different application nodes | Permission version, refresh result and deadline |
| Background work | Queued or running exports | Reason for continuing, stopping or isolating results |
| File retrieval | Previous jobs, previews and saved links | Reauthorization, expiry or explicit denial |
The OWASP session management guidance requires server-side session invalidation rather than merely clearing a browser cookie. Select server-side invalidation, permission-version checks or other verifiable controls according to the application's session and token mechanism. Do not infer that disabling a central identity automatically terminates every application session.
A file link can have a separate lifetime
A business endpoint that checks authorization on every download is different from issuing a direct storage link in advance. If a service account signed that link, disabling the employee may leave the signing credentials unchanged. Where prompt revocation is required, determine whether controlled downloads, short-lived links or storage policies are needed, then test previously issued links against the agreed deadline.
The Amazon S3 documentation describes presigned URLs as bearer tokens whose validity depends on the signing credentials. It also explains that a download begun before expiry can continue afterward. This is a product-specific boundary. Distinguish newly initiated downloads from transfers already underway, and do not promise remote recovery of copies already downloaded locally.
Retest in chronological order using the old session
- Sign an authorized test account into two relevant device types. Open a former-department record, submit an export and retain an unused download link.
- Record when the administrator confirms revocation. Keep the original pages and sessions open rather than signing out first.
- Repeat queries, approvals, pagination and downloads. Test renewal and a new login, recording response times and the actual data returned.
- Inspect what happened to background output. Confirm that the successor can continue the work and that the former account cannot recover a file through job history.
Define the boundary for operations already executing. Business and development owners should decide whether an approval accepted before revocation completes or is interrupted. Revocation should not silently reverse an established business event. Any correction needs the corresponding business cancellation process and its record.
Deliver evidence of enforcement, not only an administrator log
The acceptance record should link the revocation identifier, permission version, affected systems, test requests, actual denial times and unresolved items. If a node misses the change, identify how that failure is detected, retried and assigned for manual handling. An administrator's successful action log proves only one step in the chain.
Include these tests in the software development delivery scope (Chinese) and connect them to the permission, security and audit acceptance approach. Following a transfer, also verify that necessary new permissions work. Blocking everything is not evidence of a correctly completed role handover.