OAuth archaeology is the process of tracing every active OAuth grant, delegated permission, and dormant token back through ownership changes and integration history. It matters because access can survive mergers, rebrands, and product pivots even when the original business justification no longer exists.
Expanded Definition
OAuth archaeology is the disciplined review of delegated access history: who approved it, which app received it, what scopes were granted, and whether the grant still matches a current business need. In practice, it extends beyond a simple app inventory because OAuth access often outlives the team, vendor, or product decision that created it.
The term is used when organisations need to reconstruct trust decisions across time, especially after mergers, rebrands, employee turnover, or SaaS sprawl. It is not the same as general access review: the focus is on delegated consent, dormant tokens, and third-party app relationships that may have been forgotten but still remain active. That boundary matters because an app can look legitimate in current admin consoles while its original approval context has vanished.
Where the subject is OAuth grants rather than identity governance in general, the practical question is not only “who has access now?” but “why was this access ever granted, and should it still exist?”
Examples and Use Cases
OAuth archaeology usually appears when an organisation is trying to reconcile current access with old operational decisions. The work is investigative, but it is driven by a concrete need to find stale trust relationships before they become invisible attack paths.
- Reviewing a CRM-connected app that was approved by a departed employee, then retained through an admin succession chain.
- Tracing a marketing automation integration back to an acquisition, where the original vendor relationship no longer exists but the grant still does.
- Validating whether a dormant refresh token still supports background mailbox, file, or workspace access even though the app is no longer used.
- Comparing current OAuth scopes against the business purpose recorded at approval time to identify scope creep after product changes.
- Rebuilding the history of third-party app consent after tenant consolidation, where duplicate or legacy grants were carried forward during migration.
In environments with heavy SaaS integration, the tradeoff is speed versus certainty: a quick inventory can show what is active, but archaeology is needed to explain whether the access is still justified.
Security Implications
When OAuth archaeology is skipped, dormant but valid grants can preserve access long after ownership has changed. That creates an exposure pattern where the organisation believes an integration has been retired, while tokens, scopes, or delegated consent still allow data access, background automation, or lateral use of trust relationships.
A common failure mode is incomplete visibility into third-party OAuth apps. NHIMG research finds that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes it difficult to distinguish required integrations from inherited exposure. The operational symptom is usually not a loud alert; it is unexplained retained access, outdated consent records, or applications that still function despite no clear owner.
Astrix Security & CSA report that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
The consequence is broader than account hygiene. Unreviewed grants can preserve access through reorganisations, vendor exits, and product pivots, expanding blast radius if a token, connected app, or delegated permission is later abused.
Domain and Governance Relevance
In NHI governance, OAuth archaeology is a lifecycle control problem, not just an access review task. OAuth grants often function as machine-to-machine or app-to-app identities, so ownership, scope, and revocation must be understood across the full history of the relationship, not only at the moment of issuance.
This matters because non-human access is frequently inherited rather than consciously re-approved. If the original approver disappears, the vendor changes hands, or the integration purpose shifts, the organisation may still have an active delegated trust path with no clear current sponsor. That weakens accountability, complicates offboarding, and makes revocation decisions harder to justify or execute.
For NHI programs, the term highlights a governance reality: access reviews must account for provenance, not just current entitlements. Without that historical traceability, dormant OAuth grants can survive standard cleanup routines and remain outside normal identity ownership processes.
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 CIS Controls v8 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-02 — Secrets and Credential Management | OAuth grants and tokens are non-human credentials that must be inventoried and governed. |
| NHI-04 — Lifecycle Management | The term centers on tracing grants through ownership changes and integration history. | |
| NHI-06 — Visibility and Monitoring | Archaeology depends on discovering dormant delegated access and stale third-party app relationships. | |
| Recommendation — Track OAuth tokens and grants as NHI credentials and revoke any that no longer have a clear owner. Maintain ownership lineage for every OAuth consent and retire grants when the business use ends. Continuously enumerate OAuth apps and alert on dormant or newly orphaned delegated access. | ||
| CIS Controls v8 | 6.3 — Data Recovery | Stale OAuth access can preserve access paths that recovery and restoration processes must account for. |
| 5.3 — Account Management | OAuth archaeology is a form of lifecycle account and entitlement review for delegated access. | |
| Recommendation — Include legacy OAuth grants in recovery inventories so restored systems do not reintroduce forgotten access. Review delegated OAuth access on a schedule and remove grants that no longer match a current owner. | ||
| NIST CSF 2.0 | GV.1 — Organizational Context | The term requires knowing which integrations still matter after organisational changes. |
| Recommendation — Define ownership and business context for each OAuth integration so legacy access can be judged correctly. | ||
| MITRE ATT&CK | T1528 — Steal Application Access Token | Dormant OAuth tokens are a recognised target for token theft and reuse. |
| Recommendation — Hunt for abuse of stored OAuth tokens and investigate unexpected application access patterns. | ||
