SaaS-to-SaaS activity is the exchange of data or actions between two cloud software services without direct human involvement. In identity and security terms, it usually relies on non-human identities such as OAuth tokens, API keys, service accounts, or delegated permissions that must be governed, monitored, and limited to approved scopes.
How SaaS-to-SaaS Activity Works
SaaS-to-SaaS activity is usually driven by delegated trust, not by a person clicking through each step. One cloud service is allowed to act inside another through an OAuth grant, API key, service account, or similar non-human credential, so the security posture depends on how tightly that trust is defined and monitored.
This matters because the relationship is often broader than a single transaction. Once a connector, app, or integration is approved, it can sometimes read data, create records, trigger workflows, or move information across systems at machine speed, which makes scope control and trust boundaries central to the risk model.
Why SaaS-to-SaaS Activity Creates Identity and Access Complexity
The identity question is not just “who signed in,” but “which software component is acting, under what authority, and for how long.” That makes SaaS-to-SaaS activity an identity and authorization problem as much as an application-integration problem, because the access is often persistent, delegated, and difficult to notice once established.
In practice, the most important control point is the grant itself: what permissions were approved, whether the integration can be limited to specific tenants, objects, or actions, and whether the credential or token can be revoked without breaking legitimate business flows. If the integration inherits broad user privileges or service permissions, the blast radius can be much larger than the business owner expects.
The same pattern also creates governance questions around ownership. An integration may be installed by one team, used by another, and technically administered by a third-party vendor, so organisations need clear accountability for approval, periodic review, and removal when the use case ends.
Common Security Failure Modes
SaaS-to-SaaS activity fails most often when delegated access outlives the business need. Stale OAuth grants, overbroad API scopes, long-lived secrets, and poorly governed third-party apps can all turn a useful automation path into a standing path into sensitive data or actions.
Another common failure mode is weak visibility. Many organisations can see that a connector exists, but not exactly what data it can reach, what downstream actions it can trigger, or whether it has been used in ways that diverge from the original approval. That makes it easy for malicious abuse, accidental overreach, or supply-chain compromise to blend into normal workflow traffic.
When the integration is compromised, the attacker often inherits the same trust as the legitimate service. That can enable data exfiltration, fraudulent actions, mailbox or CRM abuse, lateral movement into adjacent SaaS platforms, or quiet persistence through a trusted app relationship.
What Good Governance Looks Like
Strong governance starts with inventory. Organisations should know which SaaS applications are connected, which identities or tokens they use, what scopes they have, and which business owner is responsible for each relationship.
Approval should be scope-based rather than app-based. A connector should receive only the minimum permissions needed for the intended workflow, and those permissions should be reviewed whenever the workflow changes. Where possible, use tightly scoped access, separate service identities, and short-lived credentials instead of broad, reusable secrets.
Monitoring should focus on both the integration and the data path. SaaS-to-SaaS and OAuth app governance becomes materially stronger when teams can connect consent, scope, token lifecycle, and revocation to a clear operational owner.
Risk and Threat Considerations
SaaS-to-SaaS activity concentrates trust in credentials and delegated permissions, so a single abused grant can expose multiple systems at once. The main risk is not the integration itself, but the size and persistence of the access path it creates.
Failure mechanism: An attacker or careless integration uses a valid token, service credential, or overbroad OAuth grant to perform actions that look legitimate to the target SaaS platform, bypassing normal human approval steps.
Impact: Sensitive data can be read, copied, modified, or forwarded at scale, and the compromised trust relationship can be reused for persistence, impersonation, or further SaaS abuse until the grant is revoked and the affected identity material is rotated.
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 NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | SaaS-to-SaaS activity often relies on tokens and API secrets that must be protected. |
| NHI-05 — Overprivileged NHI | Delegated SaaS integrations frequently accumulate scopes beyond the workflow they need. | |
| NHI-09 — NHI Reuse | Reusable tokens and shared non-human credentials increase blast radius across connected SaaS tools. | |
| Recommendation — Limit exposure of integration secrets and revoke any leaked credentials immediately. Constrain each SaaS integration to the minimum scopes needed for its task. Avoid reusing the same non-human credential across unrelated integrations. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens, API keys, and similar credentials require lifecycle control and revocation. |
| AC-6 — Least Privilege | SaaS-to-SaaS access should be restricted to only the permissions required for the workflow. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Monitoring SaaS-to-SaaS actions depends on reviewing logs for unusual delegated activity. | |
| Recommendation — Manage integration credentials through issuance, rotation, storage, and revocation controls. Restrict each integration to the minimum permissions needed to complete its approved actions. Review integration logs for unusual data access, privilege use, and workflow-triggered actions. | ||
Practitioner Guidance
Why practitioners should care: Treat SaaS-to-SaaS activity as a privileged trust relationship, not as a simple convenience feature. The operational question is whether every connected app still needs the access it has and whether the owner can explain the business purpose of each scope.
What to watch for: Pay close attention to dormant connectors, broad admin consent, third-party apps with long-lived refresh tokens, and integrations that can touch more records or workflows than their stated use case requires. These are the situations most likely to create hidden exposure.
Practitioner takeaway: Review SaaS integrations as part of access governance, not only as part of application inventory, because the real risk sits in delegated authority, token longevity, and the difficulty of spotting abuse after consent has been granted.
Related resources from NHI Mgmt Group
- What should teams verify before letting AI investigate IdP and SaaS activity?
- Why do proxy-based CASBs miss so much shadow SaaS activity?
- Why do identity attacks with normal-looking activity still bypass traditional controls in cloud and SaaS environments?
- Who should be accountable when identity teams expand access governance to unstructured data and SaaS activity insights?