Accountability should sit with the SaaS customer and the service owner who approves integrations, because they decide what data, scopes, and permissions each connection gets. Security, identity, and platform teams should share operational control, but one business owner must be accountable for risk acceptance, review, and removal. NHI governance should cover tokens, service accounts, and delegated access across the full integration lifecycle.
Who decides accountability in SaaS-to-SaaS integrations?
The accountable party should be the business or service owner that approves the integration, because that owner decides whether the connection is worth the risk and what data, scopes, and permissions it receives. Security, identity, and platform teams can operationalise controls, but accountability must stay with the person who can accept, constrain, or remove the relationship.
That distinction matters because SaaS integrations are not just technical connections, they are delegated access paths. A workflow owner may want convenience, but the accountable owner has to balance business value against the blast radius created by overbroad OAuth consent, shared tokens, or vendor-managed access.
For teams that need a practical governance model, the SaaS integration lifecycle should be treated as a controlled access relationship, not a one-time setup task. The SaaS-to-SaaS and OAuth App Governance Guide is useful here because it centres consent, scopes, token risk, and revocation decisions across the full lifecycle.
Why shared control still needs a single accountable owner
Shared operational control is normal, but shared accountability usually creates gaps. Security can set policy, identity teams can govern token and scope hygiene, and platform teams can integrate tooling, yet none of those groups should become the default risk owner for a business connection they did not request.
Accountability should follow decision rights. If a team can approve the integration, choose the scopes, keep it active, or remove it, that team needs to own the resulting exposure. That is the clearest way to avoid orphaned integrations, stale OAuth grants, and silent expansion of access over time.
This is especially important when the integration is backed by long-lived credentials or delegated access that can survive staff changes and workflow drift. Treat the approving owner as responsible for review cadence, exception handling, and the final call on decommissioning when the business need ends.
What breaks when nobody owns the integration risk?
Unclear ownership usually fails in predictable ways: excessive scopes remain approved, tokens are left active after the business need changes, and no one notices when a third-party app gains broader access than originally intended. In practice, the most common failure is not a missing control, but a missing decision-maker.
That failure mode becomes much more dangerous when the integration can reach customer data, CRM systems, code repositories, support tooling, or admin workflows. Once a connected app is trusted, compromise of that app, its token, or its vendor environment can become a supply chain event rather than a local misconfiguration.
A number of recent SaaS integration incidents have shown how quickly delegated trust can become enterprise exposure. For example, the Klue OAuth Supply Chain Breach illustrates the risk of compromised integration tokens, while the BeyondTrust breach 2024 shows how a stolen API key can turn a third-party service into a privileged access path.
Risk and Threat Considerations
SaaS-to-SaaS security is exposed when integration ownership is vague, because attackers often target the least visible trust relationship rather than the primary application. A delegated token, shared admin credential, or overbroad consent grant can provide durable access that is harder to notice than a normal user account compromise.
Failure mechanism: Weak accountability lets risky integrations persist after their original business purpose changes, which increases the chance of overprivilege, token abuse, and delayed revocation if a vendor, app, or maintainer is compromised.
Impact: The result can be unauthorized data access, lateral movement across connected SaaS platforms, and a much larger incident scope than the original integration seemed to justify.
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 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party SaaS integrations create external trust and token exposure risk. |
| NHI-05 — Overprivileged NHI | The question centers on who owns excessive scopes and permissions in SaaS connections. | |
| NHI-07 — Long-Lived Secrets | SaaS-to-SaaS connections often rely on tokens that outlive their original approval. | |
| Recommendation — Assess connected apps for vendor compromise and restrict their access to the minimum needed. Review granted scopes and remove privileges that exceed the integration's business purpose. Shorten secret lifetimes and rotate credentials before they become stale trust artifacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Integration ownership and removal depend on disciplined account and access administration. |
| Recommendation — Assign accountable owners for every integration account and revoke unused access promptly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SaaS integrations depend on credential lifecycle, rotation, and revocation decisions. |
| Recommendation — Manage token issuance, storage, rotation, and revocation as controlled authenticator lifecycle events. | ||
Practitioner Guidance
What to verify: Confirm that every approved integration has one named business owner, one technical operator, and a recorded reason for the data and scope granted. If no owner can explain why the connection still exists, that is a removal candidate, not a documentation issue.
Decision rule: If the integration can read, write, sync, or automate production data, treat it as a privileged access relationship and require review on a fixed cadence, not only during onboarding.
Common mistake: Teams often assign the control work to security while leaving business approval implicit. That reverses the accountability model, because security can advise on risk but should not be the only function responsible for accepting it.
Practitioner takeaway: The right model is single-threaded accountability with shared execution: one owner accepts the risk, other teams enforce the controls, and every integration must be removable when the business justification disappears.
Related resources from NHI Mgmt Group
- What is the difference between SaaS supply chain security and software supply chain security?
- What should security teams monitor to detect SaaS supply chain abuse?
- Who should be accountable for agentic development security and supply chain governance?
- Who is accountable for enforcing supply chain security across repositories and teams?