The accountable owners are the teams that approved the integration, defined the credential lifecycle, and operated the monitoring and revocation process. In practice, this spans IAM, platform engineering, and application owners. If a credential can stay alive without a clear owner, accountability has already broken down.
Why This Matters for Security Teams
A dormant oauth token is not just a stale credential. It is an active trust path that can outlive the team that approved it, the application that created it, and the employee who first installed it. When that token is abused to steal repositories, the failure is usually not a single technical mistake but a breakdown in ownership, review cadence, and revocation authority. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control and credential management have to be operationalized, not assumed.
The recurring pattern is visible in incidents such as the Salesloft OAuth token breach and the Dropbox Sign breach, where third-party integrations and long-lived authorizations created an attack surface that did not behave like a normal user account. NHIMG research on Guide to the Secret Sprawl Challenge shows why this matters at scale: 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection without revocation is not a containment strategy.
Security teams often discover these gaps only after repositories, source code, or automation pipelines have already been used for lateral access, rather than through a deliberate credential ownership model.
How It Works in Practice
Accountability for abused OAuth tokens should be assigned across the full lifecycle of the integration, not just the incident response team. The approving team owns the business justification, the platform or IAM team owns the control plane that issues and tracks the token, and the application owner owns the scope, use case, and retirement criteria. That division matters because OAuth tokens are often granted once and then quietly persist across app updates, vendor changes, and personnel turnover. NIST guidance on access control, auditability, and revocation supports this shared-responsibility model, but current guidance suggests the operating model must be explicit or it will fail in practice.
In a mature process, the token is tied to a named system owner, a reviewed use case, an expiry date, and a documented revocation path. Monitoring should focus on token age, unusual repository access, off-hours use, and API calls that do not match the approved integration pattern. Where possible, shorten token lifetime and move toward just-in-time authorization, because long-lived credentials are hard to justify for automated workflows. NHIMG’s coverage of the Klue OAuth Supply Chain Breach and Microsoft OAuth Breach shows how one compromised integration can scale into broad repository exposure when revocation is slow or unclear.
- Bind each OAuth app to a named business owner and a technical owner.
- Track token issuance, scope, last use, and expiry in inventory.
- Enforce review and re-approval for sensitive scopes such as repo read, write, or admin access.
- Automate revocation when the integration is inactive, over-scoped, or unowned.
- Alert on repository access that falls outside the expected API pattern.
These controls tend to break down in large developer ecosystems where integrations are created by teams outside central IAM, because no one function has complete visibility into both approval and operational use.
Common Variations and Edge Cases
Tighter token governance often increases delivery overhead, requiring organisations to balance developer velocity against the cost of missed revocation. That tradeoff becomes sharper when the token is owned by a third-party app, a contractor, or a departed employee, because the operational team may see only the symptom while another team still believes it owns the credential. Best practice is evolving, but there is no universal standard for this yet: some organisations treat dormant OAuth tokens as application risk, while others classify them as identity risk or supply chain risk depending on where the token was issued.
The edge cases are usually the hardest. A token may be dormant in one environment but still permitted through a backup path, a stale webhook, or a CI/CD job that no one has retired. In shared platforms, several product teams may consume the same integration, which makes accountability diffuse unless ownership is formally documented. NHIMG’s The State of Secrets Sprawl 2026 reinforces the broader lesson: if secrets remain valid long after their original purpose, security has already shifted from prevention to cleanup. Current guidance suggests the safest rule is simple: if no team can revoke it immediately, no team truly owns it.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF 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 secret lifecycle failures and stale token risk. |
| NIST CSF 2.0 | PR.AC-1 | Access control requires known identities and accountable authorization paths. |
| NIST AI RMF | GOVERN | Governance is needed when automated systems can act beyond initial intent. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust requires continuous verification of each token use. |
| CSA MAESTRO | Agent and workflow governance applies to autonomous token-using integrations. |
Define lifecycle ownership, policy checks, and revocation triggers for each integration.
