Access Reviews and Certification Guide

Access reviews are one of the most widely required and least loved identity controls. Auditors expect them and standards name them, yet reviewers frequently approve everything because they face hundreds of items, no context and a deadline. The result is a signed-off record that changes nothing. This guide explains how to design access reviews (also called access certifications or recertifications) that remove unnecessary access for people, service accounts, OAuth apps and AI agents. It is written for identity governance teams, application owners, auditors and security leaders who own or depend on review campaigns.

Key takeaways

• Removal is the point. The purpose of an access review is to remove access that is no longer needed. Measure success by revocations and risk reduced, not completion rates.
• Rubber-stamping is the main failure mode. Reduce volume, add usage and peer context, and focus reviewers on the risky items.
• Use risk-based and event-driven reviews alongside periodic campaigns: review when people move, when access goes unused and when privilege is high.
• Include non-human identities. Service accounts, API keys, OAuth grants and AI agents are often never reviewed, and CIS Safeguard 5.5 expects service account reviews at least quarterly.
• Close the loop: revocations must be carried out in the target system and verified, or the review has only produced paperwork.

Why reviews are required

Access reviews are the detective half of least privilege. Provisioning decides who should get access; reviews find the access that should no longer exist because people moved, projects ended, integrations were abandoned or a grant was too broad from the start. NIST CSF 2.0 states the outcome directly in PR.AA-05: access permissions, entitlements and authorisations are "defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties".

Most control frameworks turn that outcome into a recurring obligation. Frequencies vary, so confirm the requirements that apply to you; the table below summarises what the main sources say.

For access reviews as a SOX IT general control, see the SOX ITGC Guide and, for obligations by jurisdiction, the Identity Security Regulatory Map.

Types of review

No single review type covers everything. Managers know what their people do but not what an entitlement means; application owners know the system but not the people. Combine types so each decision goes to the person best placed to make it.

Cadences in the last column are common starting points, not requirements; set yours by risk and by the obligations in the previous section. Platforms support several of these models: Microsoft Entra ID, for example, lets you assign specified reviewers, group owners or self-review depending on the resource, and supports multi-stage reviews in which two or three independent sets of reviewers decide one after another. Some platforms now add AI agents that recommend decisions; our Agentic AI in IAM Operations Guide covers how to control them.

Why reviews fail

Reviews fail for predictable, human reasons. Each cause below has a design answer in the next section.

• Volume: reviewers face hundreds of line items at once and approve in bulk to finish.
• No context: entitlement names such as "GRP_FIN_RW_03" mean nothing to a manager.
• No usage data: reviewers cannot see whether access has been used in months.
• Wrong reviewer: managers are asked to judge technical entitlements they do not understand, and nobody is asked about service accounts.
• No consequences: approving everything has no cost, while revoking risks complaints and outages.
• Unsafe defaults: reviews that time out to "approve" keep every unreviewed grant, while defaults that remove access without care can cut off critical processes.
• No follow-through: revocations are logged but not executed in target systems, especially disconnected applications handled by ticket.
• Incomplete scope: the campaign covers the identity provider but not local accounts, cloud IAM, SaaS admin roles or databases.

Designing effective reviews

Reduce volume

• Exclude birthright access granted automatically by role and review it at the role level instead. See the Role Mining and Role Design Guide.
• Remove clearly unnecessary access (for example, unused for 90 days) automatically with owner notification, instead of asking reviewers. CIS Safeguard 5.3 sets a 45-day inactivity threshold for disabling dormant accounts, where supported.
• Split large campaigns into smaller, more frequent reviews by application or risk tier.
• Scope some reviews to inactive users only. Entra ID can limit a group review to users who have not signed in, interactively or non-interactively, for a set number of days.

Add context

• Show human-readable entitlement descriptions, risk level and data sensitivity.
• Show last used date and how access was granted (role, request, exception). AWS IAM last accessed information, for instance, records service-level activity over a tracking period of at least 400 days.
• Highlight outliers: access that peers in the same role do not have. Entra ID's user-to-group affiliation helper recommends denial for users who are distant from the rest of the group in the reporting structure.
• Flag segregation of duties conflicts. See the Segregation of Duties Guide.

Focus on risk

• Review privileged and sensitive access more often (for example, quarterly) and low-risk access less often.
• Trigger reviews on movers, long-term leave, contractor extensions and dormant access. NIST SP 800-53 PS-5 requires a review of ongoing need when people transfer. See the Joiner-Mover-Leaver Guide.
• Replace standing privileged access with time-bound elevation where possible, so there is less to review. See the JIT Access Guide and the Privileged Identity Management (PIM) Guide.

Make decisions accountable

• Require justification for approving high-risk access. Entra ID offers a "Justification required" setting that makes reviewers give a reason for each decision.
• Detect rubber-stamping, such as approving hundreds of items in seconds, and escalate.
• Report revocation rates by reviewer and department, and have a second stage review the highest-risk approvals.

Close the loop

• Execute revocations automatically through provisioning connectors, or through tracked tickets with deadlines for disconnected applications.
• Choose defaults deliberately. In Entra ID, "Auto apply results to resource" removes denied users when the review ends; Microsoft warns that if non-response is set to remove access or take recommendations with auto-apply on, all access to a resource could be revoked if reviewers fail to respond.
• Verify removal in the target system, not only in the governance tool. A practical template is the Access Review Checklist.

Reviewing non-human identities

NHIs rarely appear in review campaigns because they have no manager and no HR record. Yet they hold some of the broadest access in the estate, and the OWASP Non-Human Identities Top 10 lists Improper Offboarding (NHI1), Overprivileged NHI (NHI5) and Human Use of NHI (NHI10) among the top risks: all three are things a good review catches.

Make NHIs reviewable

• Assign owners first: a named person and a team. See the NHI Ownership Guide.
• Keep an inventory with owner, purpose and review date, as CIS Safeguard 5.5 requires for service accounts. See the Service Account Inventory Template.
• Collect usage evidence: permissions granted versus used, credential age and last activity. Cloud tools help; AWS IAM Access Analyzer can report unused roles, unused access keys and passwords, and unused permissions within a usage window you set.

What owners should confirm

OAuth apps, integrations and AI agents

• Include OAuth apps and SaaS integrations, with scopes, vendor and the users who consented. See the SaaS and OAuth App Governance Guide.
• Include AI agents, with their tools, data access, delegated permissions and autonomy level. An agent that acts on behalf of a user should be reviewed against both its own grants and the user's. See the Agentic AI Identity Guide and the Identity Governance for AI Agents Guide.
• Agents and integrations change faster than quarterly cycles, so pair periodic review with event-driven review when an agent gains a tool, scope or data source.

The Cloudflare Thanksgiving Breach 2023 shows why usage evidence matters. Cloudflare says it failed to rotate one service token and three service account credentials after the Okta compromise "because mistakenly it was believed they were unused", and that was how the attacker got in. See the Service Account Security Guide.

Detection and monitoring

Reviews are periodic; abuse is not. Monitoring between campaigns catches what reviews miss and shows whether the review process itself is working.

• Dormancy: alert on accounts and credentials with no activity past your threshold, and on dormant accounts that suddenly become active.
• Privilege changes: alert when an identity is added to an administrator group or privileged role outside the request process. Cloudflare's SOC was alerted two minutes after the attacker added a service account to an administrator group.
• Atypical NHI use: NIST SP 800-53 AC-2(12) calls for monitoring system accounts for atypical usage and reporting it; interactive sign-ins by service accounts are a strong signal.
• Review behaviour: track decision time, approve-all rates and reviewers who never revoke.
• Revocation drift: reconcile target systems against review outcomes and alert when revoked access reappears.

Posture tools can do much of this continuously. See the ISPM Guide and the Cloud PAM and CIEM Guide.

Metrics that show progress

Collect these as evidence once and reuse it for auditors. See the Audit Evidence and Continuous Controls Monitoring Guide.

Framework mapping

Control IDs were checked against NIST CSF 2.0, the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls safeguard text and the OWASP NHI Top 10 2025. ISO/IEC 27001:2022 Annex A control names come from a published Annex A index, as the ISO text itself is paywalled. This is an indicative NHI Mgmt Group alignment, not an official crosswalk.

Common failure patterns

• Completion as the goal: the campaign closes at 100% on time with almost no revocations, and the dashboard reports success.
• Dormant accounts left for the next campaign: an unused account stays enabled because nobody reviews it between cycles. The Colonial Pipeline Ransomware Attack 2021 began, according to Mandiant, with a VPN account that was no longer used but had not been disabled.
• "Probably unused" without evidence: decisions about service accounts and tokens made from memory rather than activity data, as in the Cloudflare Thanksgiving Breach 2023.
• Credentials reviewed for existence, not age: in the Snowflake Breach 2024, Mandiant found credentials that in many cases had not been rotated for as long as four years on instances that did not require MFA. A review that asked about credential age and authentication method would have flagged them.
• NHIs outside the campaign: service accounts, OAuth apps and agents are excluded because they do not fit the manager model, so they are never reviewed.
• Revocations that never happen: decisions to remove access sit in tickets for disconnected systems and are closed without verification.
• Exceptions that never expire: approved exceptions and policy exclusions are not reviewed again. Microsoft lists maintaining a policy's exception list as a use case for access reviews.

Implementation roadmap

To judge where your programme stands before you start, see the Identity Governance Maturity Model. For cloud estates, the Cloud IAM Review Checklist covers roles and policies that IGA tools often miss.

Practitioner checklist

• Define review scope, frequency and reviewers by risk and by the obligations that apply.
• Reduce volume through birthright exclusions and automatic removal of unused access.
• Provide context: descriptions, last-used data, peer comparison, risk and SoD conflicts.
• Add event-driven reviews for movers, dormancy, privilege changes and anomalies.
• Include service accounts, API keys, OAuth apps and AI agents, each with a named owner.
• Ask NHI owners about need, permissions, credential age and human use, with evidence.
• Require justification for privileged approvals and use a second stage for the riskiest items.
• Set non-response and auto-apply defaults deliberately and document the choice.
• Automate revocations and verify them in the target system.
• Monitor dormancy, privilege changes and atypical NHI use between campaigns.
• Measure outcomes (revocations, time to removal, coverage), not just completion.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• CIS: CIS Critical Security Controls Version 8.1
• CIS: Controls Assessment Specification, Safeguard 5.5 Inventory of Service Accounts
• PCI Security Standards Council: Document Library (PCI DSS v4.0.1)
• ISMS.online: ISO 27001:2022 Annex A Explained
• OWASP: Top 10 Non-Human Identities Risks 2025
• Microsoft Learn: What are access reviews?
• Microsoft Learn: Create an access review of groups and applications
• AWS: Refine permissions in AWS using last accessed information
• Cloudflare: Thanksgiving 2023 security incident
• Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion

Related NHI Mgmt Group resources: IAM and IGA Basics · IGA Buyer's Guide · Role Mining and Role Design Guide · Access Review Checklist · NHI Ownership Guide