Disable the app first, then revoke refresh tokens and remove delegated access so the attacker cannot keep renewing sessions. After that, review sign in logs and audit logs for non interactive activity, unfamiliar IPs, and the permissions that were granted. Because access tokens cannot be revoked immediately, continue monitoring for at least an hour after containment.
Containment after a suspected OAuth app incident
In an Azure incident, the immediate goal is to stop the app from keeping its foothold while preserving enough evidence to understand what it did. Disabling the app first cuts off the most obvious path for continued use, but the exposure often persists through tokens and delegated consent until those are explicitly removed and the activity is reviewed.
That is why investigators usually treat the OAuth app itself, its token grants, and the permissions it received as one containment problem, not three separate ones. A malicious or over-permissioned app can continue to act until the delegated access is revoked, and stolen refresh tokens can keep generating new access even after the app looks inactive.
- Ultimate Guide to NHIs — What are Non-Human Identities is a useful reference for understanding why app credentials, tokens, and delegated access must be handled as identity material.
- Salesloft OAuth token breach shows how stolen OAuth tokens can be used to maintain access after the initial compromise path is gone.
- Microsoft OAuth Breach is a relevant example of OAuth app abuse creating persistent cloud access.
What to verify in logs and permissions
After containment, the next task is to establish scope. Sign-in logs and audit logs help distinguish legitimate application use from attacker-driven activity, especially when the malicious actor used non-interactive flows, unfamiliar source IPs, or consented to broader permissions than the business intended. That review should include what was granted, when it was granted, and which principals or resources the app touched.
Because access tokens cannot be revoked instantly everywhere, teams should assume a short residual-use window and keep watching for continued activity after the app is disabled. The practical question is not only whether the app was used, but whether any other session, token, or delegated path can still reach the same resources.
- 52 NHI Breaches Analysis helps illustrate the kinds of identity and token abuse patterns teams should look for during scoping.
- Ultimate Guide to NHIs covers lifecycle, visibility, rotation, and offboarding controls that are directly relevant to delegated access cleanup.
- Anthropic’s first AI-orchestrated cyber espionage campaign report is useful for understanding how stolen credentials and delegated access can support rapid follow-on abuse.
Risk and Threat Considerations
The main risk is persistence, an OAuth app can remain useful to an attacker even after the obvious compromise is discovered if refresh tokens, delegated consent, or cached session state are still valid. That creates a window for continued mailbox, file, or API access and can mask broader privilege abuse.
Failure mechanism: The attacker uses the app’s existing grants or refresh capability to re-enter the tenant, then pivots through permitted APIs or resources before the organization finishes containment.
Impact: Continued unauthorized access can extend dwell time, increase data exposure, and make the incident look smaller than it really is until logs are correlated across the affected period.
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, CIS Controls v8 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-01 — Secrets and Credential Management | OAuth tokens and delegated grants are identity material that can sustain access. |
| NHI-03 — Access Governance and Least Privilege | OAuth app permissions determine what the compromised app can access and do. | |
| NHI-06 — Detection and Monitoring | Log review is needed to spot non-interactive abuse, unfamiliar IPs, and continued use. | |
| Recommendation — Revoke exposed tokens, rotate dependent secrets, and remove stale delegated grants. Review consented scopes and reduce permissions to the minimum required. Correlate sign-in and audit logs for anomalous app activity after containment. | ||
| NIST CSF 2.0 | DE.CM-01 — Continuous Monitoring | The incident requires ongoing monitoring for residual token use after containment. |
| RS.MI-01 — Mitigation of Incidents | Disabling the app and revoking access are direct incident mitigation actions. | |
| PR.AC-4 — Access Permissions are Managed | Delegated permissions and consented scopes must be reviewed and reduced. | |
| Recommendation — Monitor for continued activity until the token lifecycle window fully closes. Contain the app first, then revoke remaining access paths and session renewal. Audit and trim granted app permissions to reduce blast radius. | ||
| CIS Controls v8 | 6.3 — User Access Revocation | Compromised app access must be revoked promptly to stop ongoing abuse. |
| 8.2 — Log Audit | Investigators need sign-in and audit logs to scope the OAuth incident. | |
| 5.3 — Data Recovery | Post-containment validation should confirm no further unauthorized access persists. | |
| Recommendation — Remove the app's granted access and invalidate remaining access paths. Review authentication and audit logs for suspicious non-interactive activity. Validate that the affected services return to a trusted state after containment. | ||
| NIST Zero Trust (SP 800-207) | 5 — Identity-driven policy enforcement | The incident is governed by whether the app can still be authorized to act. |
| Recommendation — Re-evaluate authorization policy so the compromised app cannot be trusted by default. | ||
Practitioner Guidance
What to verify: Confirm that the app is truly disabled, that delegated grants were removed, and that any consented permissions match what the business expected. If the app had broad scopes, treat the incident as a tenant access review, not just an app takedown.
Decision rule: If you see active use after containment, assume at least one token path is still live and prioritize revocation plus scope reduction before chasing attribution details.
Practitioner takeaway: The containment standard is not “the app is off,” it is “the app can no longer authenticate, renew, or act on granted access anywhere that matters.”
Related resources from NHI Mgmt Group
- How should security teams respond when app credentials used for M365 access may have been exposed in an Azure-linked incident?
- What should teams do when a user is found in a breach after account creation?
- How should security teams automate credential-related incident response across password management and orchestration tools?
- Why are NHIs a critical concern for security teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
