Who is accountable when identity-based attacks move through SaaS integrations?

Why This Matters for Security Teams

Identity-based attacks rarely stay confined to one system once SaaS integrations are in place. A connected app, OAuth grant, API token, or service account can become a pivot point into email, file storage, ticketing, CRM, and automation platforms. That makes accountability an operational question, not just a legal one: the organisation that approved the access path must also own monitoring, revocation, and escalation when abuse appears.

This is why NHI governance matters across SaaS ecosystems, not only inside a single identity provider. NHIMG’s Ultimate Guide to NHIs shows that 92% of organisations expose NHIs to third parties, and that kind of exposure turns delegated access into a supply-chain risk. External guidance from CISA cyber threat advisories reinforces the same operational reality: attackers often abuse legitimate access paths rather than exploit obvious perimeter flaws.

In practice, many security teams encounter ownership gaps only after an OAuth token, API key, or connected app has already been used to move laterally through trusted SaaS tools.

How It Works in Practice

When a SaaS integration is granted, the access relationship becomes part of the organisation’s internal identity model even if the asset is owned by a third party. That means accountability should be assigned across three layers: the security team that sets policy and detection thresholds, the IAM or platform team that controls consent and revocation, and the application owner who understands delegated scope and business impact. If one of those layers is missing, no one can answer basic questions quickly enough: Who approved the integration? What data can it reach? Who revokes it if the vendor is compromised?

Practically, teams should maintain an inventory of all non-human access paths, including OAuth grants, refresh tokens, service principals, PATs, and API keys. The inventory should record the business owner, technical owner, scope, expiry or rotation date, and the alert route for suspicious activity. This is consistent with the direction of NHI guidance in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks, where visibility and lifecycle control are treated as core controls rather than optional hygiene.

• Define delegated scope at approval time, not after the integration is live.
• Map every integration to a named revocation owner and backup owner.
• Alert on unusual consent changes, token refresh spikes, inbox rule creation, and cross-app data export.
• Review whether the integration can be limited by tenant, workspace, or data class.

For attack-path analysis, practitioners should align telemetry with established frameworks such as the MITRE ATT&CK Enterprise Matrix so token abuse, persistence, and lateral movement are not treated as isolated events. These controls tend to break down in large SaaS estates with shadow IT and unmanaged app registrations because ownership and telemetry are fragmented across multiple administrative domains.

Common Variations and Edge Cases

Tighter integration governance often increases approval overhead, so organisations need to balance speed against the risk of uncontrolled delegated access. The tradeoff is especially sharp in environments that rely heavily on automation, external consultants, or marketplace apps, where broad scopes are often granted for convenience.

There is no universal standard for joint accountability language yet, but current guidance suggests that the organisation consuming the integration remains responsible for risk acceptance even if the vendor or cloud provider owns the underlying platform. That distinction matters when an attacker abuses a trusted app to exfiltrate mail, files, or CRM records. NHIMG’s 52 NHI Breaches Analysis and the Salesloft OAuth token breach both illustrate how delegated trust becomes the attacker’s shortest route when monitoring and offboarding are unclear.

Edge cases appear when integrations are brokered through resellers, managed service providers, or nested SaaS apps. In those cases, contract language may shift operational tasks, but it does not remove the need for internal ownership of scope, logging, and response. Organisations should also treat high-risk integrations differently from low-risk productivity tools, since not all delegated access deserves the same review cadence. In practice, accountability fails fastest when a connected app is assumed to be “vendor-owned” after it has already been granted broad internal reach.

Related resources from NHI Mgmt Group

• Who is accountable when identity-based attacks move through trusted access paths?
• How should security teams detect identity-based attacks that move through email and login paths?
• Who is accountable for stopping identity-based attacks when IAM and PAM are involved?
• Who is accountable when an exposed gateway leaks identity-relevant data?