Authentication and authorization are point-in-time decisions. Access risk is a function of time. That mismatch is a gap by design, and it's not one either discipline is built to close on its own.
Most identity programs are built, correctly, around getting authentication and authorization right: strong MFA, well-modeled RBAC or ABAC, clean provisioning at onboarding and role change. That work is necessary and most mature organizations have genuinely solved it. What fewer have solved is the layer sitting underneath both: the mechanism that continuously checks whether access already granted, correctly, at the time, still reflects current need.
This isn't a definitional piece. It assumes the distinction between authentication and authorization is already familiar. The actual argument is narrower and more specific: why a well-built authentication and authorization stack still leaves an inherent gap, what that gap actually looks like in practice, and why governance has to be a separate, continuously operating layer rather than an extension of either discipline.
At a glance, before the detail:
The Underlying Reason Authorization Can't Self-Correct
Authorization is a point-in-time decision by design. A role change fires, a policy engine evaluates what that role should hold, and access gets provisioned accordingly. That decision is correct at the moment it's made, evaluated against the role and context that existed then.
The problem isn't that the decision is wrong. It's that nothing about the authorization event itself creates a trigger to revisit the decision later. RBAC and ABAC systems are built to answer "what should this identity have, given its current attributes," evaluated on demand, not to periodically re-ask that question against every identity that already holds access. Re-running authorization logic continuously against the entire access graph is a fundamentally different operational problem than evaluating it once at grant time, and most authorization systems were never architected for that continuous re-evaluation, because it wasn't the problem they were built to solve.
This is why the gap isn't a bug in any specific IAM or IGA product. It's built into what authorization actually is: a mechanism for granting and revoking access at a given moment, not one for continuously monitoring what's already been granted.
Where This Actually Shows Up
The pattern is consistent enough across environments to be worth naming precisely, because it's the mechanism behind most access-related findings in a real audit, not a hypothetical edge case.
Addition and removal are asymmetric. A role change reliably triggers new access, since it's obvious and immediate, and provisioning workflows are generally well-built for it. The same event triggers removal of prior access far less reliably, since nothing about the new role inherently signals that the old access should be revoked, and removal typically requires an explicit, separately configured step that many workflows simply don't include. Repeated across a person's tenure, this produces an access footprint that's the union of every role they've ever held, not the access their current role actually requires.
Peer-relative anomalies are invisible to authorization logic. A grant that's individually defensible, reasonable given the specific project or exception that justified it, can still be a genuine outlier the moment it's compared against what a current peer in the same role actually holds. Authorization evaluates a request against policy. It doesn't compare an identity's accumulated access against a peer cohort, which is precisely the comparison that surfaces this pattern.
Usage and grant status silently diverge. Authorization confirms a permission was correctly assigned. It says nothing about whether that permission has been exercised in the past ninety days. An unused, still-active grant is functionally indistinguishable from a used one at the authorization layer, and stays that way until something outside authorization checks usage data specifically.
Non-human identities accumulate the same way with less oversight. Service accounts and API keys go through authorization at creation, generally with broader scope than strictly necessary, since narrowing scope for automation is more engineering effort than granting it liberally upfront. They then persist with no equivalent to an HR-triggered role change ever prompting a re-evaluation, because nothing about a service account's lifecycle resembles the human lifecycle events authorization workflows are typically built around.
Why This Isn't an Argument for Better Authorization
The instinct, once this gap is visible, is to try to close it by making authorization more sophisticated: tighter policies, more granular roles, more conditions on ABAC rules. That helps at the margin, at the moment of grant, but it doesn't address the actual problem, which is temporal, not a policy-precision problem.
Better policy still only fires at grant time. It doesn't create an ongoing mechanism that revisits access already granted under a policy that was correct when it was written and may no longer be. Tightening authorization is optimizing the wrong variable. The gap isn't between "our RBAC model is too coarse" and "our RBAC model is precise enough." It's between "access decisions get made" and "access decisions get re-examined," and no amount of precision in the first category substitutes for the second existing at all.
What a Governance Layer Actually Has to Do Differently
Closing this gap requires a mechanism built around a genuinely different operating principle than authorization: continuous or scheduled re-evaluation against the full, current state of access, rather than a one-time decision at a triggering event.
Concretely, that means:
- Peer-comparison analysis that flags accumulated access as an outlier relative to current role peers, not just non-compliant with a written policy.
- Usage-based signal that treats sustained non-use as a governance finding independent of whether the original grant was authorized correctly.
- Explicit mover logic that pairs every new grant with an evaluation of what the previous role's access should now lose, rather than treating role changes as purely additive events.
- Continuous segregation-of-duties evaluation run against an identity's full, current access picture, since a toxic combination can emerge well after either individual grant was made, when two previously separate roles' access ends up held by the same identity.
- A defined, recurring review cadence that treats "this access was correctly granted" and "this access is still appropriate" as two separate questions with two separate answers, verified independently.
None of this is a more sophisticated version of authorization. It's a different discipline, operating on a different timeline, checking a different question.
Where Zluri Fits
Zluri's core differentiation is specifically this governance layer, not a replacement for authentication or authorization, both of which it deliberately doesn't try to own.
Authentication: remains the identity provider's responsibility. Zluri consumes that data as a source of truth rather than re-platforming it.
Authorization: gets enforced directly, RBAC, least privilege, segregation of duties, and just-in-time access, provisioned automatically off real-time HRIS events at onboarding and role change.
Governance: is where the differentiated work sits, peer-comparison access reviews that surface outlier accumulation, usage data that flags authorized-but-abandoned access, mover-stage workflows that pair every grant with explicit removal logic for the role being left, and segregation-of-duties evaluation run against an identity's complete, current access footprint rather than each grant in isolation.
The distinction that matters operationally: authentication and authorization get evaluated at the moment. Governance is what keeps asking the same question after the moment has passed.
Frequently Asked Questions
Isn't continuous access review just a more frequent version of authorization?
No, the mechanism is different, not just the frequency. Authorization evaluates a request against policy at a triggering event. Governance evaluates existing, already-granted access against current need and peer norms, independent of whether a new triggering event has occurred, which is a comparison authorization systems aren't built to run against their own historical grants.
Why does mover-stage access removal fail even in organizations with mature RBAC?
Because RBAC governs what a role should have, evaluated at the point a role is assigned. It doesn't inherently evaluate what a previous role's access should lose when a new one is granted, since that requires an explicit removal step most provisioning workflows don't include by default, regardless of how well-modeled the roles themselves are.
Can tightening authorization policy alone close the governance gap?
No. Tighter policy improves the accuracy of decisions made at grant time. It doesn't create a mechanism that revisits access after it's granted, which is what the governance gap actually consists of. The two are solving different problems on different timelines.
Why do non-human identities accumulate access risk differently than human identities?
Because they're not tied to HR-triggered lifecycle events that would normally prompt a role-based re-evaluation. A service account provisioned with broad scope at creation has no equivalent to a promotion or department transfer that would naturally surface it for review, which is why governance mechanisms need to treat non-human identities as a distinct, explicitly tracked category rather than assuming human-lifecycle triggers will catch them.
.webp)
.svg)
