The hardest breach to imagine is the one that comes through an app you barely remember signing up for. That is exactly what happened in mid-June, when an OAuth-token theft at a small competitive-intelligence vendor spilled Salesforce data across hundreds of customer businesses. None of those owners had been hacked directly. None of them had to click a phishing email. They had simply, at some point in the past, clicked the “Connect to Salesforce” button inside a tool a sales rep wanted to try. The token that got created in that moment is the same one the attackers grabbed weeks or months later. The lesson is not about Salesforce or about that one vendor. The lesson is that every business now runs on a stack of connected applications, and most of those connections are forgotten the moment they are made. Reviewing them this week is no longer optional.
What Happened With The Klue Salesforce Breach?
On June 19, Salesforce publicly disabled a third-party application called Klue from its AppExchange after an OAuth-token compromise affecting hundreds of customer organizations. The compromise window itself was narrow — a 36-hour stretch in mid-June — but the surface area was wide. Any business that had at some point connected Klue to its Salesforce environment was potentially exposed, regardless of whether anyone on the team had logged into Klue in months. The data at risk included CRM accounts, deal notes, contact records, opportunity history, and account-team notes — the daily fuel of any sales operation.
Why The Attack Bypassed Every Normal Defense
The detail that should rattle every small business owner is that this attack did not need a stolen password, a phished employee, or a missing patch. The attackers did not compromise Salesforce. They compromised a vendor that already had legitimate, authorized read access to Salesforce on behalf of its customers. From the Salesforce side, every request looked perfectly normal — an approved app, with an approved token, pulling data it was approved to pull. Multi-factor authentication did not stop it because no one was logging in. Conditional access did not stop it because the request came from the right service. The token was the key, and the token had already been issued.
The Pattern Is Not New — Just Newly Common
Salesforce is the headline, but the same playbook is unfolding across every business SaaS category. Last week’s CMS plugin disclosure that exposed email and CRM API keys followed the exact same shape: a small piece of connected software, doing what it was supposed to do, holding credentials that quietly reached deep into the customer’s stack. Whether the connector is a marketing tool, a billing add-on, an AI assistant, a meeting recorder, or a productivity widget, the trust model is identical. You authorized it once. It can read what you authorized it to read for as long as the token lives.
How Can An App You Never Use Leak Your CRM Data?
OAuth is the standard that lets one application read or write data in another without sharing passwords. When you click “Sign in with Google” or “Connect to Microsoft 365” or “Add to Salesforce,” what happens behind the scenes is that the host platform issues the third-party app a token. That token carries a defined scope — read contacts, send mail, view drive files, update opportunities — and stays valid for a set window, often weeks or months at a time. The third-party app stores that token on its own servers. The host platform sees the third-party app, not the underlying user, as the requester.
The Token Outlives The Decision To Use The App
The piece most owners miss is that the token does not care whether anyone is still using the app. A sales rep who tested a prospecting tool nine months ago and then deleted the trial account did not necessarily revoke the OAuth grant. A marketing manager who connected a social scheduling tool, switched platforms, and forgot to disconnect did not necessarily revoke the OAuth grant. The token sits in the vendor’s database, valid, with scope to do exactly what it was given permission to do. When that vendor is breached — or when their secrets get pushed to a public code repository, or when a former employee walks away with database access — the token comes with it.
Why The CRM Is The Most Common Target
CRM platforms attract this exposure pattern for the same reason they are valuable in the first place. The CRM is where the customer list lives, where pricing conversations are logged, where contract terms get noted, and where the next-step intent of every active prospect sits. Almost every business application wants to connect to the CRM in some way. Email marketing wants to sync contacts. Quoting tools want to read accounts. Meeting recorders want to attach notes to opportunities. Each connection is a separate token, a separate vendor, a separate place where a future breach could let attackers pull your customer book. The Salesforce-Klue incident is the version of this risk that made the news. The version that has not made the news is sitting inside most small business CRM connection menus right now.
Which SaaS Connections Are Sitting In Your Business Today?
Every small business underestimates the size of its connected app inventory. The first time a managed IT provider runs the report, the result is usually two to three times what the owner expected. The reason is straightforward: nobody is asked for permission when a salesperson clicks “Connect with Google,” a marketer clicks “Add to Slack,” or a finance lead clicks “Authorize HubSpot.” Those decisions are made one at a time, on individual devices, often inside trial accounts. They accumulate quietly. Three years in, the connection list is a small museum of every tool the team has ever tried.
Where To Look First
Four host platforms deserve a one-hour review this week. Inside Google Workspace, the Security > API Controls > App Access Control screen lists every third-party app that has been granted access to user data. Inside Microsoft 365, the Enterprise Applications panel inside Entra ID shows every consented application along with the permissions it holds. Inside Salesforce, the Connected Apps OAuth Usage page lists every app that has been authorized along with the user accounts that authorized them. Inside Slack, the Apps page under each workspace shows every installed integration. Most owners have never looked at these screens. The first review almost always finds tools nobody on the current team recognizes.
The Ghost Connections Nobody Tracks
The hardest connections to find are the ones tied to people who no longer work at the business. When an employee leaves, their email account is usually disabled inside a day. The OAuth grants they personally authorized while employed, however, often outlive that off-boarding step entirely. This is the same blind spot as former-vendor account access that quietly lingers after a contract ends — the access was granted by a person who is no longer there to confirm it should still exist. Token revocation should be part of every off-boarding checklist. Most small business off-boarding checklists do not mention it at all.
How Do You Audit And Lock Down Connected Apps This Week?
The good news is that this is a tractable problem. A focused two-hour effort, repeated quarterly, closes most of the exposure for a small business. The exact mechanics are slightly different on each host platform, but the workflow is the same across all of them: inventory what is connected, decide which connections still belong, revoke the rest, then tighten the rules for what gets added next time.
A Four-Step SaaS Connection Audit
Step one is the inventory. Pull the connected-apps list from each major platform — Microsoft 365, Google Workspace, Salesforce or HubSpot, Slack, and any other host where authorization happens. Capture the app name, the user who authorized it, the date authorized when available, and the scope of permissions held. Treat anything you cannot identify as untrusted by default.
Step two is the trim. For every entry on the inventory, ask three questions. Is this tool still in active use by someone on the current team? Does the scope of access match the actual job the tool needs to do? Has the vendor disclosed a breach or material change since the connection was made? Anything that fails the first question gets revoked immediately. Anything that fails the second gets reduced to the minimum scope. Anything that fails the third gets a fresh review of the vendor before being kept.
Step three is the lockdown. Set the host platforms so that future third-party app connections require admin approval rather than letting any user click through a consent screen. Inside Microsoft 365, that means turning user consent off or limiting it to verified publishers with low-risk scopes. Inside Google Workspace, that means moving high-risk OAuth scopes to a managed allow-list. The goal is not to block useful tools. The goal is to stop new connections from being added silently. This is the same principle as requiring multi-factor authentication on the host accounts themselves — an extra moment of friction in exchange for a much smaller attack surface.
Step four is the rhythm. Put the audit on the calendar at a regular cadence — quarterly is reasonable for a small business, monthly for one that adopts new tools quickly. The first audit will be the longest. Every audit after that should take about an hour. Pair it with the off-boarding checklist update so that token revocation becomes part of the standard last-day process for any employee, contractor, or agency relationship that ends.
What To Ask Vendors Before You Connect
The audit handles existing connections. A short pre-connection checklist handles new ones. Before authorizing any third-party app to read or write business data, confirm three things in writing. The vendor enforces multi-factor authentication on its own administrative accounts. The vendor has a documented breach-notification timeline. The vendor will delete customer data and revoke tokens within a defined window after the relationship ends. These are not exotic requirements. They are the same questions a Microsoft 365 administrator should be asking about every plug-in, every connector, and every Microsoft 365 Business Premium add-on that touches customer data. If a vendor cannot answer any of the three clearly, that is the answer.
When Should You Bring In Outside Help On Your SaaS Stack?
The honest answer is that almost no small business has a person in-house who reads SaaS security advisories every week or runs the connected-app reports across four host platforms on a regular cadence. That is a normal place to be. It is also the gap that managed IT providers exist to close. A one-time SaaS connection audit is usually scoped tightly enough to fit inside a single engagement, and the steady-state work afterward fits cleanly inside a normal managed services agreement.
The artifact from that first review tends to surprise owners in useful ways. Beyond the list of apps to revoke, the review usually surfaces a short list of accounts that should never have been authorized to grant consent in the first place, a couple of vendor relationships that ended without proper token revocation, and one or two high-scope tools that should be replaced with lower-scope alternatives. None of those findings would normally show up on an internal audit. They show up because someone is finally looking at the connection list with a security lens. To schedule a SaaS connection audit with our managed IT services team, reach out today and we will walk through what your current connection list looks like and what tightening it up would involve.
Frequently Asked Questions
Should we revoke a connection even if we are not sure whether the app is in use?
Yes, when in doubt, revoke. The cost of revoking an app that turns out to still be in use is a short interruption while the active user reconnects it under the new approval process. The cost of leaving an unused app connected is that its token continues to carry access to your customer data until the next breach. Revocation is the safer default by a wide margin.
How is an OAuth-token breach different from a password breach?
A password breach can usually be contained by resetting the password and turning on multi-factor authentication. An OAuth-token breach cannot. The token bypasses the login screen entirely because it represents an app-to-app trust relationship that has already been authorized. Containment requires revoking the token at the host platform, rotating any shared secrets, and confirming the vendor has invalidated the underlying credentials on their side as well.
Does multi-factor authentication on our user accounts protect us from this risk?
Only partially. Multi-factor authentication protects the user login. It does not protect the token issued to a third-party application after the user has already logged in. Treat connected-app review as a separate control from the multi-factor authentication on user accounts. The two complement each other, but neither replaces the other.
Where do we find the connected-app list in Microsoft 365 and Google Workspace?
In Microsoft 365, open the Microsoft Entra admin center, then go to Enterprise Applications. The list shows every consented app along with the permissions granted to it. In Google Workspace, open the Admin console, then go to Security and then API Controls. The App Access Control screen lists every third-party app that has been authorized against any user account in the domain. Both screens support filtering and bulk revocation.
How often should we run a SaaS connection audit?
Quarterly is reasonable for most small businesses. Monthly is better for any business that adopts new tools quickly, runs a sales team that experiments with prospecting software, or has had recent turnover. The first audit takes the longest because the inventory is starting from scratch. Subsequent audits should fit comfortably inside an hour once the baseline exists and the off-boarding process is updated.
What should we do if we find a connection we cannot identify at all?
Revoke it. An unidentified consented application is the highest-priority entry on any audit list because it could represent an old test, an off-boarded employee’s tool, or a malicious grant from a phishing campaign. Once revoked, document what was removed so that if a current team member later asks why a tool stopped working, you have a clear record of when access was withdrawn and why.
Does this risk apply to small businesses or only to enterprises?
It applies to any organization that uses cloud business applications, which now means almost every small business. Enterprises tend to have governance teams that maintain connected-app inventories. Small businesses tend to skip that step, which makes the underlying exposure higher per employee, not lower. The recent OAuth-token incidents have all touched customers from one-person shops to multi-thousand-employee organizations.