SaaS-to-SaaS lateral movement happens when attackers use one cloud application or integration to reach another connected service. It is common when refresh tokens or API credentials are stored by third-party vendors on a customer’s behalf. The risk is that one compromise can open several downstream tenants at once.
Expanded Definition
SaaS-to-saas lateral movement is a cloud-to-cloud abuse pattern where a compromised application, integration, or delegated token is used to pivot into another SaaS tenant or workspace. In NHI security, the risk sits in the trust relationship, not just the initial breach.
Definitions vary across vendors, but the operational meaning is consistent: if one service can act on behalf of a customer in another service, attackers may inherit that reach after stealing a refresh token, OAuth grant, API key, or similar secret. This makes the problem adjacent to NHI governance, third-party risk, and session revocation, and it is easier to miss when the credentials are held by a vendor or embedded in an integration layer. The pattern is visible in incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach, where trust in connected systems became the attack path. NIST Cybersecurity Framework 2.0 reinforces the need to manage external dependencies, identity exposure, and recovery actions across the environment.
The most common misapplication is treating the incident as a simple app compromise, which occurs when teams fail to trace which connected SaaS platforms were granted persistent delegated access.
Examples and Use Cases
Implementing controls against SaaS-to-SaaS lateral movement rigorously often introduces friction in onboarding and integration maintenance, requiring organisations to weigh faster automation against tighter authorization, shorter token lifetimes, and more frequent review cycles.
- A sales engagement platform stores OAuth refresh tokens for a CRM integration; if that platform is breached, the attacker may reach customer records in the downstream tenant.
- A backup or productivity app has broad delegated permissions and becomes a bridge into file storage, chat, or document systems after a single secret is stolen.
- An identity-linked workflow tool is compromised, and the attacker uses the existing grant to move from one SaaS workspace to another without triggering password-based alerts.
- A third-party admin console retains long-lived API keys, allowing cross-tenant access that resembles the blast radius seen in the Snowflake breach and the Dropbox Sign breach.
- Security teams review 52 NHI Breaches Analysis alongside the NIST Cybersecurity Framework 2.0 to identify recurring failures in secret handling, revocation, and delegated trust.
In practice, the term applies whenever an integration turns one compromise into a multi-tenant event, especially when no human signs in during the attack path.
Why It Matters in NHI Security
SaaS-to-SaaS lateral movement is a non-human identity problem because the attacker often exploits credentials, tokens, or service permissions that were never meant to be used interactively. Once those credentials are valid, traditional perimeter controls offer little protection, and RBAC, PAM, and ZTA only help if the underlying SaaS grants are actually scoped and rotated.
This is where the NHI evidence becomes hard to ignore: NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, and only 20% have formal processes for offboarding and revoking API keys. That gap makes connected SaaS platforms a natural target for attackers seeking persistent access, especially when a compromised integration can fan out into several downstream services at once. The 90% of IT leaders who say proper NHI management is essential for Zero Trust are pointing to the same operational truth reflected in Sisense breach patterns and related token theft cases.
Organisations typically encounter the consequence only after a downstream tenant is accessed through a trusted integration, at which point SaaS-to-SaaS lateral movement becomes operationally unavoidable to address.
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 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-02 | Addresses secret sprawl and over-permissioned non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Focuses on managing access permissions across connected systems. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of every delegated connection. |
Treat each SaaS integration as untrusted until its permissions, tokens, and sessions are validated.
