A user-based access review starts with the person, not the system. You pick who, not what, and see everything that person can touch, across every app and group, in one place.
Most access reviews have historically started with a system-level question: which app should we review, or which group needs a membership check. That's how the market has run access governance for years, and it's part of why so many review programs still operate app by app, spreadsheet by spreadsheet.
Plenty of real security and compliance questions don't start there at all. They start with a person:
- A flagged user in a security alert
- A contractor whose engagement is ending
- A project team that just wrapped up and needs its elevated access pulled back
Answering that kind of question has traditionally meant stitching together app-by-app records by hand, hours of manual cross-referencing to reconstruct one person's access footprint. User-based access reviews are a newer entity type built specifically to close that gap.
This article covers how the review type works, when to use it, and what setup looks like in a modern platform like Zluri.
What a User-Based Review Actually Does
A user-based review lets you pick specific people, or define a population by criteria, and then scope which applications or groups to review for exactly those people, all inside a single certification.
Instead of running five separate application-based certifications to check what five project team members still have access to, you run one user-based certification: select the five people, scope it to the relevant apps, and see everyone's access footprint side by side. Instead of guessing which app or group a departing contractor touched, you scope the review to that person and every application and group tied to them surfaces automatically.
It sits alongside application-based and group-based reviews as a third way to scope a certification, not a replacement for either.
What It Solves
Before user-based reviews existed, answering a person-first question meant manually tracking users across multiple app-by-app certifications. A few scenarios where that gap showed up most:
A confidential project wraps up. Five team members got privileged access to Slack, Google Ads, and Okta for the duration of the project. Someone now has to figure out exactly what each of them still holds, and pull it back, without touching everyone else's access to those same tools.
Year-end contractor and external-employee review. Compliance requires validating every contractor and external hire's access, globally, once a year. That's not one app's problem, it's a population of people whose access spans dozens of systems.
A user shows up in a security alert. The security team needs that person's complete access footprint, right now, across every system they touch, not a slow crawl through app-by-app records to reconstruct it.
A team reorganizes. People move roles, but old access doesn't always move with them. This is the classic access creep pattern, permissions accumulate as someone moves through the company and rarely get cleaned up along the way. A user-based review scoped to the transferred employees surfaces exactly what they retained from their previous role.
An employee's exit needs a final access check. Offboarding workflows typically deprovision the apps IT knows about. A user-based review scoped to the departing employee catches what automated deprovisioning might miss, access granted manually, through a group nobody remembered to map, or through a system that isn't fully integrated, before the exit is actually closed out.
A business unit gets acquired, sold, or spun off. M&A and divestiture events need a clean, fast picture of exactly what the affected employees can access, so provisioning and deprovisioning happen cleanly at close, without waiting on a slow crawl through every system those employees might touch.
In every case, the natural unit of the review is the person, and forcing that into an app-by-app structure means either running several certifications to answer one question, or manually stitching results together afterward.
Where User-Based Reviews Fall Short
Person-first reviews solve a real gap, but they're not a wholesale replacement for the other two entity types.
They're only as good as the identity data feeding the criteria. If department, contractor status, or cost center isn't accurately synced from the connected identity source, a criteria-based population rule can quietly exclude people who should have been in scope, and nobody notices until an audit asks why.
They're not built for continuous, standing coverage. A recurring application-based certification provides ongoing baseline hygiene across an entire app population. User-based reviews are strongest for defined, often time-boxed populations, a project team, this year's contractor cohort, not as the sole mechanism for catching drift nobody's specifically looking for.
They don't scale as a way to review an entire workforce one person at a time. Running a dedicated certification for every employee individually is impractical at any real headcount. User-based reviews work best scoped to a defined population, named individuals or a criteria-based segment, not as a substitute for reviewing your whole organization person by person.
Reactive reviews are only as fast as the integrations behind them. The security-incident use case depends on every relevant app being integrated and synced. If an app isn't connected yet, that user's access to it won't surface automatically, someone still has to know to check it by hand.
Making User-Based Reviews Actually Work
Tie them to real trigger events rather than running them as a standalone program. Offboarding, role changes, project closures, security alerts, these give user-based reviews their value because they map directly to a specific moment. Treat them as the response mechanism, not a replacement for your recurring baseline reviews.
Build criteria carefully and check the preview before launching. A slightly wrong filter, excluding contractors instead of including them, for instance, can silently shrink a population without anyone noticing until someone asks why a specific person wasn't reviewed.
Use user-based reviews to complement application- and group-based reviews, not replace them. They answer a person-shaped question well. They're not a substitute for the recurring, system-level hygiene that catches the drift nobody's actively asking about on any given day.
Where User-Based Reviews Fit in a Broader Program
If application-based reviews are the baseline and group-based reviews cover privileged access, user-based reviews are the response mechanism, reached for when a specific person, project, or event raises a question the recurring cycle wasn't built to answer on its own schedule. Programs without this entity type usually solve the same need with a cross-referenced spreadsheet built under time pressure during an incident or an audit request. A dedicated user-based review produces the same output without the manual reconciliation.
When to Use User-Based Reviews vs. the Other Two Types
The distinguishing signal is simple: if your review question starts with a system ("who's in this app," "who's in this group"), use application- or group-based. If it starts with a person or a defined population of people ("what does this person have," "what do these contractors have"), user-based is the entity type built for that question specifically.
See how setup works in Zluri for the full step-by-step walkthrough covering all three entity types, including reviewer assignment and remediation mechanics.
Frequently Asked Questions
Can a single user-based certification cover both application and group access?
Not within the same certification, you choose Applications or Groups as the scope when creating it. If you need both for the same population, that means two certifications with the same user scope but different resource scope, applications in one, groups in the other.
How is a user-based review different from just running five application-based certifications?
Mechanically, both eventually touch the same underlying access records. The practical difference is workflow: a user-based review lets you define the population once, see every relevant app or group per person in a single preview, and manage reviewers and remediation at the person level, instead of tracking the same five people across five separate certifications with five separate configurations.
Can I combine specific named users with criteria-based population rules in the same certification?
Yes. You can add specific users by name and layer criteria-based inclusion and exclusion rules on top, useful when you want a defined population plus a few named additions who don't otherwise match the criteria.
Do overrides work differently for user-based reviews compared to application- or group-based ones?
The mechanism is the same, entities can run on certification defaults or switch to Custom, but for user-based reviews the override applies at the individual user level, letting you assign a different reviewer or narrow the app/group scope for one specific person within a larger population-based certification.
What happens if a user in scope leaves the company before the review starts?
The same reviewer-resolution timing applies as everywhere else in Zluri: resolution happens at launch, not at configuration time. If a user included in the scope is deactivated before a "Start Later" certification actually launches, their record still enters the review, but reviewer assignment for their access follows standard Fallback Reviewer and Certification Owner logic if their usual reviewer is no longer valid.
Can user-based reviews replace the need for periodic application- or group-based certifications?
No, they answer a different question. Application- and group-based reviews provide ongoing, systemic coverage across an entire app or group population; user-based reviews answer a specific, often time-boxed question about a defined set of people. Most mature programs run both, not one instead of the other.
What identity data does a user-based review actually depend on?
Whatever attributes are synced from the connected identity source, commonly department, employment status, contractor flag, location, and manager. If an expected attribute isn't showing up as a filter option when building criteria, it usually means that attribute isn't being ingested from the identity source yet.
.svg)
