Look for apps that request more scopes than their function requires, grants that were never revisited, and applications that suddenly gain broader permissions. A healthy programme correlates scope, usage, and revocation history rather than relying on one-time approval checks. If an app still holds access after its business purpose has faded, policy drift has already begun.
Why This Matters for Security Teams
OAuth drift is rarely a single bad approval. It is the slow mismatch between what an application was meant to do, what it still can do, and what it is actually doing today. That matters because OAuth grants are often treated as “set and forget” access, even though the business process, integration owner, and data exposure can change underneath them. The result is overbroad access that persists long after the original need has expired. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which is why OAuth review cannot be a one-time checkbox. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the broader governance context.
The practical risk is not only excess scope. It is also the absence of a reliable signal that an app’s permissions have become stale, inherited, or silently broadened through admin action. In practice, many security teams discover OAuth drift only after a third-party integration starts moving data in ways nobody expected, rather than through intentional access governance.
How It Works in Practice
Teams usually detect OAuth drift by correlating three things: granted scopes, observed usage, and revocation history. If an app has write access but only ever reads a narrow dataset, that is a policy signal. If an integration was approved for a short business project and never revalidated, that is another. If a vendor app suddenly requests broader scopes after a product update, the change should be treated as a governance event, not a routine technical adjustment. The Salesloft OAuth token breach is a useful reminder that token abuse can turn stale trust into real data exposure, while the Dropbox Sign breach shows how integration sprawl can widen the blast radius.
A workable programme normally includes:
- an inventory of every OAuth app, owner, tenant, and granted scope
- usage telemetry that shows which scopes are actually exercised
- periodic reapproval for high-risk or third-party apps
- automatic revocation or step-up review when scope changes occur
- controls that bind grants to business purpose, not just user consent
Current guidance from the NIST Cybersecurity Framework 2.0 supports continuous monitoring and access review, which is the right model here. The NHI perspective from Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is simple: if an app’s access cannot be tied to a current owner, current purpose, and current usage, the grant is already drifting. These controls tend to break down in large SaaS estates with many third-party integrations because identity sprawl outpaces manual review.
Common Variations and Edge Cases
Tighter OAuth control often increases operational overhead, requiring organisations to balance faster integrations against stronger review and revocation discipline. There is no universal standard for every environment, so the right threshold depends on data sensitivity, vendor criticality, and whether the app is internal or externally supplied. A low-risk reporting app may justify broader tolerance than a production automation app with write access to customer records.
Edge cases usually appear when scopes are bundled, when an app uses delegated access on behalf of many users, or when service accounts and OAuth tokens overlap in the same workflow. In those cases, scope alone is not enough. Teams should also watch for unusual grant timing, dormant tokens that remain valid, and permissions that are technically approved but no longer necessary for the workload. The Top 10 NHI Issues is a useful reference for these recurring failure modes, and the 52 NHI Breaches Analysis shows how stale access often becomes visible only after compromise. At the governance level, that aligns with OWASP Non-Human Identity Top 10 and the accountability focus in NIST Cybersecurity Framework 2.0.
Where this guidance breaks down most often is in unmanaged third-party ecosystems, because security teams may not see every delegated grant, every nested permission change, or every token refresh path in real time.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers credential lifecycle and stale access, central to OAuth drift. |
| NIST CSF 2.0 | PR.AC-4 | Focuses on access permissions and least privilege for ongoing governance. |
| NIST Zero Trust (SP 800-207) | Supports continuous verification rather than trust based on one-time approval. |
Review OAuth grants on a schedule and revoke any scope that no longer matches current business need.
Related resources from NHI Mgmt Group
- How can security teams tell whether AI agent access is drifting out of scope?
- How do security teams know whether vendor access is actually governed?
- How do security teams know if third-party app access is out of control?
- How should security teams govern third-party access when OAuth is abstracted away by a broker?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
