← All terms
Deprovisioning

What is Deprovisioning?

Deprovisioning is the timely removal of accounts, access rights, and sessions when a person leaves the organization or no longer needs them.

Last updated: 14 July 2026

How deprovisioning works

Deprovisioning is triggered by an event — a termination date in the HR system, a contract end, or a manual security action — and unwinds everything provisioning set up. A complete flow disables or deletes accounts across the directory and all connected applications, revokes group memberships and roles, invalidates active sessions and refresh tokens, rotates or removes credentials the person held, and reassigns owned resources such as mailboxes, files, and scheduled jobs.

Sequencing matters. Most organizations disable first and delete later after a retention period, preserving data for handover and legal requirements. Time matters even more: the gap between a person's last working moment and the removal of their access is a live risk window, so leaver events should propagate within minutes, not during the next nightly sync.

Deprovisioning also applies mid-employment: a mover who changes departments needs the old access removed, not just new access added.

Why deprovisioning matters

Accounts that outlive their owners are among the most reliable attack paths in any environment. Former employees retaining access is both an insider-risk scenario and an external one: credentials of departed users still work for attackers who obtain them, and no one is watching those accounts for unusual activity.

Incomplete deprovisioning is also the main source of orphaned accounts — active accounts with no living owner — which accumulate quietly in applications that were missed by the leaver process, especially systems integrated by hand or owned by individual teams.

Auditors treat leaver timeliness as a core control: frameworks such as ISO 27001 and SOC 2 expect evidence that access is removed promptly on termination, and "time to deprovision" is one of the few identity metrics with a direct, measurable security impact.

Deprovisioning in practice

The foundation is a reliable leaver signal: HR must record termination dates accurately, including for contractors and temporary staff who often bypass formal HR processes. From there, automate the highest-risk actions first — directory disable, session revocation, and VPN or remote access removal — then extend coverage application by application.

Measure the process with two numbers: time from termination to directory disable, and the count of applications covered by automated deprovisioning versus manual checklists. Reconciliation closes the loop — periodically comparing application accounts against the authoritative identity list to catch anything the event-driven flow missed.

Monosign automates the leaver stage through its JML workflows, disabling accounts and revoking access across connected applications when a termination event arrives.

Frequently asked questions

Should accounts be disabled or deleted?
Disable immediately, delete later. Immediate disabling closes the security gap while preserving mailbox contents, files, and audit history for handover and legal retention. A defined retention period — often 30 to 90 days — then governs final deletion.
Why is disabling the directory account not enough?
Many applications hold local accounts, cached sessions, API keys, or OAuth tokens that keep working after the directory account is disabled. Complete deprovisioning also revokes sessions and tokens, removes local application accounts, and rotates any shared credentials the person knew.
How fast should deprovisioning happen?
For planned departures, access should end at the agreed last moment of work. For terminations with elevated risk, revocation should be effectively immediate — directory disable and session invalidation within minutes. Nightly batch synchronization is too slow to serve as the only mechanism.