Ask any IT manager or GRC analyst what their least favorite part of the quarter is, and access reviews come up consistently. Not because the concept is wrong — verifying that users have appropriate access is exactly what security and compliance require — but because the execution is consistently painful in ways that compound as the organization grows. The pain isn’t evenly distributed across the process. There are three specific failure points where most of the friction lives, and they’re worth understanding precisely because they’re also where most teams are looking for relief.

How Painful Are Access Reviews Actually? Very, and in specific ways that generic “IAM is complex” framing understates. The core problem is that access reviews require accurate, complete data about who has access to what — and most organizations don’t have it in a form that supports meaningful review. What they have instead is a collection of partial pictures: SSO logs that show federated application access, manual exports from individual applications, HRMS records that may or may not reflect current employment status, and a growing tail of applications that appear in none of these sources. When an access review cycle starts, the first task is assembling these partial pictures into something reviewers can act on. That assembly is manual, slow, and produces a result that’s already partially out of date by the time it reaches reviewers. One commonly cited pattern: teams discover during audit prep that significant portions of their access logs are incomplete or missing — not because anyone failed to do their job, but because the systems weren’t designed to produce the evidence the audit requires. The downstream effect is audit-cycle firefighting: a predictable, recurring crisis that organizations experience every quarter or every year because the underlying process hasn’t changed, just the calendar.

What Are the Three Specific Pain Points? Manual User List Downloads and the Spreadsheet Trap The dominant access review workflow in most organizations is still export-based: download a user list from the IdP or application, put it in a spreadsheet, distribute to reviewers, collect responses, reconcile. This process has two structural problems that don’t go away regardless of how carefully it’s executed. First, the list is stale the moment it’s exported. Users join, leave, and change roles continuously. A snapshot taken at the start of a review cycle may not reflect the reality at the end of one, let alone at the time of the next scheduled review. Second, the list is incomplete by definition. SSO-generated exports show access to SSO-connected applications. They don’t show access to the applications that were never connected to SSO — the vendor portals, legacy systems, departmental tools, and AI applications that employees are using but that never went through formal IT onboarding. Estimates for the share of enterprise applications outside formal IT oversight consistently run above 60%. An access review based on SSO exports is reviewing less than half of the actual access estate. Deviations Between the IdP and the Reviewed System The identity provider shows a user as inactive. The application still shows them as active. This deviation — between what the IdP believes is true and what the application actually contains — is one of the most common and highest-risk gaps in access management. It happens because IdP-driven deprovisioning works only for applications that are formally connected to the IdP. Deactivate a user in Okta or Entra ID, and the SSO authentication path closes. But the local application account, created when the user first authenticated or provisioned before SSO was configured, persists. If the application supports alternative login methods, the user’s data and access remain reachable even after their IdP account is deactivated. The result is orphaned accounts: active application accounts linked to users who left the organization weeks or months ago. Organizations that have discovered this pattern through audits often find accounts persisting for four to eight months after departure — long enough for the access to be exploited, long enough to represent a material audit finding, and evidence that the offboarding process has been operating on blind trust rather than verified revocation. Reconciling IdP state with application-level account state is the technical problem that manual access reviews are trying to solve with spreadsheets — and why the spreadsheet approach is insufficient. By the time a reviewer compares the two exports, the data may have changed in either system. Not Knowing the Exact Permissions Knowing that a user has access to an application is the easy part of an access review. Knowing what they can do within that application — what role they hold, what data they can read or modify, what administrative functions they can perform — is where most review processes break down. Application permission structures are rarely exposed through IdP exports. They typically require separate exports from the application itself, often in formats that don’t map cleanly to the user list from the IdP. For applications with complex permission hierarchies — enterprise platforms where roles are composed of individual entitlements, where group membership determines access, where effective permissions are the product of multiple overlapping configurations — assembling a complete picture of what a user can actually do may require pulling from several different sources. Without this depth, access reviews devolve into presence checks: confirming that a list of users has access to a list of applications, without any ability to evaluate whether the access level is appropriate. A reviewer looking at a spreadsheet of 500 names with no usage data and no permission detail is not in a position to make a meaningful revocation decision. They’re in a position to rubber-stamp, which is what most of them do — not from carelessness, but because the data required to decide otherwise wasn’t provided.

How Are Teams Actually Solving This? The approaches that are making access reviews tractable fall into three categories, each addressing one of the pain points above. Multi-Source Discovery Instead of Single-Source Exports The completeness problem — reviews that miss the 60% of applications outside SSO — requires discovery that pulls from multiple signal sources rather than a single export. Browser agents that track URL-based application launches surface applications employees are accessing regardless of whether those applications are SSO-connected. Financial and expense data surfaces subscription-based tools that were purchased outside IT oversight. Direct API integrations with connected applications pull current account and permission data rather than relying on manual exports. The combination produces an application inventory that reflects what’s actually in use rather than what IT formally manages — a meaningfully more complete starting point for access reviews. Activity-Driven Context for Reviewers The rubber-stamping problem — reviewers approving access they can’t meaningfully evaluate — is a data problem. Reviewers rubber-stamp when they don’t have the information needed to make a real decision. Providing usage data alongside the access record changes the dynamic: a reviewer who can see that a user holds an admin role they haven’t used in 90 days has a basis for a revocation decision that they didn’t have when looking at a static name on a list. Usage activity — when was the application last accessed, how frequently, at what permission level — converts access reviews from presence audits into meaningful evaluations of whether access is being used appropriately. Automated Reconciliation for IdP-Application Deviations The deviation problem — IdP state and application account state diverging — requires continuous reconciliation rather than point-in-time comparison. When a user’s IdP status changes, the governance layer checks whether their application-level accounts reflect that change — and flags or automatically remediates any accounts that don’t. This converts a problem that surfaces during quarterly reviews into one that surfaces in real time, reducing the window between a user leaving and their orphaned access being identified from months to hours.

Is This a Real Problem Worth Solving? Yes, clearly. The consistency of the pain points across organizations of different sizes and industries — manual exports, IdP-application deviations, permission depth gaps — reflects structural limitations in how access reviews have historically been conducted rather than execution failures by individual teams. The teams experiencing this pain most acutely are those where the access estate has grown faster than the review process has scaled: organizations that have added applications faster than they’ve added governance, or that have grown headcount faster than their access management processes were designed to handle. The question for anyone evaluating solutions — whether commercial tools or purpose-built alternatives — is which of these three pain points the solution actually addresses. Tools that improve the review interface without improving the underlying data don’t solve the rubber-stamping problem. Tools that automate SSO-connected exports without expanding to non-SSO applications don’t solve the completeness problem. And tools that show access without showing permissions don’t give reviewers what they need to make meaningful decisions. Solving one of the three partially is an improvement. Solving all three changes the character of the process.