--- title: "Dormant accounts: why offboarding keeps failing" description: "Why leaver processes miss systems, why movers are worse than leavers, and how to build joiner, mover and leaver flows that do not depend on memory." url: "https://nixit.io/resources/dormant-accounts-offboarding/" lang: "en" --- # Dormant accounts: why offboarding keeps failing Ask an organisation how many active accounts belong to people who no longer work there and the honest answer is usually that nobody knows. The number cannot be produced on demand, because producing it would require a complete list of the systems where an account can exist, and that list is not maintained anywhere. This is not a discipline problem. The dependency has to move out of human memory and into a system that emits events. ## Offboarding is an inventory problem A leaver checklist is only as complete as the system inventory behind it, and the inventory is the part nobody owns. Applications arrive through departments rather than through IT: a scheduling tool bought by operations, a design service on a designer's card, a supplier portal opened during a tender. Each one creates accounts. None of them appears on the checklist, because the checklist was written before they existed. Two structural details make it worse. The trigger arrives late, since HR records a termination on its own schedule and IT frequently learns after the final working day. And partial revocation is indistinguishable from complete revocation, because nobody reports access that still works. The only failure anyone escalates is missing access, which trains the whole process to err toward leaving things open. The category that survives longest is access nobody in IT granted. Accounts issued by a customer or a partner inside their own tenant sit outside your directory entirely, so disabling the person centrally does nothing and revoking them means asking another company to act. ## Movers are worse than leavers A departure at least has a date. A role change has none, and it is handled as an addition rather than a substitution: new permissions granted in the first week, old ones left in place because removing them is not on anyone's list and their absence would be noticed while their presence never is. The effect compounds with tenure. After a few internal moves a person carries the union of every role they have held, which is why the broadest access in many organisations belongs to a long-serving analyst rather than to an administrator. Cloning is the multiplier: new starters are provisioned "the same as" an existing colleague, so one over-permissioned account becomes the template for a department. Project access behaves the same way. Rights granted for a migration, an audit or a year-end exercise are granted without an expiry date, and temporary access with no end date is permanent access with a temporary justification. ## Provisioning needs an authoritative source The lifecycle becomes reliable only when it is driven by the system that learns first, which is HR. Hires, role changes and terminations are already recorded there with effective dates. What is usually missing is the path from those records into the directory. Three things decide whether that integration holds. A stable per-person identifier used consistently across systems, because names are not identifiers: they repeat, they change, and they are transliterated differently in different tools. Data quality in the HR record, since a job title typed as free text cannot be mapped to a permission set, which makes a role catalogue, even a coarse one, the minimum viable input. And an explicit fast path for immediate terminations, where waiting for the next scheduled synchronisation is not acceptable, implemented as a documented manual revocation that is tested rather than improvised. Organisations operating in several countries hit a variant of this. Each entity often has its own HR system, its own payroll provider and its own local practice for recording a leaving date, while the identity platform is shared. The realistic approach is to treat each HR system as an authoritative feed for its own population, with one agreed schema, rather than to wait for an HR consolidation programme that may never happen. ## Disabling an account is not revoking access Disabling stops new authentication. On its own it does not invalidate what has already been issued, and this gap is where most of the surprises live. Browser sessions stay valid until they expire. Refresh tokens can extend access for days. OAuth grants the person approved for third-party applications hold their own tokens. Application passwords, personal access tokens and API keys keep working independently of directory state. A VPN profile authenticating with a client certificate works until that certificate is revoked, whatever the account status. Devices enrolled in mobile device management remain enrolled until removed. And anything already synchronised to a personal machine is simply gone. A complete leaver runbook therefore lists session termination, refresh token revocation, withdrawal of application consents, certificate revocation, device deregistration and rotation of any shared secret the person could read from the password manager, as separate steps with separate evidence. ## What SCIM covers and what it leaves behind Applications that support SCIM can be provisioned and deprovisioned automatically. Applications behind SAML or OpenID Connect close by consequence, because disabling the central account removes the only authentication path. Widening these two categories is the highest-value work in the whole programme, since every application moved into them leaves the manual list permanently. The remainder is long and heterogeneous: local accounts in the ERP or warehouse system, applications with their own password store, SaaS subscriptions bought on a corporate card and never registered anywhere, SSH keys left on servers, API tokens, service accounts, VPN profiles, physical badges, and access granted by partners inside systems you do not administer. SaaS sprawl deserves separate attention because it is measurable without much effort. Card statements and expense claims name the subscriptions nobody declared, and single sign-on coverage figures show which of them anyone can log into after a departure. The aim is not to eliminate the manual list. It is to reduce it to a short, named inventory with an owner per entry, kept current by a procurement step that asks how accounts are created and closed in any new tool before it is bought. ## Service accounts and shared credentials This is the hardest category because revocation harms someone other than the person leaving. A credential used by a whole team is not rotated when one member leaves, since rotating it interrupts everyone else, so in practice everyone who ever passed through that team retains access indefinitely. The departure of anyone who knew a shared secret is a rotation event. Where rotation is so disruptive that it never happens, the problem is architectural rather than behavioural, and the fix is to remove the sharing rather than to schedule the rotation more firmly. Three moves make that possible. Give shared workstations individual identity through badge and PIN or short session timeouts, which removes most operational shared logins. Build a service account inventory where each entry has a named owner, a stated purpose and a rotation mechanism, and treat any account with no identifiable owner as a candidate for controlled disablement to find out what stops. Then remove interactive sign-in from technical accounts entirely, using platform-managed identities where the environment supports them, so there is no password left for anyone to know. ## Contractors, agencies and partner access Nobody tells IT when a contractor stops working with you. The relationship ends between two companies rather than through an internal HR event, and agency-supplied staff make this worse: turnover is high and the employment record belongs to the agency. Default expiry is the only control that survives contact with reality. Accounts are created with an end date matching the contract term, extended only on an explicit request from a named internal sponsor, and closed automatically when no request arrives. It is less elegant than reliable notification and it does not depend on it. The same logic applies in the other direction, to accounts your organisation holds in customer and supplier systems. Those need an owner internally and a review, because the other party will not prompt you. ## Privileged access is a separate track Administrative rights do not belong in the same lifecycle as ordinary access. The working model is a vault: credentials checked out on request for a limited window against a recorded reason, rotated automatically after use, with the session logged. An administrator leaving is a different event from a user leaving, and disabling their account does not resolve it. It requires rotating everything they could read: local administrator passwords, service account credentials, network device logins, cloud provider API keys. The same category covers standing vendor access, such as the integrator who installed a system years ago and still holds a maintenance connection that nobody reviews. ## Making access reviews mean something A periodic review turns into theatre easily. A spreadsheet of hundreds of rows with technical group names gets approved wholesale, producing an audit artefact with no operational effect. What changes the outcome is narrowing the scope, splitting reviews per system with business-meaningful descriptions rather than group names, showing last sign-in beside each entitlement so unused access is easy to remove, and treating non-response as removal instead of retention. A periodic reconciliation between the directory and the HR population belongs alongside it, since that is what surfaces accounts with no person attached. ## What an auditor asks for Assessors ask for evidence rather than intent, and the requests are consistent: the list of leavers over a period with the disablement timestamp for each account, so the delay can be measured; the documented joiner, mover and leaver process; access review records naming the reviewer and the date; privileged session logs; and the service account inventory with owners. For organisations in scope of NIS2, access control and privileged account management are named explicitly among the required risk management measures, and ISO 27001 examines the same ground through its identity and access controls. Both are written around demonstrating that the measure works rather than confirming that it exists. ## A practical order of work Start with the system inventory and an owner for each entry, because without it nothing else has a boundary. Reconcile the directory against the HR population next to establish the current position, disabling rather than deleting what has no person behind it and holding it for a retention window, since some of those accounts turn out to be undocumented service accounts. Then wire a single trigger from HR, and extend SSO and automated provisioning across the most used applications to shorten the manual tail. Rewrite the leaver runbook with session and token revocation as explicit steps. Finally bring service accounts under ownership, vault privileged credentials, and start the review cycle once the data behind it is trustworthy enough to act on. Directory consolidation, lifecycle automation and privileged access are part of [identity and access management](/services/identity-access-management/), and the evidence, review cycle and regulatory mapping around them belong to [cybersecurity and compliance](/services/cybersecurity-compliance/).