- The SalesLoft Drift breach hit 700+ organizations in August 2025 using stolen but valid OAuth tokens. No CVE, no malware, and no indicator of compromise was ever published for it.
- Zero Trust does not ask whether a threat has a name. It asks whether the access can be justified, so it blocks this class of attack by design.
- Three mechanisms make that work: Protect Surfaces, least-privilege access defined through the Kipling Method, and full Layer 7 inspection of every request.
- CVE submissions to NIST’s National Vulnerability Database grew 263% between 2020 and 2025. Chasing every published vulnerability is not a strategy that can keep pace.
In August 2025, an attacker walked into more than 700 companies, Cloudflare and Palo Alto Networks among them, using a valid login token from the wrong IP address. No CVE. No malware. No indicator of compromise to flag. Zero Trust would have stopped it anyway, without ever knowing the attacker’s name.
Three Kinds of Threats, One Blind Spot
Threat Type 01 · Known
Known Threats
Published vulnerabilities with CVE numbers, documented exploit techniques, known indicators of compromise. Vendors patch these. SOCs hunt them. They are the minority of what actually hits an organization.
Traditional security handles these, slowly.
Threat Type 02 · Unknown
Unknown Threats
Vulnerabilities that exist but have not been published yet. Techniques active in the wild before researchers ever document them. Average dwell time runs past 24 days before anyone knows they are there.
IOC-based security is blind here.
Threat Type 03 · Unknown Unknowns
Unknown Unknowns
Zero-days held by nation-states and organized crime. Techniques nobody has seen yet. No CVE. No hash. No domain to block. Nation-states have no incentive to publish their most valuable tools.
IOC-based security does not even know to look.
In Brief
The fundamental problem
CVE submissions to NIST’s National Vulnerability Database increased 263% between 2020 and 2025, over 40,000 published in 2024 alone, with 2025 tracking higher still. NIST enriched a record 42,000 CVEs in 2025 and still could not keep pace. Chasing every vulnerability is not a security strategy. It is an infinite treadmill that gets faster every year.
Why “known” is misleading
Publishing a CVE makes a vulnerability known to defenders, and to attackers. The average dwell time for known vulnerabilities runs past 24 days. For unknown ones, defenders can only guess. Even when a patch exists, the gap between publication and deployment is a window attackers exploit systematically.
Zero Trust’s different answer
Instead of chasing threats, Zero Trust eliminates the conditions that make them effective. Define what is allowed. Block everything else, regardless of whether the threat has a name. Protect Surfaces, least-privilege access via the Kipling Method, and full traffic inspection are the three mechanisms that make this operational.
The 2025 proof point
The SalesLoft Drift breach hit 700+ organizations, including Cloudflare, Palo Alto Networks, and Zscaler, using valid OAuth tokens from unexpected IP ranges. There was no CVE and no IOC. Just trusted credentials doing things Zero Trust policy would never have permitted. The attack was not sophisticated. The defenses were not tight enough.
Lieuwe Jan Koning, CTO, ON2IT: “You must spend most of your time and budget implementing a strategy that tries to keep attackers out in the first place. Zero Trust is that strategy.”
I. Why Chasing Known Threats Is a Losing Strategy
CVE submissions to NIST’s National Vulnerability Database grew 263% between 2020 and 2025, over 40,000 published in 2024 alone. NIST enriched a record 42,000 in 2025 and still could not keep pace. Q1 2026 submissions are running nearly one-third higher than Q1 2025. The vulnerability pipeline is not slowing down. It is accelerating.
The problem is structural. The term “known vulnerability” implies control, but in practice a published CVE is still an active threat in an organization’s infrastructure until patches are deployed and all countermeasures applied. In high-profile cases, researchers observe active exploitation of a vulnerability in the weeks or months before the CVE is even published. And once a CVE is published, new exploit techniques evolve faster than initial remediation measures can account for.
Then there are the unknown unknowns: vulnerabilities that nation-states and organized criminal groups actively develop, use, and sell on dark web markets without any incentive to publish. For these, there is no CVE, no hash, no domain name to block. No indicator-of-compromise-based tool can detect what has never been described.
The conclusion is uncomfortable but unavoidable: an organization cannot patch its way to security. The volume of vulnerabilities is too high, the exploitation window too fast, and the unknown threat landscape too broad. A strategy that chases individual threats is, by design, always one step behind.
Signal
AI-based tools that look for behavioral indicators of compromise take a more general approach, but they follow the same conceptual model. They are hunting intruders who are already inside the house. Zero Trust tries to keep them out.
II. Zero Trust’s Different Approach: Three Core Concepts
Zero Trust does not ask “what threats exist?” It asks “what access is explicitly justified?” Removing implicit trust from the network and defining precisely what is permitted eliminates large classes of both known and unknown threats in a single architectural decision, without needing to know their names.
Kindervag’s three original concepts, unchanged since 2010, are the mechanism that makes this work.
Protect Surfaces: defend from the inside out
Instead of trying to protect the entire attack surface, which is effectively the whole internet and grows larger every day, Zero Trust defines Protect Surfaces: small, bounded, defensible segments built around an organization’s most critical DAAS elements (Data, Applications, Assets, Services). The Protect Surface is the inversion of the attack surface. Concentrating defenses close to what matters most makes the blast radius of any breach structurally bounded rather than organization-wide.
Least-privilege access: the Kipling Method
Only the access needed, only when it is needed, only from where it should come. Zero Trust policy defines explicit access conditions for every Protect Surface using the Kipling Method: Who, What, When, Where, Why, and How. Access that cannot answer all six questions is not access that should be permitted. Identity is one element, but the WHERE and HOW are equally non-negotiable. A valid credential from the wrong location is not authorized access. It is an attack.
Inspect and log all traffic: verify, never assume
Zero Trust does not trust traffic because it passed a perimeter check. All traffic to and from a Protect Surface is logged and inspected through Layer 7. This is not a passive, compliance-driven logging exercise. It is the mechanism that validates, in real time, that the policy is working as intended, and it gives SOC analysts the context to detect deviations no IOC would ever surface: a known integration behaving differently than its established baseline.
Signal
Zero Trust is fundamentally based on achieving the optimal and most general prevention of data breaches, by designing protection from the inside out, not by cataloguing threats from the outside in.
III. The SalesLoft Drift Case: What Actually Happened
In August 2025, a threat actor tracked as UNC6395 compromised OAuth tokens from SalesLoft’s Drift chatbot integration, a tool used by thousands of organizations to connect their Salesforce CRM to their sales workflows. Using those tokens, the attacker quietly accessed Salesforce instances across more than 700 organizations over a ten-day window, exfiltrating accounts, contacts, cases, and opportunities, then mining that data for AWS keys, Snowflake credentials, and other secrets to pivot further.
There was no CVE. No novel exploit. No malware deployed. The attacker used valid OAuth tokens to make legitimate-looking API queries against the Salesforce Bulk API. No IOC-based tool would have triggered on traffic that was, by every technical measure, authorized.
The attack chain unfolded over months, then struck fast.
March–June 2025 · Initial compromise
SalesLoft GitHub repositories accessed. The attacker gained access to SalesLoft’s development infrastructure, downloaded code repositories, and established a guest user account. The Drift application’s AWS environment was subsequently accessed and OAuth tokens for hundreds of customer integrations were harvested. There was no Zero Trust control on a third-party vendor’s GitHub environment: a supply chain compromise outside any individual organization’s perimeter but inside its trust boundary.
August 8–18, 2025 · Active exploitation
Stolen tokens used from DigitalOcean IP ranges. The actor connected to customer Salesforce instances using the stolen OAuth tokens, but from DigitalOcean infrastructure. The Drift integration always connected from known AWS IP ranges. This was the signal. The Salesforce Bulk API was used to systematically export Account, Contact, Case, and Opportunity records across hundreds of organizations. No IP allowlisting existed on the Salesforce API integration: the WHERE question in the Kipling Method was never asked, and never enforced.
August 20–23, 2025 · Discovery and containment
Tokens revoked, integration pulled from AppExchange. Salesforce and SalesLoft revoked all active Drift OAuth tokens. The Drift application was removed from the Salesforce AppExchange. Mandiant was engaged to investigate. By the time notification reached affected organizations, the attacker had been inside their Salesforce data for up to ten days. This is where CSIRT and SOC teams step in, but the damage was done: containment after the fact is exactly what Kipling-based prevention is designed to make unnecessary.
Ongoing · Credential harvesting
Exfiltrated data mined for AWS keys, Snowflake tokens, and VPN credentials. The attacker’s primary objective was not the Salesforce data itself but the credentials embedded within it: AWS access keys, Snowflake tokens, internal passwords. The Salesforce data was the pivot point into deeper infrastructure across hundreds of victim environments. The breach was a supply chain attack with a blast radius spanning the entire customer bases of affected vendors. No data segmentation limited what the attacker could retrieve per query; a Protect Surface model would have bounded what any single integration could access.
The critical signal, from Mandiant’s investigation
Vendor connections are particularly easy to baseline due to their consistency, making IP range deviations highly suspicious and easy to detect for organizations with proper monitoring. The organizations that had that monitoring had a fighting chance. The ones that implicitly trusted valid tokens did not.
IV. Why Is This Traffic Even Allowed? The Kipling Question
The most important question about the SalesLoft Drift breach is the same question asked about Log4j, about Snowflake, about every major supply chain compromise in the past decade: why was this traffic permitted in the first place?
Applying the Kipling Method to the Drift-to-Salesforce integration would have produced the following access policy, and exposed the gap immediately.
| Question | Defined policy | What the attacker did | ZT verdict |
|---|---|---|---|
| Who | SalesLoft Drift service account, OAuth token | Valid stolen OAuth token | Token valid, would pass without additional controls |
| What | Read access to CRM sync fields only | Bulk API export of all Accounts, Contacts, Cases, Opportunities | Fail: bulk export was never in scope for a sync integration |
| Where | From SalesLoft’s known AWS IP ranges | From DigitalOcean infrastructure (208.68.36.90) | Fail: IP origin violated the defined policy, connection should have been blocked immediately |
| When | During business sync windows | Continuous access, including off-hours | Fail: access pattern outside the defined operational window |
| Why | CRM data synchronization | Credential harvesting and data exfiltration | Not detectable at policy definition, caught by WHERE and WHAT instead |
| How | Standard Salesforce REST API, defined field scope | Salesforce Bulk API with Python/aiohttp user agent | Fail: Bulk API was never authorized, a different mechanism than the defined policy |
Three of the six Kipling questions, What, Where, and How, would have flagged or blocked the attack at the point of connection. The WHERE question alone would have stopped every session the attacker initiated. The Drift integration always came from AWS. When it came from DigitalOcean, that single deviation from the defined policy was the entire attack surface that needed to be closed.
This is the core argument against IOC-based security as a primary defense. No IOC listed DigitalOcean IP 208.68.36.90 as malicious before the attack. No hash, no domain, no user-agent string was on a blocklist. The only thing that would have stopped this was a policy that said this integration is only allowed from these IP ranges, and anything else is not permitted.
Signal
It is difficult to imagine that, when using Kipling to define policy for this integration, connections from arbitrary internet infrastructure would have been permitted. Kipling enforces the craftsmanship to write, implement, and maintain effective security policy.
V. Protect Surfaces: Why the Blast Radius Was 700 Organizations
Even if the initial token compromise could not have been prevented (the attacker was inside SalesLoft’s vendor environment, outside any individual organization’s control), the Zero Trust Protect Surface model would have fundamentally changed what the attacker could do with those tokens.
The blast radius of the SalesLoft breach was unlimited within each victim’s Salesforce environment because the Drift integration had been granted access to the entire Salesforce data model. Accounts, Contacts, Cases, Opportunities, custom objects: all accessible with a single OAuth token.
A Protect Surface approach to the Salesforce integration would have defined precisely which objects the Drift integration needed for its stated purpose, CRM sync, and blocked access to everything else. An attacker with a stolen Drift token would have found a bounded, minimal access surface rather than an open data warehouse.
| Without Zero Trust | With Zero Trust Protect Surfaces |
|---|---|
| OAuth token grants access to all Salesforce objects by default | Token scoped to only the objects the integration needs for its defined purpose |
| Connection permitted from any IP that presents a valid token | Connection only permitted from the vendor’s declared infrastructure IP ranges |
| Bulk API access available to any authenticated integration | Bulk API access explicitly denied unless in the policy; sync does not require bulk export |
| Integration activity not baselined; any query pattern is normal | Baseline established; deviation from normal volume, timing, or data access triggers a SOC alert |
| Blast radius: entire Salesforce data model across all objects | Blast radius: only the objects explicitly scoped in the Protect Surface policy |
Signal
Even when attackers succeed in gaining an initial foothold, as they did here through the vendor’s own infrastructure, segmented Protect Surfaces provide a second layer of prevention against data collection and exfiltration. The Kipling Method would have stopped the attack at the WHERE check. The Protect Surface model would have limited the damage if it hadn’t.
The Numbers Behind the Argument
Mandiant · Google GTIG · 2025
Cloudflare Incident Report · 2025
NIST NVD · Analysis
NIST NVD · April 2026
Kindervag · Kipling Method
ON2IT Analysis · 2025
The Strategy That Works Against What You Don’t Know
The SalesLoft Drift breach was not a sophisticated attack. It was a supply chain compromise followed by the use of valid credentials from a slightly different IP range. The organizations that were not impacted, or that detected the intrusion quickly, were the ones that had done two things: defined their third-party integrations as Protect Surfaces with explicit access policies, and baselined vendor connection behavior so deviations were immediately visible.
That is Zero Trust. Not a product. Not a vendor. A strategy that replaces implicit trust, in tokens, in integrations, in traffic that looks legitimate, with explicit, policy-defined, continuously verified access. It does not matter whether the threat has a CVE number. What matters is whether the traffic can answer six questions: Who, What, When, Where, Why, and How.
The security industry will continue to produce more CVEs, more IOCs, and more threat intelligence feeds. That work is valuable, and insufficient. The organizations that are meaningfully more resilient than their peers are the ones that have stopped trying to catalogue every threat and started defining exactly what is allowed. Everything else is blocked by default.
An organization cannot see all the threats coming. It can define what is permitted. Zero Trust is the strategy that makes that definition do the work.
Final signal
Zero Trust is not about knowing every threat. It is about knowing exactly what should be permitted, and rejecting everything else, regardless of whether you can name it.
Get in touch
Let’s find your WHERE gap before someone else does.
A short conversation is enough to see whether your vendor integrations would survive a Kipling check.
Contact usSources
- Mandiant / Google GTIG. Investigation into the SalesLoft Drift breach, 2025.
- Cloudflare. Incident report on the SalesLoft Drift supply chain compromise, 2025.
- NIST. National Vulnerability Database, CVE submission volumes, April 2026.
- Kindervag, J. Kipling Method and Protect Surface framework, Zero Trust.