in one lineSaaS-to-SaaS integrations are app-to-app connections that run on tokens and API keys no person owns and offboarding never touches.
the numbers
- 48%of breaches involve a third partyVerizon DBIR, 2026
- 700+companies reached through one compromised OAuth integrationFINRA on the Salesloft/Drift breach, 2025
- 1,000+believed under 10 apps vs 1,000+ actualAppOmni, 2024
1what it is
SaaS-to-SaaS integrations are connections between two applications that operate automatically, without a human logging in to trigger them. A marketing automation tool that synchronizes contact records with a CRM. An HR platform that sends employee data to a payroll system. A customer support tool that pushes tickets into a project management application.
Each of these integrations is authorized by an API key, a service token, or an application-level OAuth grant. That credential gives one application permission to read from or write to another. The integration runs in the background, often continuously, and is typically set up once and then forgotten.
This is different from user OAuth grants, which are tied to a specific user account. SaaS-to-SaaS integration credentials exist at the application layer. They are not associated with a person, do not appear in user account lists, and are not touched by directory offboarding.
2why it accumulates
Integration credentials accumulate for the same reason other SaaS access accumulates: creation is easy, cleanup is not.
Setting up an integration is a one-time task. The configuration is done, the integration runs, and the attention moves elsewhere. There is typically no process that revisits the integration to check whether it is still needed, still used, or still held by an application that is still in your stack.
When a tool is decommissioned, its integrations are often overlooked. The main application account is cancelled or removed, but the tokens it issued to other applications, or that other applications hold to reach it, stay in place. Those credentials may still be valid if the target application does not invalidate them when the source application stops using them.
Integration credentials also tend to be created by whomever set up the tool, often a technical member of a specific team rather than IT. When that person moves on, the integration has no clear owner. It continues running, or it sits dormant with a token nobody monitors.
3what it costs you
Persistent access through decommissioned tools. An application that has been removed from your stack may still hold a valid API token granting access to another application that is still active. The decommissioned tool is no longer in use but its access credential is still live. If the vendor is acquired or their infrastructure is compromised, that token is a live access path into your environment.
Unmonitored data flows. SaaS-to-SaaS integrations move data between applications continuously. Without an inventory of what is connected to what, you do not know which applications receive which data. Customer records, employee data, financial information: the flows are real and may not align with your data residency or processing agreements.
GDPR data processor gaps. Applications receiving data from your environment through automated integrations are data processors. They require DPAs. Without an inventory of integrations, you cannot maintain a complete list of processors, and you cannot confirm that agreements are in place for all of them.
Credential theft impact. If an API key or integration token is exposed through a misconfiguration, an accidental commit, or a vendor breach, an attacker with that credential has the same access the integration has. For integrations with broad read or write access, the impact is significant. Most organizations do not know how many such tokens exist or what scope they carry.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedSalesloft / Drift, 2025howA chat tool's key into your CRM is stolen from the vendor.what leavessupport tickets, including passwords pasted into themwho ends up with itan extortion group working through hundreds of companies
- it happenedGitHub OAuth tokens, 2022howIntegration keys to your code host are stolen from the integration vendor.what leavesyour private code and the secrets inside itwho ends up with itattackers looking for the next door
- it happenedSisense, 2024howAn analytics vendor is breached and the keys it holds to your systems are copied.what leavesconnections straight into your datawho ends up with itwhoever holds the vendor's keys
4what works
The inventory lives in two places. The first is the admin settings of the highest-value applications, the CRM, the HR system, the financial tools, the development platforms, where the list of API keys and connected applications shows what each connection is, what access it holds, and, where the platform records it, when it last ran. The second is any integration platform in use, Zapier, Make, Workato, which holds tokens on behalf of many applications and therefore doubles as a ready-made central inventory of at least the connections it manages.
Last-execution dates separate the living connections from the dead ones. An integration that has not run in months is a deactivation candidate, and the reasoning favors revoking over merely flagging: a dormant token grants the same access as an active one, carries the same theft and breach exposure, and provides nothing in return. The sharper version of the same logic applies to decommissioned tools, where the application is gone from the stack but tokens it was issued by other applications may still validate. Auditing the surviving applications for credentials issued to retired tools, and revoking them, closes access paths that no current process would otherwise ever touch.
Named ownership per integration is the step most environments skip and the one that determines whether the cleanup lasts. An integration with an owner gets questioned when its purpose lapses; an integration without one runs until something breaks or someone breaches it. Application-layer credentials never appear in user offboarding, which means an ownership review at each tool rotation, when a system is replaced or a builder leaves, is the only lifecycle these connections will ever have.
on the record
your turn
what you can do about it
this week
List the integrations connected to your CRM and file storage.
Remove the ones nobody uses, and give the rest an owner.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →