Access creep between onboarding and offboarding is a math problem

At a glance

What this is: This is a Zluri analysis of why access creep builds during employment, not just at onboarding or offboarding, and why role changes plus temporary access drive the accumulation.

Why it matters: It matters because IAM and IGA teams cannot govern what they cannot see, and manual lifecycle cleanup fails once scheduled changes and event-based access outpace capacity.

Context

Access creep is the gradual buildup of permissions that remain after the original business need has changed. In this article, that buildup is framed as an identity governance problem, not a provisioning problem, because the access granted at onboarding is only the starting point.

The article separates predictable role changes from temporary, event-based access and shows why both create excess grants when cleanup is not triggered. That is a familiar pattern for IAM and IGA programmes: entitlement drift is often introduced by the business process around access, not by the initial grant itself.

The operational blind spot is visibility. If teams cannot inventory all applications, including federated, non-federated, and shadow IT, they cannot reliably revoke access or prove that cleanup happened.

Key questions

Q: What breaks when access cleanup only happens at onboarding and offboarding?

A: Access accumulates during the middle of employment when role changes and temporary grants are not re-evaluated. Onboarding can be correct and offboarding can still be handled, yet excess access remains because the organisation never resets the baseline when job context changes or temporary need ends.

Q: Why do role changes create so much access creep?

A: Role changes create access creep because organisations are faster at adding new access than removing old access. The old permissions are often still usable, carry no immediate operational pain, and therefore survive the transition. The result is accumulated access from previous roles that expands blast radius and weakens least privilege.

Q: How can security teams tell if agentic access is getting out of hand?

A: Look for tokens that can reach multiple environments, secrets that appear in config files or shared workspaces, and actions that do not trigger external approval before production writes. If an agent can move from a staging task to destructive infrastructure changes without leaving an enforceable trace, the governance model is already too loose.

Q: Should organisations prioritise automation or role cleanup first in user access management?

A: Role cleanup should usually come first when access is badly structured, because automation will only accelerate messy decisions. Once roles and responsibilities are clearer, automation can reduce delay in provisioning, deprovisioning, and review cycles. The right order is to simplify the model, then automate the repetitive work around it.

Technical breakdown

Scheduled access drift after role changes

Scheduled drift happens when HRIS records a promotion, team move, or department change but the downstream access baseline never gets recomputed. The result is additive access: the new role’s entitlements are granted while the old role’s permissions remain in place. In governance terms, this is a lifecycle sync failure between HR, identity, and application control layers. The article’s math shows why this matters at scale, because even small per-person residue becomes a material entitlement burden across the workforce.

Practical implication: tie role-change events to access recertification and baseline resets, not just to new provisioning.

Event-based access and the missing expiry signal

Event-based access is granted for a project, escalation, backup duty, or temporary need, but the article shows that the end of that need is rarely tracked. The control gap is not the initial grant. It is the absence of an expiry signal or follow-up state that tells the IAM process when to remove it. Without that, temporary access becomes permanent by default, especially in non-federated apps and departmental tools outside central visibility.

Practical implication: treat temporary access as expiring by default and require a system signal to extend it.

Visibility-first automation across a fragmented SaaS estate

The article argues that cleanup is impossible without complete application visibility because access cannot be revoked in systems that are not in inventory. That means federated SSO apps, directly provisioned SaaS, and shadow IT all need to feed the same governance view. The technical point is simple: automation only works after discovery, because lifecycle logic needs a complete entitlement map before it can safely remove anything. That is why the visibility problem and the automation problem are inseparable.

Practical implication: unify app discovery, entitlement inventory, and lifecycle automation before relying on cleanup workflows.

NHI Mgmt Group analysis

Access creep is a lifecycle control failure, not a provisioning failure. The article’s core insight is that onboarding can be clean while access still accumulates through the middle of employment. That shifts the governance problem from grant accuracy to entitlement decay, which is where many IAM and IGA programmes still underinvest. The practitioner conclusion is that lifecycle control has to extend across the full employment journey, not just the joiner and leaver endpoints.

Visibility is the prerequisite for any credible access cleanup programme. If an organisation cannot see federated, non-federated, and shadow applications together, it cannot claim to govern access end to end. This is not a tooling preference but a governance boundary: you cannot revoke what you have not discovered. The implication is that identity programmes need discovery completeness before they can trust any remediation metric.

Visibility-first automation: the named concept that matters here. Zluri’s analysis points to a model where discovery comes before rules, and rules come before cleanup. That sequence matters because lifecycle automation built on partial inventory creates a false sense of control. The practitioner conclusion is to measure governance by how completely it can see and then retire excess access, not by how many tickets it can close.

Manual cleanup does not scale with workforce mobility. Once role changes and temporary access are frequent, the review burden grows faster than human capacity. The math in the article shows why access governance collapses into backlog when teams depend on manual review cycles. The implication is that identity operations must be engineered around event volume, not around hope that analysts will eventually catch up.

Access creep exposes a broader IGA design assumption: permissions stay visible long enough to be removed. That assumption fails in modern SaaS estates where access may be granted outside central workflows and then linger without a matching termination event. The practitioner conclusion is that lifecycle governance must be designed around discovery, expiry, and recursive cleanup as a single control loop.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Visibility-first automation is the operating model that access governance now needs. Organisations should stop treating lifecycle cleanup as a periodic review task and start treating it as a discovery plus expiry problem. The practical shift is to connect entitlement decisions to live application inventory, because access decay cannot be governed inside a partial catalog.

Role changes and temporary access should be treated as separate control paths. One path is scheduled and can be triggered from HR events, while the other is event-based and needs expiry or usage evidence to close. Programmes that collapse both into generic provisioning workflows will continue to accumulate residue even when the joiner and leaver motions look healthy.

Access creep now belongs in IAM and IGA risk reporting. The article ties excess grants to audit findings, compliance violations, and licence waste, which makes the issue measurable rather than anecdotal. Teams should track how much access remains after role change, not just how quickly access is granted.

For practitioners

• Implement role-change-triggered access reviews Link promotions, team moves, and department changes to an automatic entitlement review that recalculates the role baseline and removes superseded access.
• Add default expiry to temporary access Require every project, emergency, or backup grant to carry an end date unless a system event explicitly renews it.
• Build a complete application inventory Unify federated SaaS, direct-to-app provisioning, departmental tools, and shadow IT into one discovery view before attempting cleanup.
• Automate cleanup from HRIS and IdP events Use real-time lifecycle triggers so access removal starts when role data changes rather than waiting for quarterly recertification.
• Use usage evidence before removing access Base safe cleanup on observed non-use so teams can remove excess entitlements with audit-ready justification.

Key takeaways

• Access creep builds during active employment, especially when role changes and temporary access are not tied to removal workflows.
• The article’s model shows that a 500-person environment can accumulate 4,500 excess grants a year when cleanup does not happen.
• The control that changes the outcome is not more provisioning effort but complete visibility, automatic lifecycle triggers, and default expiry for temporary access.

Key terms

• Access Creep: Access creep is the gradual accumulation of permissions that remain after a role change, project move, or temporary exception ends. It matters because legacy access often creates hidden conflicts, especially when a user retains rights across systems that should be controlled separately.
• Event-Based Access: Event-based access is temporary permission granted for a specific business activity, such as a project, emergency, or backup assignment. It should expire when the activity ends, but it often persists because no reliable end trigger exists in the governance process.
• Scheduled Lifecycle Change: A scheduled lifecycle change is a documented employment event such as a promotion, department move, or team transfer that should trigger entitlement review. For identity governance, it is the point where old access should be re-evaluated against the new role baseline.
• Visibility-First Automation: Visibility-first automation is a governance pattern that requires complete application and entitlement discovery before cleanup logic is trusted. It matters because automated removal is only safe when the organisation can see all the systems and access paths it is attempting to control.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.