Access creep between role changes and offboarding: what teams miss

TL;DR: Access creep accumulates during employment, not just at onboarding or termination, because role changes and temporary access often never get cleaned up; Zluri’s analysis models 500 employees, 100 SaaS apps, and 4,500 excess grants a year. The control gap is visibility and lifecycle automation, not a lack of provisioning effort.

NHIMG editorial — based on content published by Zluri: The Math Behind Access Creep: What Happens Between Onboarding and Offboarding

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

Questions worth separating out

Q: How should security teams stop access creep after role changes?

A: Security teams should tie each HR-driven role change to an automated access review that removes the old role baseline, not just adds the new one.

Q: Why does temporary access so often become permanent?

A: Temporary access becomes permanent because organisations track when access starts, but not when the business need ends.

Q: What breaks when organisations cannot see all applications?

A: Cleanup breaks first, because teams can only review and revoke access in systems they know exist.

Practitioner guidance

• Map access changes to lifecycle triggers Connect HRIS events such as promotion, transfer, department change, and location change to automated entitlement review so old role access is removed when the new role baseline is applied.
• Expire temporary access by default Assign end dates to project, backup, emergency, and training access so permissions drop automatically when the business need ends instead of relying on manual follow-up.
• Build complete application discovery Inventory federated apps, non-federated tools, department-purchased software, and shadow IT so cleanup workflows can act on the full estate rather than only what appears in IAM logs.

What's in the full article

Zluri's full blog post covers the operational detail this post intentionally leaves for the source:

• The step-by-step math behind the 500-employee access creep model, including how excess grants compound over five years.
• The capacity breakdown showing where manual IAM work goes and why 0.5 FTE cannot keep pace with 1.54 FTE of lifecycle work.
• The visibility-first automation model for federated apps, non-federated apps, and shadow IT across the full SaaS footprint.
• The self-service access request pattern used to reduce provisioning burden while preserving approval workflows.

👉 Read Zluri's analysis of access creep between onboarding and offboarding →

Access creep between role changes and offboarding: what teams miss?

Explore further

View Full Forum →  |  NHI Foundation Course →