Launching your first access review without losing control

At a glance

What this is: Zluri outlines a five-step approach to launching a first access review, arguing that visibility, scope, ownership, review execution, and remediation must be sequenced correctly for the process to work.

Why it matters: IAM and IGA teams need a workable first-pass model because access reviews fail when discovery is incomplete, reviewer ownership is unclear, or remediation is not tied to evidence and follow-through.

By the numbers:

• Manual discovery is expected to cover 40-60% of actual apps, according to the article.
• Basic automation is expected to cover 50-75% of actual apps, according to the article.
• Comprehensive automation is said to reach 99%+ of actual apps, according to the article.

Context

Access reviews only work when an organisation can see what access exists, who should review it, and what happens after a decision is made. This article frames the practical launch problem for IAM and IGA programmes: the control is familiar, but the operating model is usually incomplete.

The underlying issue is not whether reviews are worthwhile, but whether the first review can be scoped, assigned, executed, and evidenced without creating a dead-end process. That makes access reviews a governance and lifecycle problem, not just a compliance task.

Key questions

Q: What breaks when organisations launch access reviews without full visibility?

A: They certify only the access they can see, which usually means the review excludes shadow IT, embedded apps, and non-SSO tools. That creates false confidence because the process looks complete while leaving a large part of the access estate untouched. The first control is discovery, not approval.

Q: Why do access reviews become unmanageable when teams try to review everything at once?

A: Because scope and volume overwhelm reviewers before they can make meaningful decisions. A first review needs a smaller, risk-based set of applications so managers, app owners, and security can assess access with context instead of turning the process into mass approval.

Q: What are the signs that an access review process is failing in practice?

A: A failing access review process usually shows up as long approval cycles, overloaded reviewers, repeated manual preparation, and heavy engineering effort just to launch each campaign. If reviewers need multiple sources to understand a user’s access, or facilitators spend weeks coordinating certifications, the process is not scaling. Those are clear signs the workflow needs better automation and better access context.

Q: Should organisations use group-based or user-based access reviews?

A: Use group-based reviews when access is commonly granted through SSO groups, because the review boundary matches how access is actually administered. Use user-based reviews for individually assigned access and privileged accounts. The right choice is the one that reflects the operating model, not the one that feels simpler on paper.

Technical breakdown

Why visibility comes before certification

Access certification depends on knowing what applications, identities, and entitlements exist. If discovery is incomplete, the review sample is biased from the start and the process certifies only a fraction of the real access estate. The article distinguishes between IDP data, finance records, and broader discovery methods because each reveals a different slice of the environment. In practice, this is why shadow IT and non-SSO SaaS matter so much: they are often invisible to the systems that teams treat as authoritative.

Practical implication: build discovery before launching certification, or the review will validate an incomplete access inventory.

How scoping turns an impossible review into a manageable one

Scope is the control point that prevents a first access review from collapsing under volume. Rather than reviewing every user and every application, the article recommends prioritising high-risk apps first, especially systems with financial, customer, privileged, contractor, or compliance-sensitive access. That sequencing matters because access review quality declines when reviewers are overwhelmed. The model also separates user-based from group-based scoping, which changes the unit of review and can cut effort dramatically where access is group-driven.

Practical implication: define tiered scope and choose the review unit that matches how access is actually granted.

Why reviewer assignment is a governance control, not admin work

The article shows that certification fails when ownership is vague. Managers, application owners, and security teams each have different context, so the review model has to map access types to the right reviewer class. This is a governance design decision because the reviewer determines whether approvals reflect business need, application sensitivity, or risk. Hybrid assignment is therefore not a convenience feature; it is how the process preserves accountability without forcing one team to make decisions outside its knowledge boundary.

Practical implication: assign reviewers by access type and risk, then document who owns each decision path before the review starts.

NHI Mgmt Group analysis

Access reviews fail first at discovery, not at approval. The article shows that organisations often start certification before they have a trustworthy view of applications, users, and group-based entitlements. That is a governance failure because the review is only as complete as the inventory behind it. In IAM terms, the control is being asked to certify an estate it does not fully know, which turns review into partial assurance. The practitioner conclusion is simple: treat discovery as the prerequisite control, not a preparatory task.

First access review is a lifecycle problem disguised as a compliance exercise. The sequence of visibility, scope, assignment, review, and remediation is the real operating model. Each step depends on the prior one, which is why incomplete handoff after certification is so damaging. If removals are not executed and evidenced, the review becomes a reporting event rather than an identity governance control. The practitioner conclusion is to design the process around lifecycle closure, not around the meeting where decisions are made.

Group-based review changes the economics of access governance. Where access is granted through SSO groups, certification at the group level is often a better control boundary than reviewing users one by one. That does not eliminate accountability, but it changes the review from identity enumeration to entitlement governance. For mid-market environments with large user counts and shared access patterns, this is a more realistic way to scale review cadence without turning every cycle into manual triage. The practitioner conclusion is to align the review unit with how access is actually administered.

Reviewer selection is the hidden control that determines whether a certification is meaningful. Managers, app owners, and security teams each hold different pieces of the decision context, and the article rightly separates those responsibilities. A manager can validate role fit, an app owner can validate app-specific access, and security can challenge elevated or external access. If a single reviewer class is forced across all access types, the process loses precision and the approvals become noisy. The practitioner conclusion is to match decision authority to the type of access being reviewed.

Remediation and documentation are part of the control, not the aftermath. The article makes clear that a review is unfinished if denied access is not removed and evidence is not captured. That is where many programmes appear successful on paper but fail under audit or operational follow-through. For identity teams, the lesson is that certification, removal, and recordkeeping must be wired together from the outset. The practitioner conclusion is to design for closure, because an access review that cannot prove action is not complete.

What this signals

First-review design matters more than review frequency. Quarterly access reviews do not create governance value if the initial review cannot reconcile discovery, scoping, reviewer assignment, and remediation. For identity programmes, the launch sequence is the control, because it determines whether certification becomes repeatable or collapses into manual exception handling.

Access review maturity is defined by closure, not completion. Many teams can run a certification campaign, but fewer can prove that denials were removed and evidence was retained. That distinction matters for IAM, IGA, and audit readiness because an access review only reduces risk when the governance loop ends in enforced change.

For practitioners

• Build discovery before certification Pull app data from your IDP, finance systems, and department sources so the first review covers the real application estate rather than only what one system can see.
• Scope the first review to high-risk apps Start with financial, customer, privileged, contractor, and compliance-sensitive systems, then expand coverage after the process is proven.
• Choose the right review unit Use group-based review where access is granted through SSO groups, and reserve user-level certification for individually assigned or privileged access.
• Assign reviewers by decision context Map managers to standard user access, app owners to application-specific access, and security to external or elevated access so each reviewer sees what they can actually judge.
• Connect denial decisions to remediation Require every denied entitlement to generate a removal task and an evidence record so the review closes with provable action, not just completed approvals.

Key takeaways

• The central problem is not deciding whether access reviews matter, but building the launch sequence so the first review covers real applications, real owners, and real remediation paths.
• The article shows that visibility, scoping, reviewer assignment, and evidence capture are the controls that determine whether the process is operationally usable.
• For IAM and IGA teams, the practical lesson is to start with a smaller, risk-based review and prove closure before expanding the programme.

Key terms

• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
• Entitlement Scope: Entitlement Scope is the exact set of actions, resources, or permissions attached to an identity during a session. In cloud and NHI governance, scope is as important as duration because broad permissions can turn a short-lived grant into a high-impact access event. Narrow scope is a core control objective.
• Reviewer Ownership: Reviewer ownership is the assignment of a specific accountable person or role to approve, reject, or modify access during recertification. It matters because reviews without clear ownership tend to be delayed, inconsistently judged, or impossible to defend in audit evidence.
• Remediation Closure: Remediation closure is the point at which a discovered access issue is actually fixed, not just logged. It matters because exposure only falls when stale accounts, excess permissions, or risky connectors are removed, justified, or re-scoped in the live environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.