The biggest SaaS data thefts of the last two years did not break into the SaaS platforms at all: attackers used credentials and tokens that customers or their suppliers had already issued, and walked in as trusted users and trusted apps. This briefing is for board members, chief executives and the executives who answer to them for technology and supplier risk. It explains, in business terms, why connected apps and their tokens have become the practical perimeter around customer, sales and support data, what the Snowflake and Salesloft Drift campaigns teach directors, and the questions, metrics and 90-day plan that show whether management has this under control. The technical controls are in the OAuth and SaaS integration breaches guide and the risk catalogue in the Top 10 SaaS Security Risks.
The risk in one paragraph
Every business now runs on dozens or hundreds of SaaS platforms, and those platforms are wired to each other with OAuth apps, API keys and service accounts so that data flows without anyone logging in. Each connection is a non-human identity holding a standing permission, often broad, often long-lived, and often stored by a third party you have never assessed. When one of those suppliers is breached, its tokens become an attacker's keys to your data, and the activity looks like normal use of an approved integration. The provider's own security is not the question; the question is whether your organisation knows which apps and tokens can reach its data, whether each one is limited to what it needs, whether anyone would notice a bulk export, and how fast the business can cut a supplier off. That is a governance problem the board can and should ask about.
Why this is a board-level issue now
- A password was enough at scale: in the 2024 Snowflake customer data thefts, Mandiant and Snowflake notified about 165 potentially exposed organisations. Mandiant found that the accounts used had no MFA, at least 79.7% had credentials previously exposed by infostealer malware, some credentials had not been rotated for up to four years, and the affected instances had no network allow lists. Mandiant traced every incident it responded to back to compromised customer credentials. See the Snowflake breach and the UNC5537 threat actor profile.
- One supplier's tokens opened hundreds of customers: in August 2025 an actor Google tracks as UNC6395 used compromised OAuth tokens for the Salesloft Drift integration to export large volumes of data from many companies' Salesforce instances, then searched the data for AWS access keys, passwords and Snowflake tokens. Google's Threat Intelligence Group said the issue did not stem from a vulnerability in the core Salesforce platform. See the Salesloft Drift breach and the UNC6395 threat actor profile.
- The blast radius chains: the Drift data was mined for secrets that unlock other systems. A support ticket containing a cloud key turns a CRM breach into a cloud breach. Boards should assume that what sits in one SaaS platform can open the next.
- Supplier risk now includes your suppliers' identities: traditional third-party assessments ask about a supplier's certifications, not how it stores the tokens it holds for your tenant. The NIST Cybersecurity Framework 2.0 places supplier risk in its Govern function (GV.SC-07: supplier risks are understood, recorded, prioritised, assessed, responded to and monitored).
- Directors are expected to own cyber risk: in the UK, the government's Cyber Governance Code of Practice sets expectations for boards. See the UK Cyber Governance Code of Practice Guide.
How the integration perimeter works
Directors do not need the protocol detail, but they do need the shape of the risk. The table sets out the four kinds of access that sit around a SaaS platform and who usually holds them.
| Access type | Who holds it | Why it is risky | What management should show |
|---|---|---|---|
| Human logins | Staff, contractors, administrators | Infostealer malware harvests passwords and session cookies | SSO with phishing-resistant MFA for everyone, including contractors |
| Service accounts and API keys | Your own scripts, data pipelines, reporting tools | Often password-based or long-lived, rarely owned, never reviewed | Named owner, strongest authentication the platform offers, rotation |
| Connected OAuth apps | Third-party SaaS suppliers (chat, sales, analytics, AI tools) | Supplier stores refresh tokens; a supplier breach exposes every customer | Approved app list, minimum scopes, IP restrictions where available, revocation plan |
| User-granted consents | Individual employees clicking "allow" | Shadow integrations and consent phishing outside procurement | Admin approval for new apps, regular review of consents |
Every row except the first is a non-human identity. See the Non-Human Identity (NHI) Guide and the Consent Phishing and Illicit OAuth Grants Guide.
Five questions for the board to ask
- Which apps and tokens can reach our most sensitive SaaS data today? For the CRM, support desk, data warehouse and collaboration suite, show the list of connected apps and service accounts, their owners and their permissions.
- Could anyone reach that data with only a password? What share of human and service access uses SSO with MFA or key-based authentication, and how many password-only accounts remain?
- If a supplier holding our tokens were breached tonight, how fast could we cut it off? Is there a tested runbook to revoke an integration's tokens, rotate secrets it could have read, and confirm no further access?
- Would we see a bulk export while it is happening? Are SaaS audit and event logs collected centrally, and when did we last test an alert on a large export by an approved app?
- What secrets are sitting inside our SaaS data? Do we scan tickets, CRM records and chat for keys and passwords, and rotate what we find?
Red flags in management answers
- "The vendor is SOC 2 certified": a certificate says nothing about how the supplier stores the refresh tokens it holds for your tenant.
- No owner for integrations: procurement approved the supplier, IT connected it, and nobody owns the token afterwards.
- "Full access" scopes accepted by default: integrations granted everything because the setup wizard asked for it.
- Logs not licensed or not collected: detailed SaaS event logging is an add-on that was never bought, or it is switched on but nobody reads it.
- Revocation never rehearsed: the first time the team revokes a major integration will be during an incident.
What good looks like
- A single inventory of SaaS platforms, connected apps, service accounts and API keys, each with a business owner and a stated purpose. See the SaaS Security Guide.
- New third-party apps need admin approval, a security review of how the supplier stores tokens, and the narrowest scopes that work. The UK NCSC's supply chain security principles (understand the risks, establish control, check your arrangements, continuous improvement) give a ready structure.
- Core platforms configured to a published baseline: for Microsoft 365, for example, CISA's SCuBA project publishes secure configuration baselines covering services such as Exchange Online, SharePoint Online and Teams.
- Token use restricted to the supplier's known network ranges where the platform supports it, and session lifetimes set deliberately.
- Central monitoring of SaaS event logs with alerts on bulk export, unusual query volumes and access from anonymising networks. See the SSPM Integration Security Guide.
- A tested playbook to revoke and rotate when a supplier is breached. See the OAuth Token Theft Incident Playbook.
- Routine scanning of tickets, CRM and chat for secrets. See the Secrets Shared in Chat and Tickets Guide.
Where to invest first
- Visibility: discover every connected app and token on the five platforms that hold the most customer data. This is the precondition for everything else.
- Authentication: remove password-only access for people and service accounts on those platforms. This would have closed the access route in the Snowflake campaign.
- Least privilege for integrations: cut scopes to what each app needs and remove unused apps. Fewer and narrower tokens shrink the blast radius of any supplier breach.
- Detection: central SaaS logs with alerts on bulk export. In the Drift campaign the export queries remained in customers' logs even after the actor deleted query jobs.
- Response: a rehearsed revoke-and-rotate playbook and a contract clause requiring suppliers to notify you promptly of any compromise of tokens they hold.
Metrics to track
| Metric | What it tells the board |
|---|---|
| Connected apps and tokens on critical SaaS platforms, and the percentage with a named owner | Whether the integration perimeter is known and governed |
| Percentage of human and service access to critical SaaS using SSO with MFA or key-based authentication | Exposure to the Snowflake-style credential route |
| Integrations holding broad or full-access scopes | Blast radius of a supplier breach |
| Time to revoke a major integration and rotate its secrets, measured in an exercise | Readiness to contain a supplier compromise |
| Critical SaaS platforms with central log collection and a bulk-export alert | Ability to see theft while it happens |
| Secrets found in tickets and CRM records per quarter, and percentage rotated | Whether SaaS data can be mined for keys to other systems |
The board should see these quarterly. See the Board Cyber Risk Reporting Guide.
A 90-day plan
- Days 1 to 30: management names an owner for SaaS integration risk, produces the first inventory of connected apps and tokens for the top five platforms, and reports MFA coverage for human and service access.
- Days 31 to 60: remove unused apps, cut excessive scopes, close password-only access on critical platforms, turn on admin approval for new apps, and start central log collection with a bulk-export alert.
- Days 61 to 90: run a tabletop exercise in which a supplier holding tokens is breached, measure time to revoke and rotate, add token-handling questions to supplier assessments, and deliver the first metrics pack to the board.
Standards and references
- Google Threat Intelligence Group: Widespread Data Theft Targets Salesforce Instances via Salesloft Drift
- Mandiant: UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
- NIST: Cybersecurity Framework 2.0
- NCSC: Supply chain security principles
- CISA: Secure Cloud Business Applications (SCuBA) Project
How NHI Mgmt Group can help
We provide independent non-human identity risk assessments and board briefings, including how OAuth apps, API keys, service accounts and integration tokens are governed across SaaS estates. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, tokens and secrets. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: SaaS Security Maturity Model · Board Briefing: NHI Risk · Third-Party Risk Management Guide · How to detect use of a stolen OAuth refresh token