SaaS Authorization: When Access Reviews Fall Behind

A quarterly access review tells you who had access on the day someone ran the report. It says almost nothing about the days on either side of that snapshot, and that’s exactly where most SaaS access problems live. Your review calendar might say everything checks out. Meanwhile, a contractor’s Salesforce token from a project that wrapped in March is still active in July. A marketing hire’s Workday permissions never got scoped down after she moved teams. An AI agent someone spun up to summarize support tickets has quietly picked up read access to two data sources nobody approved. None of that shows up until the next review cycle, if it shows up at all.

Teams running access reviews are doing exactly what the framework asks of them; diligence was never the shortfall. The design of the control itself is the problem: a review is a point-in-time attestation applied to an environment that changes constantly. SaaS access doesn’t wait for a review to catch up. New apps get connected, integrations get authorized, and service accounts get spun up every week, sometimes every day. For most organizations, the mismatch between how often access changes and how often anyone checks it has become the real security gap, sitting in the distance between reviews rather than in the reviews themselves.

What an access review is built to catch

An access review, sometimes called a user access review or access certification, asks a manager, app owner, or security team to formally attest that a given identity’s access to a system is still appropriate. SOX, SOC 2, ISO 27001, and HIPAA all require some version of this: a named reviewer, a documented decision, and a timestamped record an auditor can pull months later.

Review and certification aren’t quite the same thing, and the difference matters here. A review is the act of looking at access and judging whether it’s still warranted. A certification is the signed, evidentiary version of that look, the kind that holds up when an auditor asks for proof after the fact. Neither one is in question as a control. Certification proves someone checked. It doesn’t prove that what got checked on review day still holds true on any other day of the quarter. That’s a separate problem, and it’s the one that’s gotten harder as SaaS footprints have grown.

Why the gap keeps widening

A decade ago, an enterprise ran access reviews against a few dozen core systems, most of them on a predictable provisioning cycle tied to HR events. The average company now runs on 106 SaaS applications, according to BetterCloud’s State of SaaS report, plus the API integrations connecting them, plus a growing population of service accounts and AI agents that never show up on an HR org chart at all. Gartner estimates the ratio of machine identities to human identities at 82 to one. Every one of those machine identities can hold access, and almost none of them wait for a review cycle before they start using it.

Quarterly reviews were built for an environment where access changed in step with headcount. SaaS access changes in step with product launches, vendor trials, contractor onboarding, and whatever integration an engineering team connected last Tuesday to unblock a sprint. The review calendar stays fixed. The attack surface doesn’t. Provisioning keeps happening between review dates, offboarding keeps lagging behind departures, and scope keeps expanding, none of it tied to the control that’s supposed to catch it.

A review only ever describes the moment it was run. Everything that happens in a SaaS environment between that moment and the next review sits outside governance entirely, and that’s a mechanical gap, not a carelessness problem: the control fires on a schedule, and no schedule keeps pace with an environment that changes daily. Closing that gap means changing what enforces access between reviews, not just how often someone looks at it.

What lives in the blind spot

Picture the ninety days between two review cycles, a common cadence for mid-size companies. A contractor finishes an engagement in week two. Their Salesforce and Slack access gets flagged for removal, but the ticket sits in an IT queue for three weeks because nobody owns SaaS offboarding end to end. A finance analyst switches teams in week five and keeps her old NetSuite permissions because nobody remembered to revoke them, then picks up new ones for her new role on top of the old. An AI agent built to summarize support tickets gets connected to a billing data source in week seven so it can pull payment history too, a scope expansion nobody logged as an access change because, technically, no human filed a request for it.

By the time the next review runs, all three of those identities show up with access that looks plausible enough to wave through. A reviewer scanning a spreadsheet of two hundred permissions has no way to know the contractor’s account sat unused for weeks before anyone flagged it, or that the AI agent’s scope grew without anyone signing off on it. The review passes all three, and the reviewer did nothing wrong. The review checked a snapshot, exactly as designed. Policing the ninety days that led up to it was never part of the job.

Why faster reviews aren’t the same as closed exposure

A real and growing category of tools automates the mechanics of access review: pulling entitlement data from every connected SaaS app, flagging stale or high-risk permissions with a model instead of a spreadsheet macro, routing sign-off to the right manager, and generating audit-ready evidence the moment a reviewer clicks approve. That’s a genuine improvement over the quarterly export-to-Excel exercise, and if your reviews still run that way, automating the workflow is worth doing regardless of what else changes.

It still doesn’t touch the underlying design problem. A faster, smarter review is still a review: a decision made at one point in time about access that keeps getting used at every other point in time. Running certification weekly instead of quarterly shrinks the blind spot. It doesn’t remove it, and at SaaS scale, with new integrations and agents appearing daily, even a weekly cadence leaves days of unmonitored standing access sitting on the table. The contractor’s Salesforce token is still live the moment their contract ends, no matter how soon your next review happens to catch it.

Closing the gap with runtime authorization

Closing this gap means removing the snapshot from the critical path entirely, not making the snapshot faster. Runtime authorization evaluates every access request against policy at the moment the request happens, not against a role assignment someone configured back in March. Instead of granting a contractor standing access to Salesforce for the length of an engagement, the platform makes an access decision and re-evaluates it every time that contractor’s account tries to read a record, checking whether the engagement is still active, what the request is for, and what current policy allows.

This is the logic behind Zero Standing Privileges: no identity, human or machine, holds a persistent grant sitting there waiting to be misused between reviews. Every access decision gets evaluated when it’s requested, so an offboarded contractor’s token stops working the moment the offboarding event fires, not three weeks later when a ticket finally clears. An AI agent that tries to reach a data source outside its approved scope gets stopped at that specific request, not flagged after the fact during the next certification cycle.

PlainID’s Runtime Authorization Platform sits underneath your existing identity stack rather than replacing it. Your IGA and identity provider tools, whether that’s Okta, Microsoft Entra ID, Ping Identity, SailPoint, or Saviynt, still own who an identity is and what role it was provisioned into. Through centralized Policy-Based Access Control (PBAC), PlainID evaluates every access request against real-time business policy, adding the critical layer that governs what that identity can access, do, and expose the moment an access request occurs , enforced through pre-built Authorizers across your SaaS applications, APIs, and data layers, with policy changes taking effect in under 60 seconds instead of waiting on a development cycle. The Authorization Graph then gives you a continuous, queryable record of who accessed what, when, and against which policy, so your next audit pulls from a live system of record instead of a manually assembled spreadsheet.

Access reviews don’t disappear in this model. They change jobs. Instead of standing as the last line of defense against three months of accumulated standing privilege, they become the periodic check that your runtime policies still match business reality, a smaller and more accurate exercise once the platform is the thing enforcing access every hour in between.