TL;DR: PlainID argues that quarterly access reviews only certify a snapshot, while SaaS permissions, tokens, integrations, and AI agent access continue changing between cycles, leaving contractors, movers, and service accounts outside governance until the next attestation. Snapshot-based certification cannot control a continuously changing SaaS estate.
At a glance
What this is: This is an analysis of why SaaS access reviews miss real risk between certification cycles, with the key finding that point-in-time review cannot govern continuously changing permissions.
Why it matters: It matters because IAM, IGA, and PAM teams need controls that govern access between reviews, especially where SaaS, service accounts, and AI agent permissions can change faster than certification workflows.
👉 Read PlainID's analysis of why SaaS access reviews fall behind between cycles
Context
SaaS access reviews are a governance control, not a runtime enforcement control. The article argues that the problem is not whether reviewers do their job, but that the control only captures a single moment while SaaS entitlements, tokens, integrations, and agent permissions keep moving.
For IAM and IGA programmes, that creates an exposure window between review dates. Access can be added, widened, or left active after role change or offboarding, and the next certification cycle may simply ratify a state that was already outdated when it was checked.
Key questions
Q: What breaks when SaaS subscriptions are not tied to access reviews?
A: Orphaned subscriptions and stale entitlements start to accumulate because no one revalidates whether the access still matches the job. That creates audit gaps, wasted spend, and higher risk when former users or inactive teams retain access. The result is a control environment that tracks billing better than identity.
Q: Why do SaaS permissions keep creating risk after a review passes?
A: Because the risk is created by change after the review, not necessarily by the review itself. Access can become stale, over-scoped, or unused immediately after certification if offboarding, role changes, or integrations keep moving. A clean review result only means the state was acceptable at that moment, not that it remained acceptable.
Q: How can security teams tell whether privileged access reviews are actually working?
A: They are working when every privileged entitlement is inventoried, every decision is traceable, and revoked access is removed from all connected systems without delay. If the organisation can only show approvals but not downstream revocation, the review is administrative recordkeeping rather than governance. Proof of removal is the best maturity signal.
Q: Should organisations prioritise runtime authorization over traditional access reviews for agents?
A: Yes, when the actor can request, use and release access faster than a review cycle can observe it. Traditional access reviews still matter for governance, but they cannot be the primary control for autonomous execution that changes state within a single task.
Technical breakdown
Why point-in-time certification misses SaaS drift
Access reviews and access certifications were designed to prove that someone checked whether access was still appropriate on a specific date. In SaaS environments, that model breaks because permissions change after the attestation is signed. Tokens remain active, employees change roles, integrations expand scope, and service accounts accumulate access without waiting for the next review. The control is evidentiary, but it is not continuous. That distinction matters because auditors need proof of review, while attackers and operational drift exploit the days and weeks between reviews.
Practical implication: Treat certification as audit evidence, not as the control that enforces access between review dates.
Why SaaS and machine identities widen the access window
The article ties the governance gap to the growth of SaaS applications, connected APIs, service accounts, and AI agents. These identities do not align to HR-driven change events and often acquire access through integration work, sprint-driven provisioning, or delegated automation. As a result, the estate changes faster than quarterly or even weekly review cadences can track. The risk is not just stale human access. It is also machine and agent access that can expand invisibly and remain valid until some later certification cycle notices it, if it does at all.
Practical implication: Inventory non-human access paths alongside human entitlements so review cadence reflects the identities actually holding privilege.
How runtime authorization changes the enforcement model
Runtime authorization evaluates access at request time rather than relying on a standing grant created earlier. In practical terms, that means the policy engine checks whether the identity, context, and business condition still justify access every time a request is made. This is the opposite of snapshot governance. It moves control from periodic attestation to current decisioning, which is why Zero Standing Privilege is relevant here. The article uses that logic to show why stale tokens and over-scoped permissions remain effective until access is enforced continuously.
Practical implication: Shift critical SaaS access decisions to policy checks that run when the request happens, not only when the review happens.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Snapshot certification is a governance proof, not a protection mechanism: Access reviews show that access was judged at one moment in time, but they do not govern the hours and days after the attestation. That is a structural limit, not an implementation error. The implication is that certification must be treated as evidence for audit, while enforcement has to happen elsewhere.
The blind spot is the period between access changes and the next review: SaaS estates accumulate risk through contractor offboarding delays, role changes, new integrations, and unreviewed service account scope. Those changes happen on operational timelines, while reviews run on governance calendars. Practitioners should stop assuming the review cadence itself meaningfully constrains exposure.
Access governance for SaaS now depends on runtime decisioning: When tokens, integrations, and agent permissions can change daily, governance has to move from periodic approval to policy enforcement at the moment of use. That does not eliminate review, but it changes the control plane that actually limits blast radius.
Identity lifecycle is now part of SaaS authorization, not a separate admin task: Offboarding, mover events, and integration changes all alter what access should exist between certifications. The old separation between lifecycle administration and authorization oversight no longer holds in a constantly changing SaaS environment. Practitioners need one operating model that accounts for both.
Continuous authorization is becoming the practical standard for high-change environments: Quarterly or monthly review cycles still matter for auditability, but they no longer define effective control in dynamic SaaS estates. The organisations that treat runtime policy as the primary enforcement layer will be better placed to limit dormant access and unapproved scope growth.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
What this signals
SaaS access governance is shifting from periodic approval to continuous enforcement: Review cycles still matter for evidence and accountability, but they no longer close the exposure window created by daily entitlement change. IAM and IGA teams should expect runtime policy to carry more of the enforcement burden as SaaS estates keep expanding.
Access lifecycle and authorization can no longer be managed as separate workstreams: Offboarding, role changes, integration approvals, and agent onboarding all alter the access picture between reviews. Programmes that keep lifecycle hygiene and authorization control in different queues will keep discovering stale access after the fact.
For practitioners
- Audit standing SaaS access between certification cycles Identify where access can change after approval, especially for contractors, movers, integrations, service accounts, and AI agents. Compare the review date to the actual date access was last used, expanded, or revoked.
- Map non-human identities into the review population Include tokens, service accounts, API-linked access, and agent permissions in the same governance inventory as human users so entitlement drift does not sit outside access review scope.
- Move critical SaaS access to runtime policy enforcement Use policy checks at request time for high-risk applications so access is evaluated against current conditions rather than preserved as a standing grant until the next review.
- Separate audit evidence from enforcement Keep access certification as a compliance artifact, but do not rely on it to limit exposure. Use it to verify governance decisions while another control removes stale access in between reviews.
Key takeaways
- Quarterly certification can prove that access was checked, but it cannot govern permissions that change after the check.
- The risk in SaaS is not limited to human users. Contractors, service accounts, integrations, and AI agents can all widen the access window between review cycles.
- Runtime authorization is the control pattern that changes the outcome because it evaluates access when the request happens, not only when the review is run.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on SaaS identities retaining more access than current business need justifies. |
| NHI-01 — Improper Offboarding | Contractor access lingering after project end is a direct offboarding failure. | |
| Recommendation — Reduce standing SaaS entitlements and recertify high-risk access against current business need. Tie SaaS deprovisioning to offboarding events so access ends when the relationship ends. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Tokens and other authenticators are central to the access drift described in the article. |
| Recommendation — Enforce authenticator lifecycle controls so stale SaaS tokens are revoked promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether entitlements stay valid between review cycles. |
| Recommendation — Continuously govern entitlements so access remains aligned to current authorization decisions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Persistent SaaS tokens and over-scoped access enable credential abuse and movement across connected apps. |
| Recommendation — Prioritise detection and containment for long-lived SaaS credentials that can support credential access and lateral movement. | ||
Key terms
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
- 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.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- How runtime authorization is positioned alongside existing identity provider and IGA tooling
- The control flow for enforcing policy at request time across SaaS applications and APIs
- The distinction between access review evidence and live enforcement in a dynamic estate
- How Zero Standing Privilege changes the access model for contractors and AI agents
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.
Published by the NHIMG editorial team on August 14, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org