Orphaned SaaS applications keep their delegated permissions long after the business need ends, which means users, vendors, and projects can change while access remains intact. That creates standing exposure that is invisible to normal account reviews and often survives password resets, MFA changes, and employee departures.
When OAuth scopes are left unchecked, what actually keeps accumulating?
Scopes are not just a login detail, they define the delegated power an app keeps until someone deliberately removes it. If no one revisits them, access quietly accumulates across SaaS apps, connected services, and vendor tooling, even after the original project, user, or business purpose has changed. That creates a standing permissions layer that is easy to miss in ordinary account hygiene reviews.
That is why OAuth scope review is really a lifecycle control, not a one-time setup task. The issue is not only who can sign in, but what an approved app can continue to do on behalf of the user or tenant long after the original justification has expired.
Why stale scopes survive routine identity cleanup
OAuth grants often outlive passwords, MFA resets, and even employee departures because the delegated authorization can sit outside the normal account-centric revocation path. A user account can be locked down while the app token or consented grant still remains valid, which leaves a separate access path intact.
That is the practical failure mode: teams review human accounts and assume the associated app access has been cleaned up with them. In reality, the grant can persist independently, especially in SaaS-to-SaaS integrations where the app was installed once and then forgotten.
OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful here because it explains scopes, grants, and token behavior in the authorization model that makes this persistence possible.
What breaks operationally and where the blast radius shows up
Once scopes are not reviewed and revoked over time, the organisation loses visibility into who can still act through delegated access. That can affect mailbox access, file access, API actions, and other SaaS permissions that remain active even when the business relationship has ended.
The operational break is usually not immediate outage, it is control drift. Access review reports can look clean while the real exposure sits in old grants, which means stale integrations can continue to read data, modify records, or trigger workflows without any fresh approval.
SaaS-to-SaaS and OAuth App Governance Guide is directly relevant because it covers consent, scopes, token risk, and revocation runbooks for connected applications.
Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs is also relevant because stale delegated access behaves like an unmanaged lifecycle problem: provisioning happened, but offboarding never did.
Why this becomes a security problem instead of just an admin problem
Unrevoked scopes create standing exposure that an attacker, rogue vendor, or compromised integration can reuse without needing to break the main user account again. If a refresh token, consent grant, or app authorization remains valid, the path back in is already there.
That is why scope hygiene matters for third-party risk and not just account cleanliness. A forgotten consent can preserve access after a vendor change, after a project ends, or after an employee leaves, and the resulting access can be hard to distinguish from normal application traffic.
RFC 6749: The OAuth 2.0 Authorization Framework is the core external reference for how delegated authorization and grants work, including the mechanics that make scopes persistent until they are revoked.
OWASP Non-Human Identity Top 10 helps frame the control problem because overprivilege, long-lived secrets, and lifecycle failures are common ways this access becomes difficult to see and easy to abuse.
Risk and Threat Considerations
Stale OAuth scopes are risky because they preserve a live trust relationship after the original business need is gone. That means a compromised app, a misused vendor integration, or a former employee’s consented access can continue to reach data and services even when the primary account has been secured.
Failure mechanism: The organisation revokes the user, but not the delegated grant, so the app keeps its effective permissions through existing tokens or consent.
Impact: Attackers or obsolete integrations can retain silent access to mail, files, APIs, or workflows, increasing blast radius and delaying detection.
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 addresses the attack surface, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth grants and tokens need lifecycle control and revocation. |
| AC-2 — Account Management | Stale app access persists when grants are not tied to ownership and offboarding. | |
| AC-6 — Least Privilege | Unreviewed scopes expand delegated access beyond current business need. | |
| Recommendation — Review and revoke OAuth credentials on a defined lifecycle. Tie app consent to account and owner lifecycle events. Limit granted scopes to the minimum required permissions. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OAuth scope and grant handling is central to this access-control failure. |
| Recommendation — Verify scope handling, consent, and revocation paths for OAuth integrations. | ||
| CIS Controls v8 | CIS-5 — Account Management | Connected app grants require active inventory and timely removal. |
| Recommendation — Maintain and review application access inventories, then remove obsolete grants. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Revoked scopes are part of access control governance for connected apps. |
| A.8.5 — Secure authentication | OAuth tokens and consents are authentication material that must not linger. | |
| Recommendation — Enforce periodic review and removal of unnecessary delegated access. Use secure token lifecycle controls and revoke unused authorizations. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Orphaned OAuth grants are a form of offboarding failure for non-human access. |
| NHI-07 — Long-Lived Secrets | Stale OAuth access often persists through long-lived tokens and grants. | |
| Recommendation — Revoke app grants when their business owner or purpose ends. Shorten token lifetime and remove durable access paths where possible. | ||
Practitioner Guidance
What to verify: Review consented apps, granted scopes, refresh-token behavior, and tenant-level app permissions as a separate inventory from human accounts. If the app can still act after the user leaves, the grant is still live.
Decision rule: If an OAuth app no longer has an active business owner, current purpose, or documented data need, revoke the grant rather than leaving it to the next account review cycle.
What good looks like: Every connected app has an owner, an expiry or review date, and a revocation path that is tested before the access becomes stale.
Practitioner takeaway: Treat OAuth scopes as delegated privilege with a shelf life, because the real failure is not forgotten login, it is forgotten authority.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org