.png)
When the only two buttons are "approve" and "revoke," reviewers approve. Right-sized review actions like role downgrades and license downgrades fix the decision model itself, and they're the difference between a review that certifies access and one that actually corrects it.
Most access reviews present every access decision as a coin flip: keep it or kill it.
That framing feels clean, but it doesn't match how access actually works inside an organization. A sales engineer with admin rights in the CRM doesn't need to lose the CRM. She needs to lose admin. A designer holding an enterprise license he opens twice a month doesn't need to be removed from the tool. He needs a cheaper seat. In both cases, the correct decision sits between the two buttons the review tool offers, and when the correct decision isn't available, reviewers default to the safe one: approve.
That's how user access reviews drift into rubber-stamping. Not because reviewers are lazy, but because the decision model gives them no way to be precise.
The Approve-or-Revoke Trap
Put yourself in the reviewer's seat. You're a department head looking at a line item that says one of your team members has access to a system they use every day, but with a permission level that looks higher than their job needs. Your two options:
- Approve: the person keeps working, nothing breaks, and the excess permission survives another quarter.
- Revoke: the excess permission dies, and so does the person's ability to do their job. You get a ticket, an angry Slack message, and a re-provisioning cycle within the hour.
Every rational reviewer picks approve. Multiply that across hundreds of line items per cycle, and the review stops functioning as a control. It becomes a quarterly confirmation that everyone keeps everything, signed off by people who could see the problem but had no button for the fix.
A binary review doesn't measure whether access is appropriate. It measures whether access is tolerable, and almost everything is tolerable.
The stakes of getting this wrong are well documented: security leaders overwhelmingly attribute breaches to over-permissive access, which is exactly the category of risk that approve-or-revoke reviews are worst at correcting. Over-permissioned access is rarely a keep-or-kill question. It's a how-much question, and binary tools can't answer how-much questions.
What the Middle Ground Actually Looks Like
Between "keep everything" and "lose everything" sits a set of decisions that map to how access risk and access cost actually accumulate. The prose version first, then the breakdown.
A full review decision model has at least four outcomes: approve when access and level are both right, downgrade the role when the app is right but the permission level is excessive, downgrade the license when the access is legitimate but the seat tier is over-provisioned, and revoke when the access shouldn't exist at all. The first and last are what every tool offers. The middle two are where most of the real findings live.
Two things stand out in that table.
First, the two middle rows are the most common findings in a mature review. Truly unjustified access (the revoke row) gets rarer as your provisioning gets better. But permission drift and license drift never stop, because they're produced by normal organizational life: promotions, project rotations, "just give them admin for now," annual renewals that carry last year's seat mix forward. A review process that can't act on drift is blind to the majority of what it should be finding.
Second, the middle rows are where finance enters the picture. A revoke-only review is a security exercise. A review that can downgrade licenses is also a cost-recovery exercise, and often a significant one, because premium-tier seats assigned by default are one of the most reliable sources of SaaS waste. When the same quarterly cycle that satisfies your auditors also hands finance a list of enterprise seats that can safely drop to standard, the review stops being a compliance tax and starts paying for itself.
Why Reviewers Make Better Decisions When Better Decisions Exist
The deeper effect of right-sized actions isn't the individual downgrades. It's what they do to reviewer behavior across the whole cycle.
When "downgrade" exists as an option, the psychological cost of acting drops to nearly zero. The reviewer is no longer choosing between the person's productivity and the organization's security. She's choosing the option that preserves both. That means:
- Fewer reflexive approvals. The safe-default logic that drives rubber-stamping only works when acting is dangerous. Downgrades make acting safe.
- More honest scrutiny. Reviewers engage with permission levels when engaging can lead somewhere other than a breakage ticket.
- A review record that means something. An audit trail full of granular decisions (approved, downgraded, revoked, with reasons) is far stronger evidence of a functioning control than a wall of approvals.
The quality of review decisions is capped by the quality of review actions. Give reviewers two buttons and you get binary thinking. Give them the full decision space and you get judgment.
Why Most Tools Stop at Approve and Revoke
If the middle ground is this valuable, why do most access review tools ignore it? Three reasons, and they're all about what the platform underneath can actually see and do.
Most review tools don't know what a license tier is. Traditional IGA platforms model access as entitlements: you have the entitlement or you don't. License tiers, seat types, and plan levels live in a different system (usually the vendor's own admin console or a finance spreadsheet), so the review layer literally cannot offer a license downgrade. It has no concept of one.
Role changes require write-depth most integrations don't have. Flipping a user from admin to member inside an app requires an integration that goes beyond reading the user list. Many platforms connect to apps at a depth sufficient for visibility and full deprovisioning, but not for granular role modification. So the review offers the actions the integrations can execute: keep or kill.
Remediation is the last thing anyone automates. Across the industry, remediation consistently lags certification in automation maturity. Vendors built the certify-and-sign-off layer first because that's what auditors ask to see, and remediation depth came later or never. The result is a market full of tools that are genuinely good at collecting approvals and genuinely limited in what those approvals can trigger.
The pattern this produces is familiar: the review "completes," the findings that needed nuance got approved for lack of a better option, and the access landscape on the last day of the cycle looks almost identical to the first.
How Zluri Handles It: The Most Appropriate Action, Not the Only Available One
This is the part of the review model we built differently at Zluri, and it's a direct consequence of what the platform sees. Because Zluri's discovery and integration layer captures not just who has access, but what role they hold and what license tier they're on, the review layer can offer actions that match reality:
- Approve when access, role, and license all check out.
- Modify access when the app is right but the shape of the access is wrong: downgrade an admin to a member, trim a permission set to what the job requires.
- Downgrade the license when usage doesn't justify the seat: move an enterprise license to a standard one and recover the difference at renewal.
- Revoke when the access shouldn't exist, executed through the same integrations rather than exported to a ticket queue.
And critically, these actions execute as part of closed-loop remediation: the decision made in the review is the change made in the app, with the evidence trail generated automatically. A downgrade decision that dies in a spreadsheet is no better than an approval. A downgrade that executes, verifies, and documents itself is a control.
This is also where the security-and-finance alignment becomes practical rather than theoretical. The same review cycle produces two outputs: a least-privilege correction record for the security team and the auditors, and a license right-sizing record for finance. Neither team ran a separate process to get it.
If you want to see how these reviews are configured in practice, including how reviewers see and select the full action set, our walkthrough of setting up certifications in Zluri covers the mechanics end to end.
Frequently Asked Questions
Why do access reviews only offer approve or revoke in most tools?
Because the underlying platform can't see or execute anything else. Offering a role downgrade requires integrations deep enough to modify roles inside each app, and offering a license downgrade requires the platform to model license tiers at all. Most IGA and review tools were built around entitlement-level certification, so approve and revoke are the only actions their architecture supports.
What is a role downgrade in an access review?
A role downgrade keeps a user's access to an application but reduces their permission level within it, for example moving an admin to a member or editor role. It's the correct decision when the access itself is justified but the privilege level exceeds what the job requires.
What is a license downgrade in an access review?
A license downgrade keeps a user in an application but moves them to a lower-cost seat tier, for example from an enterprise license to a standard one. It's the correct decision when access is legitimate but usage doesn't justify the premium tier, and it turns the review cycle into a source of recoverable SaaS spend.
How do right-sized review actions reduce rubber-stamping?
Rubber-stamping happens when revoking is the only alternative to approving, because revoking breaks people's work. When reviewers can downgrade instead, acting on a finding no longer carries the risk of disruption, so the rational default shifts from "approve everything" to "choose the appropriate action."
Do downgrade decisions count as remediation evidence for audits?
Yes, and they're often stronger evidence than approvals. A review record showing granular decisions (approvals, role downgrades, license downgrades, revocations, each with a reason) demonstrates that the control actually operates and corrects access, rather than confirming whatever exists. The key requirement is that decisions execute and are documented, not just recorded as intent.
