All Paths to Deprovisioning in Zluri: A Complete Map

"Deprovisioning" tends to conjure one scenario: an employee leaves. That's one path among many, and treating it as the whole picture is how the other paths end up under-built.

Access can stop being appropriate for a dozen genuinely different reasons: a role changing, a window closing, usage dropping to zero, a reviewer's decision, a contract ending. Each is a distinct trigger requiring its own mechanism.

This is the complete map, every distinct path that leads to access being reduced or removed, organized by what actually triggers it. Some of these are automated, some require a human decision, some aren't triggered by an event at all. Together they cover the full territory "deprovisioning" actually spans.

Fourteen distinct paths span eight trigger categories, from identity events and time-based expiry to usage patterns, review decisions, risk violations, commercial changes, standing policy, and manual admin action. Some execute automatically the moment a condition is met, others require a human decision point, and one requires no triggering event at all. The full inventory:

Identity-Lifecycle Triggers

Full offboarding (departure). The most familiar path, an employee's actual last working day, sourced from HR data, triggers complete revocation across every application in their footprint. This is comprehensive by design, covering the person's entire access, not one specific grant.

Mover-stage partial deprovisioning (role change). A distinct path from full offboarding, triggered by a role or department change rather than a departure. This revokes access tied specifically to the person's previous role while new access for their current one is granted, closing the gap left by the well-known asymmetry where addition happens reliably and removal doesn't, unless it's built as its own explicit step.

Contractor and external-user group-removal trigger. Third-party access frequently ends without ever routing through a formal HR termination event. A group-membership change, removal from a project-specific group, serves as its own valid trigger for this population specifically, since assuming the standard employee offboarding path will catch it leaves this category structurally uncovered.

Emergency or manual urgent termination. Standard offboarding automation is built around scheduled data syncs, not instantaneous reflection of a same-moment change. A genuinely urgent situation, a security incident, an unplanned departure, needs a direct, manually initiated action rather than depending on the next scheduled sync cycle to pick it up.

Time-Based and Scheduled Triggers

Access Duration expiry (JIT Access). A defined or custom time window specified at the point of a request, paired with a Deprovisioning Playbook that executes automatically the moment that window closes. This converts a grant into a time-bound one by default, rather than open-ended access that persists until someone remembers to revisit it.

Break-glass access expiry. Emergency, pre-authorized access carries its own defined time window, auto-revoked once that window closes, distinct from standard JIT access in that the access was granted without the normal upfront approval sequence specifically because the situation was urgent, making the automatic expiry the primary safeguard rather than a secondary one.

SoD exemption expiry. A time-bound exemption to a specific Segregation of Duties violation reopens the underlying conflict automatically once its mandatory duration ends. This isn't deprovisioning by itself, but it's the trigger that puts a tolerated exception back in front of remediation rather than letting it quietly become a permanent, unreviewed carve-out.

Usage-Driven Triggers

Unused threshold automated deprovisioning. Access that's gone untouched for a configurable rolling window, 30, 60, or 90 days, can trigger automated revocation once wired through an Automation Rule and Deprovisioning Playbook. Done responsibly, this includes a notification buffer before the actual revocation executes, since usage-based detection carries real false-positive risk.

Underused downgrade. A distinct, partial path rather than full revocation, access falling below a usage threshold relative to its tier triggers a downgrade, a premium license reduced to a basic one, rather than removing access entirely. This is the appropriate response when the access itself is still warranted, just not at its current level.

Review-Driven Triggers

Access Review Revoke decision. A reviewer's explicit decision during a periodic certification, informed by peer comparison, usage data, and recommended actions, triggers full removal of the specific access under review. This is human judgment applied on a recurring cadence, catching what automated triggers alone wouldn't necessarily flag.

Access Review Modify decision. The partial counterpart to Revoke, keeping the person's access to an application while changing the specific entitlement level they hold within it. This is the decision that expresses the common real finding, right access, wrong level, that a binary revoke-or-keep review structurally can't capture.

Risk and Violation-Driven Triggers

SoD Enforce-mode automated remediation. Once a Segregation of Duties rule has been validated and switched from Monitor to Enforce, detecting a violation automatically triggers the configured remediation playbook, resolving the conflict without waiting on manual intervention.

Application Restricted-status triggering stripped access. When an application's risk score and authorization status combine to a high-risk, Restricted classification, the recommended-action matrix calls for direct user notification and SSO authentication removal, a risk-driven trigger tied to the application's changing status rather than any specific person's lifecycle event.

Commercial and Relationship-Driven Triggers

Vendor contract termination. When a vendor relationship ends commercially, the technical access supporting it, an OAuth grant, API credentials, a vendor-owned service account, needs its own explicit revocation, tied to the contract's actual end date rather than assumed to lapse on its own once the agreement is over.

M&A divestiture. The reverse of merger-driven consolidation, a bulk deprovisioning event covering an entire divested population's access at once, requiring the same underlying mechanics applied at a scale and speed a routine, individual offboarding trigger was never built to handle alone.

Policy-Driven Triggers (No Specific Event Required)

Zero Standing Privilege conversion. Unlike every path above, this isn't triggered by a departure, an expiry, or a violation, it's a deliberate policy decision to proactively revoke default, standing access and convert it to on-demand, time-bound grants instead. This path removes access nobody specifically flagged as wrong, simply because standing access itself is the thing being reduced as a matter of policy.

Manual Triggers

Direct, ad hoc admin-initiated deprovisioning. Not every removal traces back to a rule or a review. An admin can directly revoke a specific piece of access at any time for a reason that doesn't map to any automated trigger, a one-off correction, a direct request from a manager, a judgment call that doesn't need to wait for the next scheduled process to catch it.

Why It Matters That These Are Distinct Paths

Treating all of this as one undifferentiated "deprovisioning" bucket is how specific paths end up under-built while attention concentrates on the most obvious one. An organization with a well-built offboarding trigger and nothing else can still leave usage-driven waste, expired time-bound grants that were never actually revoked, and third-party access with no formal exit trigger entirely uncovered, each of those is a distinct gap that "we have offboarding automation" doesn't actually close.

Frequently Asked Questions

Is a downgrade the same thing as deprovisioning?

Not fully, and it's worth treating as its own category. Underused downgrades and Access Review Modify decisions both reduce access without eliminating it entirely, distinct from full revocation, and both address a different situation, access that's still warranted but currently held at too high a level.

Why does contractor access need its own separate deprovisioning trigger instead of relying on standard offboarding?

Because a contractor's engagement frequently ends without generating the same kind of formal HR termination record a full-time employee's departure would. A group-membership-based trigger covers this population specifically, rather than assuming the standard employee-offboarding path will catch it, which it structurally can't if no HR termination event was ever recorded.

Does Zero Standing Privilege conversion require someone to do something wrong first?

No, and this is what makes it distinct from every other path here. It's a proactive policy decision to reduce standing access as a category, not a response to a departure, a violation, or an expiry. Access gets converted to on-demand simply because the policy calls for minimizing standing grants, independent of any specific triggering event.

If an organization only has one deprovisioning trigger built, which one should it be?

Full offboarding tied to an actual HR departure date, since it's the highest-volume, most consequential single path. But it's worth being clear that having only this one still leaves every other path, usage-driven waste, expired time-bound access, contractor exits, risk-driven revocation, genuinely uncovered, not partially covered by extension.