Provisioning automation gets all the demo attention because it's the one that speeds up onboarding, which is a metric someone tracks. Deprovisioning is the one that actually matters for risk, and it's the one most orgs still do by hand, on a timeline that depends on someone remembering to file a ticket.
The gap that actually gets exploited
Access granted on day one and never revisited is privilege creep. Access that should have been revoked on someone's last day but wasn't for another two weeks is a live credential sitting outside anyone's control. The second one is the more common finding in an access review, and it's entirely a process gap, not a technical one.
Wiring deprovisioning to the actual source of truth
The fix is boring: HR system status change triggers the access revocation directly, not a ticket that routes through a queue.
def on_hr_status_change(event: dict):
if event["status"] == "terminated":
user_id = event["employee_id"]
revoke_all_sessions(user_id)
deactivate_okta_user(user_id)
remove_from_privileged_groups(user_id)
log_deprovision_event(user_id, source="hr_webhook")
Same logic for role changes — a lateral move should trigger a review of group membership, not just an addition of new access on top of what the old role already had. That's where privilege creep actually accumulates: nobody removes the old access when the new access gets granted.
Risk-based authentication as the other half
Provisioning and deprovisioning handle who has standing access. Risk-based authentication handles what happens at the moment of a request — location, device posture, and behavior pattern deciding whether to step up the auth requirement. The two need to work together: even correctly provisioned access should get an extra check when the request looks unusual.
Where machine learning actually earns its place
Provisioning, deprovisioning, and risk-based auth handle the rules I can write down explicitly. Anomaly detection against behavior patterns — login times, access volume, resource patterns that don't match a user's history — catches the stuff I didn't think to write a rule for. I don't treat a flagged anomaly as a verdict, just a reason to look, but it's caught real issues that none of the deterministic checks above would have.
What I actually track
Time-to-deprovision from the HR termination event, not from ticket creation. That's the number that tells you whether the automation is actually closing the gap or just making it easier to see the gap exists. Alongside that, I keep an eye on login attempts, access request volume, and policy violation counts over time — not because any single number means much on its own, but because a sudden shift in one is usually the first sign that a process or a policy has quietly drifted out of alignment with how the org actually operates now.
None of this is a set-and-forget system. The processes above need the same periodic review as the access they're governing — an automation that was correct at rollout can go stale just as easily as a policy nobody revisited.