Third-Party Risk Management in 2026: Vendor Security Assessment After Salesloft and Snowflake

The most damaging breaches of the past two years did not start where the regulator looks first. They started somewhere else — in a chatbot integration, a forgotten demo account, a CI/CD pipeline at a vendor most procurement teams could not name three months earlier. By the time the impact hit the cover page, the original vector was a footnote.

That pattern is now the dominant attack model. IBM’s X-Force Threat Intelligence Index 2026 puts numbers on it: large supply chain and third-party compromises have increased nearly fourfold since 2020. Most organisations’ third-party risk programmes were not built for this. They were built to evidence due diligence at procurement — a one-time security questionnaire, a SOC 2 review, an annual reassessment if anyone remembered. They are not built for an environment in which the vendor itself is the attack surface and the OAuth tokens it holds are the keys.

This guide is a working framework for what TPRM has to look like in 2026. It draws lessons from the two incidents that should be teaching every CISO right now — the 2024 Snowflake credential-stuffing campaign and the 2025 Salesloft/Drift OAuth supply chain breach — and translates them into the controls, processes, and tooling that an honest TPRM programme needs. It is opinionated about what to drop and what to add, because most TPRM programmes are doing the wrong things well rather than the right things at all.

The two incidents that should be reframing every TPRM programme

Snowflake (2024): identity hygiene at the customer edge

The Snowflake incident was not a Snowflake breach. The platform itself was not compromised. What happened, between roughly April and June 2024, is that a financially motivated threat group — tracked by Mandiant as UNC5537 and tied operationally to ShinyHunters — used credentials harvested by infostealer malware to log into roughly 165 Snowflake customer tenants. Push Security’s analysis of the campaign was unsparing: more than 80% of the compromised accounts had prior credential exposure, none had MFA, and many of the credentials dated back to infostealer infections from as early as 2020 — never rotated, still valid years later.

The downstream damage was on the cover of every security publication that summer. AT&T, Ticketmaster/Live Nation, Santander, Neiman Marcus, LendingTree, Advance Auto Parts. Wikipedia’s running tally puts the total at more than 500 million records across 165 organisations. The Judicial Panel on Multidistrict Litigation consolidated 32 lawsuits against Snowflake in October 2024. Snowflake responded by making MFA mandatory for all human users on accounts created from October 2024 onwards, and by November 2025 began blocking sign-in for all password-only logins.

The TPRM lesson is not “enforce MFA.” That was already in every vendor security questionnaire. The lesson is that the Snowflake breach happened because the third-party security model in use across the industry — vendor self-attestation about controls — could not see what was actually configured at the customer’s tenant. Snowflake, the vendor, was operating per its shared-responsibility model. The customers, doing the due diligence, never validated whether MFA was actually on, whether SSO bypasses were disabled, whether dormant demo accounts were still active. The control existed on paper. It did not exist in production.

Salesloft/Drift (2025): trust transitivity at machine speed

The Salesloft/Drift breach is more important. It is the cleanest example to date of how the trust model embedded in modern SaaS integrations breaks under attack.

The mechanics, drawn from Mandiant, Cloudflare’s incident write-up, and AppOmni’s analysis: between March and June 2025, attackers (tracked as UNC6395, also called GRUB1) compromised Salesloft’s GitHub environment, established persistence, and used it as a pivot into Drift’s AWS environment. From there they exfiltrated the OAuth refresh tokens that Drift customers had issued to allow the chatbot to integrate with Salesforce, Google Workspace, and Slack. Between roughly 8 August and 18 August 2025, the attackers used those tokens to systematically query and exfiltrate Salesforce records from more than 700 organisations, including Cloudflare, Zscaler, Palo Alto Networks, Tenable, Proofpoint, SpyCloud, Tanium, and PagerDuty. The targeting was credential-harvesting: AWS keys, Snowflake tokens, VPN credentials, anything that could be pivoted into a follow-on intrusion.

There are three things about this incident that should be sitting on every CISO’s desk.

The first is that no vulnerability was exploited at any of the 700+ victim organisations. The attackers used valid OAuth tokens issued through the standard authorisation flow. The activity was indistinguishable from legitimate Drift API traffic. Traditional monitoring did not flag it because there was nothing anomalous to flag — a trusted integration was doing what a trusted integration does, just on behalf of someone else.

The second is that the impact was not bounded by the vendor breach. Stolen Salesforce data that contained AWS keys or Snowflake tokens became the seed for the next intrusion. The Cloud Security Alliance’s analysis of the incident put the point bluntly: the Drift compromise differs from earlier supply chain attacks like SolarWinds or Kaseya precisely because attackers exploited the trust relationship itself, not a code-level vulnerability. That trust is transitive. Once one vendor is breached, every customer’s downstream secrets become exposure.

The third is that identity is the perimeter, and the identity in question is non-human. OAuth tokens for SaaS integrations are machine identities. Most organisations have no inventory of them. They are issued during procurement, granted broad scopes during integration setup, and never reviewed afterwards. This is the third-party risk surface that nobody is managing.

These two incidents define the TPRM problem for 2026. Snowflake says: vendor self-attestation about customer-side controls does not work. Salesloft says: trust delegated to integrations is trust delegated to whoever compromises that integration next.

Where most TPRM programmes are still wrong

Before the framework, the honest part. Most third-party risk programmes are doing one or more of these things, and all of them are wrong in 2026.

Treating the security questionnaire as the programme. A SIG, CAIQ, or custom 200-question questionnaire is a procurement artefact. It evidences that you asked. It does not evidence that the vendor’s controls work, that they are still configured the way they were when the questionnaire was returned, or that the integration you are about to grant them respects least privilege. Questionnaires are necessary. They are not sufficient, and the gap between necessary and sufficient is where every recent supply chain breach has lived.

Reassessing annually. Vendor security posture changes weekly. Reassessment cadences set in 2018 — annual for high-criticality vendors, every other year for medium — are now meaningless. The Salesloft/Drift attackers were inside Salesloft’s GitHub from March 2025. By the August 2025 exploitation window, every annual reassessment of Salesloft conducted in 2025 had already missed the active compromise.

Scoring vendors but not their integrations. A vendor risk score from BitSight, SecurityScorecard, or the inevitable in-house spreadsheet rates the vendor. It does not rate the OAuth scopes the vendor’s app holds in your environment, the IPs it can call from, the data objects it can read, or whether anyone has looked at the integration since the day it was set up. This is where the actual blast radius lives.

Conflating compliance attestations with security. A SOC 2 Type II report is a useful baseline. It is not a guarantee. It tells you the vendor had certain controls in place, tested at points in time, by an auditor who did not look at the specific integration you are using. The Salesloft GitHub compromise was active throughout a period in which Salesloft was almost certainly maintaining its compliance attestations. None of those attestations stopped the breach or detected it.

Outsourcing the entire programme to the GRC team. TPRM that lives only in GRC will never see what an integration is actually doing in production. The programme has to span GRC, security operations, IAM, and SaaS owners. The organisations that detected the Drift activity early — Cloudflare, in particular — did so because their security operations teams owned visibility into SaaS integration behaviour, not because their GRC team had a better questionnaire.

If any of the above is the centre of gravity of your TPRM programme, you are doing the 2018 version of this work in 2026. The shape of the work has to change.

A working TPRM framework for 2026

The framework below is structured around the actual lifecycle of a third-party relationship — from initial assessment through integration, monitoring, and offboarding — with the controls and capabilities that incidents over the past two years have made non-negotiable. It is not a maturity model. Maturity models invite executives to celebrate being at level 3 of 5. The honest version is: you either have these capabilities or you do not, and where you do not, you have an exposure.

Stage 1: Pre-procurement assessment

The questionnaire still goes here. Use SIG or CAIQ if you want a starting baseline; build supplementary questions that target the controls that recent incidents have shown to matter. Specifically:

• Token and credential lifecycle: how does the vendor issue, rotate, and revoke OAuth tokens, API keys, and service account credentials? What is the maximum lifetime of an unrotated credential?
• Source code and CI/CD security: this is the question Salesloft’s customers should have been asking pre-Drift. Who has access to the vendor’s GitHub or equivalent? Is MFA enforced? Are secrets scanned and rotated? Is anomalous repository activity monitored?
• Sub-processor concentration: which of the vendor’s own vendors hold customer data, and what is the vendor’s TPRM posture toward them? This is the fourth-party risk that UpGuard’s Salesloft analysis flagged as systemic.
• Incident notification timelines and channels: not what the contract says. What the operational practice is. How quickly will you actually be told?

Pair this with primary research: the vendor’s incident history, public security advisories, dark web monitoring for leaked credentials linked to the vendor, and where available, BitSight or SecurityScorecard ratings — used as one signal among several, not as the single answer.

Stage 2: Integration design and onboarding

This is the stage that most TPRM programmes skip and that the Salesloft incident makes mandatory. Every integration with a third-party SaaS or cloud service must be designed against three principles:

Least privilege at the OAuth scope level. When a SaaS app requests OAuth scopes during integration, those scopes are the actual access. “Read all Salesforce records” is not the same as “read Account and Contact records only.” Most organisations approve the scopes the vendor requests because the integration will not work otherwise. The right answer is to negotiate scope-by-scope where the vendor allows it, and to disqualify vendors who require all-or-nothing access to data they do not need.

Network constraints where the vendor supports them. IP allow-listing, mTLS, private connectivity. These are not always available, but where they are, they materially reduce the blast radius of a token compromise.

Inventoried, owned, and reviewed. Every integration gets a named human owner inside the organisation. Every integration goes into a SaaS-aware inventory (which typically means an SSPM platform — see the comparison table below). Every integration gets a scheduled review at a frequency proportionate to the data scope.

Stage 3: Continuous monitoring

The annual reassessment is dead. The replacement is continuous monitoring across three layers:

Vendor security posture telemetry. Continuous external monitoring of the vendor’s attack surface, leaked credentials, public incident disclosures, and rating changes. This is the BitSight/SecurityScorecard layer. Useful signal, not a substitute for the other two layers.

Integration behaviour monitoring. What is the OAuth-authorised app actually doing in your tenant? Volume of API calls, types of objects accessed, geographic origin, deviation from baseline. This is where SSPM platforms (AppOmni, Adaptive Shield, Obsidian, Valence) earn their keep. Cloudflare’s investigation into Drift activity in their tenant was driven by this layer of visibility — not by a vendor advisory.

Inbound vendor advisories. A formal process for ingesting vendor breach notifications and trust-portal updates, mapping them to your usage of the vendor, and triggering response playbooks. The Salesloft/Drift timeline showed this matters operationally: Salesforce and Salesloft began revoking Drift tokens on 20 August 2025, but Cloudflare did not receive direct notification until 23 August. Three days, in a credential-harvesting attack, is a long time.

Stage 4: Incident response specifically for third-party events

The IR plan has to assume third-party incidents as a first-class scenario, not a footnote. The operationally distinctive elements:

• A pre-built playbook for “vendor X has disclosed a breach affecting integrations of type Y” — what to revoke, what to rotate, what to scan for, in what order
• A maintained inventory mapping each vendor and integration to its data scope and business owner, so the question “are we exposed?” can be answered in minutes rather than days
• A credential-rotation capability that can move at vendor-breach speed across the secrets that may have been exposed (which typically requires secrets management tooling — see our secrets management comparison for how the major platforms compare)
• A communication tree that includes legal, compliance, the vendor itself, and any downstream customers who may have been affected through your environment

Stage 5: Offboarding

The most overlooked stage. When a vendor relationship ends:

• All OAuth tokens revoked, not just the user accounts deactivated
• All API keys and service account credentials rotated and revoked at source
• All federated trust relationships unwound (SSO connections, SCIM provisioners)
• All data the vendor processed identified, retrieved or attested as deleted, and removed from the vendor’s environment per contract
• The vendor removed from the inventory, the integration removed from the SSPM platform, the rating subscription cancelled

This is unglamorous work and almost no one does it consistently. It is also where dormant integrations become next year’s unauthenticated attack surface.

TPRM platform comparison

The TPRM platform market has consolidated around four broad approaches. None of them does the whole job; most organisations end up combining a TPRM platform with an SSPM and (often) a security ratings service.

The honest recommendation: pick a TPRM platform that handles the assessment and continuous-rating layer (OneTrust if you have other GRC needs; SecurityScorecard, BitSight, or UpGuard if you do not), and pair it with an SSPM platform that gives you visibility into what your OAuth-connected SaaS integrations are actually doing. Trying to do this with a single tool will leave you blind to one of the two layers, and the Salesloft/Drift incident demonstrated which layer matters most in a real attack.

Where this connects to compliance

Third-party risk is now woven into every major regulatory framework that matters. Three connection points worth understanding:

• NIS2 in the EU and UK (where the UK Cyber Security and Resilience Bill mirrors much of it) requires supply chain security as one of the ten Article 21 measures. In-scope organisations have to assess and manage the cybersecurity risks of their direct suppliers. See our NIS2 compliance checklist for how this maps to operational requirements.
• DORA for EU financial services entities goes further: the Register of Information specifically requires firms to maintain detailed records of all ICT third-party arrangements, with TLPT (Threat-Led Penetration Testing) cadences and explicit governance over critical ICT third-party providers. The DORA compliance article covers what supervisors are now finding in early submissions.
• The HIPAA Security Rule update expected in May 2026 will impose new written verification requirements on business associates, making them directly liable in ways the current rule does not.

The convergence point is that regulators are now treating third-party risk as core security risk, not a compliance subdomain. Organisations that maintain a separate TPRM team disconnected from security operations are going to find themselves explaining the same gaps to multiple auditors.

What good looks like in 2026

Strip away the framework and the platforms and the questionnaire taxonomies, and the test for whether a TPRM programme is fit for the current environment is short. A CISO should be able to answer, within an hour, of any given vendor:

• What data does this vendor have access to right now, at what granularity, through what integrations?
• When was the last time anyone reviewed the OAuth scopes that integration holds?
• If this vendor disclosed a breach this morning, what would we revoke, what would we rotate, who would do it, and how long would it take?
• What is the dependency graph — which of our other systems and vendors would also be exposed if this vendor’s tokens were compromised?

Most organisations cannot answer these questions in a week, never mind an hour. That is the gap. The vendors and integrations that compromise organisations in 2026 will be the ones for whom these questions had no answer at the moment they were needed.

The good news: the framework is knowable, the tooling exists, and the regulatory environment is now pushing in the same direction. The bad news is that none of this happens by buying a platform. It happens by treating third-party risk as an active operational programme rather than a procurement gate, and by accepting that the perimeter you actually have to defend is now made of other people’s identities and integrations.

Frequently asked questions

How often should we reassess critical vendors in 2026? Annual reassessment is no longer adequate as the only touchpoint. The right model is continuous monitoring (external posture, integration behaviour, public advisories) with formal reassessment triggered by either time (annually as a backstop) or events (a vendor breach, a material change in the integration, a change in the data scope). Treat the time-based annual review as the floor, not the ceiling.

Is a SOC 2 Type II report enough for vendor security assurance? No. A SOC 2 Type II is a useful baseline that tells you a vendor had certain controls operating during the audit window, evaluated against criteria the vendor selected. It does not validate the controls relevant to your specific integration, it does not detect compromises that the vendor itself has not yet detected, and it dates almost immediately. Use it as one input, not the answer.

What is the difference between TPRM platforms and SSPM platforms? TPRM platforms (OneTrust, Whistic, SecurityScorecard, BitSight, UpGuard) focus on assessing and rating vendors as organisations. SSPM platforms (AppOmni, Adaptive Shield, Obsidian, Valence) focus on the security configuration and runtime behaviour of SaaS applications and their integrations inside your environment. The Salesloft/Drift breach made it clear that you need both — the TPRM layer to assess the vendor, and the SSPM layer to see what the vendor’s integration is actually doing in your tenant.

How do we manage fourth-party risk — our vendors’ vendors? Two parts: first, ask in the questionnaire and require disclosure of material sub-processors. Second, monitor those sub-processors with the same external posture tools you use for direct vendors where they sit in critical paths. Concentration risk — many of your direct vendors depending on the same sub-processor — is the most important fourth-party signal to track. The Salesloft incident affected 700+ organisations because Drift was a common sub-processor across those organisations’ Salesforce environments.

What should we do operationally when a vendor discloses a breach? Have the playbook pre-written. The minimum: revoke OAuth tokens for the vendor’s integration, rotate any credentials the vendor may have had access to, query your audit logs (Salesforce, Workspace, Slack, AWS as relevant) for the disclosed indicators of compromise across the disclosed window, scan the data the vendor held for embedded secrets that may need rotating elsewhere, and assess downstream notification obligations. Cloudflare’s published response to the Drift incident is a useful reference template.

Are vendor security ratings (BitSight, SecurityScorecard) reliable? They are useful directional signals and useful for portfolio-level risk views. They are not reliable as a single source of truth about whether a vendor is secure. The signal-to-noise ratio is worst for vendors that are actively compromised but have not yet been publicly disclosed — which is exactly the moment you most need to know. Treat ratings as one input alongside the questionnaire, the integration-behaviour telemetry, and direct technical due diligence.