Why former employees' accounts linger: separate disablement, session revocation, and data handover

EDITORIAL PRACTICE

Offboarding is a sequence of closures, not a deletion

If the goal is framed as 'delete the account', the dangerous window disappears from view. An account ceasing to exist and a person ceasing to reach business data are not the same event. The risk lives in the reachability that remains before deletion, so the design work is deciding which paths close, in what order, and when.

The closure sequence has four layers: stopping sign-in at the identity platform, revoking issued sessions and tokens, deprovisioning apps that are not integrated with the platform, and collecting devices and physical access items. Each layer has different owners and different times-to-effect, so they must be listed and ordered explicitly.

There is also a gap between HR confirming a departure and IT executing the closures. If the last day is a Friday night and IT acts on Monday, the weekend is fully exposed. Define a 'pre-closure' that can run when notice arrives and a 'main closure' for the departure day, so the result does not depend on the weekday or on one person's presence.

Urgency branches the procedure too. A normal voluntary departure and a departure involving compromise or discipline demand different speeds. Microsoft's guidance places compromise and termination in the same 'revoke all access' context; keep a standard path and an emergency path, with trigger conditions agreed with HR in advance.

Put the whole sequence on one reusable checklist with executor, time, and verification fields per item. Moving offboarding from memory-based work to a repeatable procedure is the premise of everything that follows.

Closure and preservation do not conflict. Stopping access and preserving business data are separate decisions; where litigation or audit holds apply, issue the preservation instruction alongside the closure. Writing that distinction at the top of the procedure keeps the floor from stalling on 'delete or keep'.

Assign owners inside the sequence as well: who receives the HR notice, who operates the platform, who touches each SaaS admin console, who receives the devices. In a small organization one person wears several hats, but the items that leak are the ones whose owner was ambiguous. Make the owner field mandatory on every checklist row.

This article does not walk through one platform's console clicks. Terminology and operations differ per platform, but the skeleton — separate what must stop by layer, assume a time-to-effect, and manage the non-integrated remainder by ledger — transfers. Read it in your own platform's vocabulary.

Sources: [1]

EDITORIAL PRACTICE

Disabling sign-in and revoking sessions are different operations

Disabling an account at the identity platform stops new sign-ins. It does not necessarily kill sessions that were alive at that moment, which is how 'the login page rejects them but the open app still works' happens. Disablement and revocation belong on separate lines of the procedure.

Microsoft's procedure shows blocking sign-in and choosing 'Revoke sessions' as distinct actions. The basic pattern is a set of three: disable sign-in, revoke refresh tokens, and disable the user's registered devices. Treating any one of them as completion is how offboarding incidents happen.

Sessions an application issued itself may not be revocable from the platform side. The guidance is explicit that to revoke a session token, the application must revoke access based on its own authorization policies. For core business apps, maintain per-app revocation steps instead of assuming the platform covers everything.

Password reset has a role as well: combined with disablement, it cuts credential reuse. In hybrid environments the guidance anticipates replication delay, so know your own sync cycle and write the 'disabled in cloud, still valid on-premises' window into the procedure.

Record the evidence: the execution times of disablement and revocation, next to the user's last sign-in time. If a question arises later about post-departure access, the presence of that record decides how fast the investigation goes. Note where the logs live and how long they are kept.

In an emergency the order changes: if compromise is suspected, disable and revoke first, and run preservation in parallel, before handover or notifications. Writing the different 'first move' for standard and emergency paths into the procedure removes hesitation on the day.

Verify revocation actively where possible: after closure, test that sign-in with the departed account is refused and that existing sessions in core apps are actually terminated, and record the result. Judging 'stopped' from an admin console display alone is where verification quality is decided.

Sources: [1]

EDITORIAL PRACTICE

Token lifetimes create a window where access still works

Even after revocation, access does not always drop to zero instantly. The guidance warns that in some scenarios, there could be a period between the initiation of access revocation and when access is effectively revoked. That period is the remaining lifetime of already-issued tokens: Microsoft Entra ID access tokens last for 1 hour by default, and access can continue on an existing token during that window.

Without this understanding, teams misread the situation twice over: treating expected residual access in logs as an incident, or waving through a real anomaly as 'probably the time lag'. Write the expected time-to-effect per platform into the procedure so verification timing and judgment criteria stay stable.

The effect also varies by application type. The guidance separates applications using access tokens, which lose access at token expiry, from applications using session tokens, whose existing sessions end at token expiry and depend on synchronization frequency with the platform. Record, per core app, which type it is and how long closure takes.

Apps supporting Continuous Access Evaluation can reflect revocation in near real time. Inventorying which of your core apps support it draws the line between 'safe for instant-stop scenarios' and 'assume a lag'.

Monitor with the lag in mind: watch the departed user's sign-in attempts and access closely for a defined period after departure. Access that continues beyond the expected window is not lag; it is an undiscovered path. Defining the re-investigation trigger by time keeps verification honest.

Prepare the explanation for stakeholders too. 'They could still see mail for a while on the last day' can be normal behavior of the mechanism; sharing the existence of the lag in advance prevents confusion and unnecessary escalation.

Record the agreed handling of the lag with the relevant departments. If complete instant cutoff on departure day is mechanically impossible in some range, share that range and the compensating monitoring with HR and agree it in writing. If the question 'why wasn't it stopped immediately' comes later, the technical premise and the agreement protect the organization.

Sources: [1]

EDITORIAL PRACTICE

Non-integrated SaaS is stopped by a manual-work ledger

SaaS integrated with the identity platform inherits closure through disablement and automatic provisioning. Microsoft recommends deploying an automated provisioning and deprovisioning solution, and notes that Microsoft Entra app provisioning typically runs automatically every 20-40 minutes. The ledger of SaaS apps should record integration status and propagation interval as attributes.

The problem is everything not integrated: tools a department contracted on its own, tools that began on a free tier, legacy systems outside the platform's scope. Unless someone opens each admin console and stops the user, access continues after departure. You cannot stop what is not in the ledger; offboarding quality is decided by the quality of the everyday SaaS ledger.

The ledger should record, per tool: owner/administrator, integration method, deprovisioning method, who performs the offboarding action, and where the data lives. For manual tools, link the offboarding checklist to the ledger row and record execution time back on the checklist, so the record runs in both directions.

Even where the stop itself is manual, automating the trigger helps: the guidance points to automated ticket creation for apps that do not support automatic deprovisioning. If the fact that a stop is due is captured mechanically, manual execution leaks far less.

Watch the administrator problem too: in department-contracted SaaS, the admin is often the departing person or a single department member. Record where admin rights sit and hand them over as part of the same offboarding, so 'the person who could stop it has left' never happens.

Keep improving the ledger with periodic reconciliation against invoices and card statements, SSO usage logs, and an intake flow for new tools. If every departure discovers an unlisted tool, the problem is not offboarding; it is intake governance.

A mechanical diff between the SSO app list and the ledger is an effective maintenance device: apps registered in SSO but missing from the ledger, and ledger entries that vanished from SSO. Putting that diff report into the IT routine keeps the ledger from being something repaired in a panic only at departure time.

Sources: [1]

EDITORIAL PRACTICE

Decide data handover before you stop access

Before stopping access, decide where the person's data goes: mail, documents, customer records, in-flight project files. After the person leaves, the means to discover what exists where is itself diminished. As soon as notice arrives, agree with the manager on three buckets: hand over, preserve, and safe to discard.

Handover mechanics differ per data type: move to shared drives, transfer ownership to a successor, or grant time-boxed delegate or forwarding access. Unbounded forwarding and sharing create a continuing channel for a departed person's information, so every grant gets an expiry and an end procedure.

Draw the line between personal and business content. Blanket-handover of private files and personal correspondence creates privacy problems of its own. Fix the in-scope range by company policy in advance, and route ambiguous cases to HR or legal rather than floor judgment; that is what prevents later disputes.

Deletion comes after handover and preservation complete. Set a retention period during which the account is kept in a sign-in-disabled state, then delete and process data finally. Keeping the deletion date different from the departure date prevents both handover gaps and preservation gaps.

Verify completion from the receiver's side: the successor can actually open the files, read the customer history, and identify the latest version of in-flight work. 'Sent' is not done; 'usable' is done.

Customer-facing continuity is easy to forget: notifying clients whose contact person left, reassigning shared mailboxes, handing over scheduled meetings. IT's closure sequence and the business handover sequence can live in different tables, but review them together at least once per case.

Handover should include automations running under the person's name: scheduled jobs, shared auto-replies, queued sends. These keep running after the person leaves and cause incidents and mis-sends. Add a checklist row, before account closure, that inventories 'things that keep moving under this name'.

Sources: [1]

EDITORIAL PRACTICE

Devices and physical keys are collected against the IT ledger

Digital closure does not remove data sitting on a loaned device. Device return, handling of on-device data, and wiping form the physical layer of offboarding. The guidance lists resetting Intune-managed devices and wiping corporate data from managed apps as removal mechanisms, while noting that an offline device still has access to locally stored data.

The return list is wider than laptops: entry badges, security keys, loaned peripherals, paper keys. Reconcile the IT ledger with the facilities loan ledger so nothing is missed. Authenticator hardware such as security keys needs both sides handled — physical return and deregistration on the platform — as a pair.

For personal devices used for work, the answer is separation rather than collection: define by policy whether only the corporate data area is wiped or app registrations are removed. Without a policy settled in advance, departure day turns into a negotiation over a personal phone and the whole process stalls.

Pre-decide the unreturnable cases: remote workers whose return shipment slips, reported loss, no contact. Return deadlines, remote-wipe triggers, and loss reporting steps, listed as patterns, turn the day's judgment into choosing which pattern applies.

Reuse of returned devices closes the loop: standardize initialization and reissue so no predecessor data or registrations carry over. The end of one offboarding is the start of the next onboarding.

Align return records with asset records: device serial, return date, wipe date, reissue destination. Double-managing state in both the offboarding checklist and the asset ledger invites inconsistency; let the checklist hold references and keep the state itself in the asset ledger alone.

Sources: [1]

EDITORIAL PRACTICE

Make post-departure residue checks a standing routine

After a case closes, schedule a re-verification that everything really shut: identity-platform account state, member lists of core SaaS, password changes for shared accounts, authenticator deregistrations, and leftover forwarding rules. A check on the day and a check later have different value.

Shared accounts and service logins do not end with personal-account closure. Credentials a departed person knew should be rotated on departure as a principle. Discovery is hard, but at minimum enumerate shared credentials that touch administrative privilege and rotate them every time.

Time the re-checks after propagation completes — for example the next business day and one week later. Leaks found at the second check are ledger defects, so fix the ledger rather than blaming the operator; converting leaks into system improvements is the real purpose of residue checks.

Quarterly, inventory all departed users' account residue in bulk: accounts still enabled, accounts with no owner, long-unused accounts. Offboarding leaks often surface only in this periodic sweep, whose results should feed back into the ledger and the procedure.

Keep the case record: whose departure, which actions, when, verified by whom. Audits and incident investigations ask for exactly this unglamorous record, and a reusable checklist naturally accumulates it.

Report residue-check results as numbers leadership can see: how many leaks were found in the quarter and which ledger attributes were missing. Offboarding is unglamorous work, but leak patterns are a direct picture of SaaS governance, and numbers make the case for investing in the ledger.

The maturity of offboarding is measured not by special tooling but by whether this re-verification keeps running without friction.

Sources: [1]