An application-based access review starts with the app, not the person. You pick Salesforce, Okta, or Slack, pull every user who touches it, and get someone qualified to sign off on whether that access still makes sense.
If you've ever run an access review, this is probably the version you've run.
Application-by-application certification is how the market has approached access governance for years, long before dedicated identity governance platforms existed. For a huge share of review programs, it's still the right starting point.
This article breaks down exactly how application-based reviews work, when to reach for them instead of group- or user-based reviews, and what the setup looks like in a modern platform like Zluri, from certification creation through remediation.
What an Application-Based Review Actually Does
An application-based review answers one question: "Who has access to this app, and should they?"
You select an application (or a set of applications by criteria), pull in the users tied to that app, assign reviewers, and let them approve, modify, or revoke access record by record. What gets surfaced during the review is scoped entirely to that application:
- Roles
- Licenses
- Last login
- Department
- And other contextual risk insights
This is the structure most compliance frameworks were originally written around, and the one most access review processes, spreadsheet-driven or otherwise, still default to. It's different from asking:
- "What does this person have access to across everything" (that's a user-based review)
- "Who belongs to this group" (that's a group-based review)
Application-based reviews are vertical: one app, every user under it.
When Application-Based Is the Right Call
Application-based reviews fit best when the review question is naturally anchored to a system, not a person or a group. A few patterns where this is clearly the right entity type:
Recurring compliance certifications on a specific system. SOX-regulated financial systems, HIPAA-covered platforms, PCI DSS payment tools, these usually need a standing quarterly or annual certification tied to the app itself, regardless of who's using it in any given cycle.
Post-integration cleanup. You just connected a new SaaS tool and provisioned a batch of users during rollout. An application-based review lets you validate that provisioning decision was correct, in one pass, scoped to exactly that app.
High-risk or business-critical single-app reviews. Salesforce, GitHub, your identity provider, these are the applications where "who has access" is a standing security question independent of any particular reorg or project. A recurring app-based certification keeps that question answered continuously.
Vendor and third-party risk questionnaires. When a customer's security team or a TPRM assessment asks "who has access to the system that touches our data," an application-based review is the direct, exportable answer to that exact question, scoped to precisely the system in question.
If your actual question is "what should this specific group of contractors still have access to across five systems," application-based reviews force you into five separate certifications to answer one question. That's the signal to use a user-based review instead.
Where Application-Based Reviews Fall Short
Reviewing one app at a time is the most common approach in the market, but it has blind spots worth knowing before you build a program entirely around it.
Access granted through group membership doesn't always show up in an app-level review. Someone can hold admin rights to an application entirely because of an Okta or Azure AD group they belong to. If that group itself never gets reviewed, an app-based certification can validate the person's direct role while missing the elevated access sitting one layer above it.
Reviewer fatigue sets in fast. Same reviewer, same list, every quarter. If the population barely changes cycle to cycle, the review can quietly turn into a rubber-stamp exercise. Auditors increasingly treat a near-100% approval rate as a red flag that reviews aren't rigorous, not as proof access is clean.
Coverage gaps hide in the apps that never made it into the program. A review process that's airtight on the top ten business-critical apps but silent on the other few hundred doesn't reduce risk proportionally to the effort spent, it just moves the exposure to whatever isn't being watched.
It's siloed by design, and that cuts both ways. A person can pass five separate app-based reviews cleanly while holding a combination of access, across those five apps, that's excessive in aggregate. No single app-scoped review is built to catch that; it takes a person-level view to see it.
Making Application-Based Reviews Actually Work
Risk-tier your applications instead of applying one cadence to everything. Financial systems, your identity provider, source code repositories, these deserve quarterly or even continuous review. Low-risk internal tools can reasonably run on an annual cycle. Treating every app the same wastes reviewer attention on low-stakes systems while under-reviewing the ones that matter.
Surface usage data prominently, not as an afterthought. Last login and app role matter, but if that data isn't front and center in the review interface, reviewers default to approving based on a name they recognize rather than evidence the access is still needed.
Watch approval rates over time, not just per cycle. A population that gets approved at close to 100% every quarter, with almost no Revoke or Modify decisions, is usually a sign the review has become a formality rather than evidence the access is genuinely clean.
Rotate or spot-check reviewer assignments. If the same App Owner is the only person who's ever looked at a given app's access list, that's a single point of failure in your control, not a strength.
Where Application-Based Reviews Fit in a Broader Program
Most mature access governance programs don't run one review type in isolation. Application-based reviews are usually the recurring baseline, because they map directly onto individual compliance controls and give auditors a clean, system-by-system trail. Group-based reviews layer on top for privileged and administrative access, and user-based reviews handle the event-driven, person-specific questions that a recurring app cycle isn't built to answer. Treat application-based reviews as the steady-state foundation, not the entire program.
Application-Based vs. Group-Based vs. User-Based
Read the deep dives on group-based access reviews and user-based access reviews for the other two entity types, or see how setup works in Zluri for the full step-by-step walkthrough across all three.
Frequently Asked Questions
Can one certification cover multiple applications at once?
Yes. You can add specific applications individually or use criteria-based scoping to pull in a whole class of apps (by type, category, or restricted status) into a single certification, each with its own reviewer and remediation configuration via overrides.
What's the difference between a default reviewer and an override?
Defaults apply to every application in the certification unless you specify otherwise. Overrides let you customize the reviewer, data visibility, or remediation playbook for individual applications within the same certification, without creating a separate one.
Do application-based reviews support recurring schedules?
Yes. You can set monthly, quarterly, or custom recurrence up to 12 months. Zluri anchors future instances to the first certification's start date, so the review-to-remediation interval stays consistent across every cycle.
What happens if an app has no App Owner assigned?
The review falls to the configured Fallback Reviewer, which must be a named individual. If no Fallback is configured or valid, it defaults to the Certification Owner, so no application ever goes unreviewed for lack of an assigned owner.
Can I require more than one person to sign off on the same application?
Yes, application-based reviews support up to five sequential reviewer levels. Each level reviews independently and must sign off before the next level can see and act on the record. See the full breakdown of multi-level access reviews for how reviewer resolution, fallbacks, and sign-off sequencing work across levels.
How often should application-based reviews actually run?
It depends on the app's risk tier rather than a fixed calendar rule. Financial systems, identity providers, and anything holding regulated data typically warrant quarterly or continuous review; lower-risk internal tools can reasonably run annually. A single cadence applied across every app usually means over-reviewing what doesn't matter and under-reviewing what does.
What's a sign an application-based review program has gone stale?
Approval rates sitting near 100% cycle after cycle, for the same population, with almost no Revoke or Modify decisions. That pattern usually means reviewers are rubber-stamping rather than genuinely evaluating access, not that the access itself is clean.
.svg)
