Leaving triggers a form. Or a ticket. Or a manager notification that may or may not be actioned. The gap between the speed of provisioning and the reliability of revocation is one of the most consistent identity governance failures in the enterprise.
Why This Matters Now
Identity and access management has matured significantly in most enterprise environments. Modern IAM platforms provision access automatically when HR systems record a new hire or role change. Directory synchronization ensures that access rights follow role assignments in near real-time. Lifecycle management workflows trigger onboarding processes that would have taken days in older environments in hours or minutes.
Offboarding automation has not kept pace. Account deactivation, group membership removal, SaaS license revocation, API key deprecation, and service account decommissioning involve more varied systems, more complex dependencies, and more operational coordination than provisioning, which typically follows a defined path from HR to IAM to application. Offboarding requires reversing that path across systems that may not have the same integration depth as provisioning systems.
Provisioning is the path of least resistance. Revocation is the path of greatest friction. Most identity governance investments reduce the friction on the path that matters less for security.
The Governance Problem Beneath the Surface
The asymmetry between provisioning and revocation reflects a structural feature of identity governance programs. Provisioning automation delivers immediate business value: new employees are productive faster, role changes take effect immediately, and operations are not blocked by access delays. The business value of revocation is protective rather than productive: it prevents access by former employees, reduces the attack surface for compromised accounts, and limits the blast radius of security incidents.
Protective value is harder to justify as investment than productive value. Provisioning automation has clear, measurable business benefits. Revocation automation prevents harms that may never materialize, making its value difficult to quantify in a way that competes for investment alongside productivity-improving initiatives.
The governance consequence of this structural asymmetry is identity estates with excellent provisioning infrastructure and inconsistent revocation coverage. Access accumulates faster than it is removed. The gap between granted access and required access grows with organizational size and employee tenure.
What This Actually Means in Enterprise Practice
SaaS Access Is Outside Central Revocation Scope
Enterprise SaaS adoption has grown to the point where the average organization uses hundreds of SaaS applications. Many of these were provisioned by business teams without central IT involvement, are not connected to the central IAM system, and are not in scope for the automated offboarding processes that IT manages for core applications. Former employee accounts in these systems persist indefinitely because no revocation workflow reaches them.
Service Accounts Have No Offboarding Process
Service accounts created by employees for automated processes, API integrations, and operational automation are typically associated with the employee who created them rather than with the service they support. When the employee leaves, the service account's association to an active identity is broken but the account itself remains active. Service accounts may continue operating with credentials that were never rotated after the employee's departure, representing an attack surface that the offboarding process was not designed to address.
Service accounts created by employees are effectively orphaned at offboarding. The account exists. The responsible owner does not. The credentials were never rotated because rotation requires knowing the account exists and the process that depends on it, which are not documented for most informally created service accounts.
Privileged Access Is the Highest Risk Gap
Privileged access, including administrative accounts, elevated permissions, and break-glass access, represents the highest-risk category of access to retain after an employee's departure. It is also the category most frequently missed in revocation workflows. Privileged access is often provisioned through mechanisms separate from standard user provisioning, tracked in separate systems or in shadow documentation, and is not always in scope for the automated offboarding triggers that handle standard user access.
Role Changes Are Additive, Not Substitutive
When employees change roles, new access is provisioned for the new role. Old access from the previous role is frequently not revoked. Over time, employees accumulate access from every role they have held, creating profiles with significantly more access than their current role requires. Access reviews catch some of this accumulation. They do not prevent the accumulation from occurring between review cycles, and review coverage is incomplete for many organizations.
How Different Teams See This: Where They All Miss
Revocation completeness requires coordination across HR, central IT, business teams, and security that provisioning does not require to the same degree. Each team's scope covers part of the identity estate. No team covers all of it.
Framework Control Reference
The specific control obligations most relevant to this topic across primary frameworks. Use these references in governance discussions, vendor assessments, and audit responses.
These controls share a common requirement: the obligation is active, not declarative. Documenting alignment is not the same as demonstrating it.
The Enterprise Reality Gap
The enterprise identity revocation reality gap is the population of active accounts held by individuals who no longer require them: former employees with access to core systems, former contractors with access to sensitive data, role-changed employees with access to systems from previous roles, and service accounts with credentials that were never rotated after their owners departed.
This population is larger in most enterprises than identity governance programs acknowledge. It is also the population that represents the most common initial access vector in enterprise security incidents involving insider threat, compromised credentials, and supply chain attacks.
Every active account held by someone who no longer needs it is an attack surface that provisioning automation created and revocation automation did not close. The population of such accounts in most enterprises is larger than identity governance metrics reflect.
Enterprise Scenario: The Account That Should Have Been Gone
The offboarding process executed correctly within its scope. The scope did not include the access that posed the highest risk. A subsequent security review identified the active accounts. A threat intelligence report three months later identified the former employee's credentials in a credential dump from a separate service breach. The credentials were rotated the day the threat intelligence arrived, ninety-three days after the employee left.
Industry Signal
Breach investigations that involve former employee access consistently identify the same pattern: offboarding processes that address core systems and miss shadow access. The Verizon Data Breach Investigations Report has repeatedly identified former employee access as a significant initial access vector. Security tooling vendors addressing identity security have built entire product categories around discovering and remediating orphaned accounts, reflecting both the prevalence of the problem and the demand for solutions that standard IAM programs have not resolved.
Orphaned account risk is not a theoretical concern. It is a documented, recurring attack vector that identity governance programs have consistently underaddressed. The attack surface is the gap between provisioning coverage and revocation coverage.
Enabling Capabilities
- SaaS management platforms: Tools that discover SaaS applications in use across the organization, identify user access in each, and support revocation workflows beyond central IAM scope.
- Identity governance platforms with departure workflows: Extended offboarding automation that reaches SaaS applications, service accounts, and cloud resource access beyond directory-connected systems.
- Service account discovery and management: Dedicated tooling for discovering, documenting, and managing service accounts with linkage to responsible owners and automated rotation on owner departure.
- PAM systems: Privileged access management platforms that track privileged account holders and trigger revocation of privileged credentials on role change and departure.
- Dormant account detection: Automated monitoring for accounts that have not been used within defined thresholds, triggering review and potential deactivation.
A Practical Starting Point
Map the access your offboarding process does not reach. Specifically: SaaS applications not connected to central IAM, service accounts in your cloud infrastructure, developer tooling provisioned by engineering teams, and privileged accounts in non-directory-connected systems.
For each category, estimate the number of active accounts held by former employees or former role holders. The number is your revocation gap. Build a remediation plan that addresses each category through either automated integration or defined manual process with accountability and timeline.
The offboarding process you have is complete within its scope. The question is what is outside its scope. Start there.
Questions Leaders Should Be Asking
- What categories of access are outside the scope of our automated offboarding process, and what is our process for revoking that access when employees leave or change roles?
- How many service accounts in our environment are associated with former employees, and when were their credentials last rotated?
- What is the average time between an employee's departure and the revocation of all access held by that employee across all systems?
- Do we have visibility into SaaS applications provisioned by business teams outside central IT scope, and do those applications appear in our offboarding workflows?
- What is the population of active accounts in our environment associated with individuals who left the organization more than thirty days ago?
What to Require From Vendors
Ask directly:
"What offboarding integration capabilities does your platform provide, specifically for connecting to HR systems for automated account deactivation, and what is the scope of access your platform can revoke through that integration?"
Expect as evidence:
- Specific list of access categories revoked through HR-triggered offboarding automation
- Documentation of what access is not covered by automated revocation and requires manual action
- Service account lifecycle management capabilities with owner linkage
- Dormant account detection and management capabilities
A vendor who describes offboarding automation without specifying its scope has described a capability whose coverage you cannot assess. Ask for the explicit list of what the automation reaches and what it does not.
Demonstrating Diligence
- Documentation: Offboarding process scope documentation with explicit coverage and gap acknowledgment; service account inventory with owner mapping; SaaS application inventory with access tracking.
- Process: Defined remediation for access categories outside automated scope; service account rotation process for owner departure; dormant account review and deactivation.
- Technical evidence: Offboarding completion records with scope confirmation; service account rotation logs; dormant account detection and remediation records.
Demonstrating revocation diligence requires showing completeness of scope, not just reliability of process within scope.
Closing Perspective
Access provisioning automation is one of the genuine success stories of enterprise IAM. The productivity improvements it delivers are measurable, the business case is clear, and the implementation is mature in most organizations. The identity governance investment has been well-deployed.
The security consequence of that investment is an identity estate where access can be granted quickly and reliably across a broad range of systems and cannot be reliably revoked across the same range. The attack surface the provisioning system creates, the provisioning gap closes. The revocation gap leaves it open.
Closing the revocation gap requires building automation with the same scope and reliability as provisioning automation. The investment is significant. The alternative is an identity estate that grows more exposed over time as access accumulates faster than it is removed.
The identity governance program that provisions well and revokes incompletely has built an excellent entry point and left the door open behind it.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.