Who should revoke a compromised SaaS integration during an incident?

Why This Matters for Security Teams

A compromised saas integration is not a routine access-review issue. It is an active incident path where stolen tokens, overbroad OAuth scopes, or an exposed service account can be used to move laterally inside business systems before human review catches up. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s 2024 ESG report on managing non-human identities both point to the same operational reality: identity compromise is common, and delay is expensive. The report notes that 72% of organisations have experienced or suspect a breach of non-human identities.

The main mistake is assuming revocation belongs to a single queue, such as IAM, after tickets are triaged. During an incident, authority must already be assigned so the business owner can accept service impact, the identity team can disable tokens and keys, and security operations can remove access paths without waiting for a lengthy approval chain. In practice, many security teams encounter the need for emergency revocation only after the attacker has already used the integration to pull data or expand access, rather than through intentional incident design.

How It Works in Practice

The most effective model is pre-delegated incident authority. The business owner owns the service risk, the identity team executes technical revocation, and security operations coordinates containment and evidence preservation. That division of labour matters because SaaS integrations often span multiple control planes: the app console, the identity provider, API tokens, refresh tokens, service accounts, and connected workflows.

Current best practice is to define a short incident playbook that names who can do what, in what order, and with which approval thresholds. For example:

• Disable the integration or connected app at the SaaS admin layer.
• Revoke refresh tokens, API keys, certificates, and delegated OAuth grants.
• Remove risky scopes and break cross-tenant trust links where possible.
• Preserve logs, token metadata, and scope history for investigation.
• Rotate any downstream secrets that may have been exposed through the integration.

This is aligned with the practical guidance emerging in NHI Lifecycle Management Guide and the Ultimate Guide to NHIs on static vs dynamic secrets. If a compromised integration is still using long-lived credentials, revocation must happen immediately because TTL is no longer a theoretical control. For higher-risk SaaS environments, organisations are increasingly moving to just-in-time, short-lived credentials and workload identity so that the revocation blast radius is smaller and the tokens age out quickly. These controls tend to break down when the integration is embedded in a third-party automation chain that does not expose token inventory or supports only partial revocation.

Common Variations and Edge Cases

Tighter revocation authority often increases operational disruption, requiring organisations to balance containment speed against business continuity. That tradeoff becomes sharper when the integration supports payroll, customer support, or production automation, where an immediate disable can interrupt critical workflows.

There is no universal standard for this yet, but current guidance suggests three common edge cases. First, some SaaS platforms let the app owner revoke access while the identity team must separately invalidate tokens elsewhere. Second, federated integrations may require action in both the SaaS tenant and the upstream identity provider. Third, very mature environments may allow security operations to trigger emergency disablement directly, with business owner notification occurring in parallel rather than beforehand.

NHIMG’s Salesloft OAuth token breach is a reminder that token compromise can look like normal integration traffic until it is too late. The practical answer is to pre-assign revocation authority, test it, and document fallback paths for off-hours incidents. Best practice is evolving, but the core requirement is stable: the people who can stop the blast radius must be able to act without waiting for a committee.

Related resources from NHI Mgmt Group

• Why is NHI ownership attribution important for incident response?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why can a single SaaS app create such a large blast radius?
• What actions should I take if my OAuth tokens are compromised?