Decommissioning Done Right: The Quiet Risk of What You Forget to Remove

Identity programmes pour enormous energy into granting access well and almost none into removing it well. Yet the access you forgot to remove is uniquely dangerous: it is privileged enough to matter, old enough that nobody remembers it, and unwatched because no active user is generating noise around it. Orphaned accounts, dormant entitlements, and incompletely-offboarded leavers are a standing invitation, and they are found in essentially every environment that hasn't made decommissioning a deliberate control.

The three populations of forgotten access

• Orphaned accounts — accounts on target systems that correlate to no active identity. They exist because provisioning happened out-of-band, because correlation is weak, or because a person left and their downstream accounts were never cleaned up.
• Dormant access — entitlements held by active users but unused for long periods. The user is legitimate; the access is not justified. This is pure attack surface with no offsetting business value.
• Incomplete leavers — people who left but whose access lingers in systems the primary offboarding never reached, especially SaaS apps and federated services outside the core directory.

Detection requires complete visibility

You cannot decommission what you cannot see, which is why this work depends on the same foundation as everything else in IGA: comprehensive aggregation and strong correlation across all your systems, not just the easy ones. The orphaned account that matters is invariably in the system you didn't onboard into your governance platform. Coverage gaps in aggregation are decommissioning blind spots, and attackers gravitate to exactly those shadows.

Make removal safe so it actually happens

Teams hesitate to remove access because removing the wrong thing breaks someone's job, and the blame for an outage is more immediate than the blame for a breach that hasn't happened yet. Counter this with two things: data (usage evidence that makes removal defensible) and reversibility (fast restoration if you got it wrong). When removing dormant access is low-risk and quickly undoable, the organisational reluctance evaporates and hygiene becomes routine rather than heroic.

Automate the obvious, govern the rest

Some decommissioning should be fully automatic: a leaver event from the authoritative source disables accounts everywhere, immediately. Some needs a light-touch review: dormant access triggers a micro-certification asking the owner to confirm or release. The principle is that access should expire by default and persist by exception — the opposite of how most environments work, where access persists by default and is removed only if someone remembers. Flipping that default is the whole game.

Decommissioning is unglamorous, invisible when it works, and catastrophic when neglected. Treat it as a first-class control — with its own metrics, automation, and ownership — and you close off the quiet attack paths that no amount of front-door authentication will ever protect.