Cloudflare and Salesloft expose why vendor credentials are the real target

At a glance

What this is: Nightfall’s analysis says the Cloudflare and Salesloft incident shows how a third-party compromise can turn into downstream API token exposure across connected SaaS environments.

Why it matters: It matters because IAM, PAM, and NHI teams need visibility into vendor-held credentials, not just vendor assurances, when integrations and shared data flows expand the attack surface.

By the numbers:

• Cloudflare confirmed attackers accessed 104 API tokens through the Salesloft Drift breach.

Context

Supply chain risk becomes an identity problem when third-party compromise exposes credentials that can be reused across cloud and SaaS systems. In this case, the security issue is not only data leakage but the loss of control over API tokens, access keys, and other secrets that authenticate services and integrations.

The article frames the Cloudflare and Salesloft incident as a warning that vendor questionnaires and periodic assurance reviews lag the speed of token exposure and downstream abuse. That is a typical failure mode for modern SaaS estates, where access is distributed across many integrations and no single team has full lifecycle control.

Key questions

Q: What fails when vendor credentials are stored in third-party SaaS systems?

A: The failure is lifecycle control. Once an API token or service account is stored outside the core environment, security teams often lose track of where it is used, who owns it, and how fast it can be revoked. That creates a standing exposure window that attackers can exploit after a vendor breach or integration compromise.

Q: Why do third-party credentials create more breach risk than perimeter controls alone can stop?

A: Third-party credentials can bypass perimeter defenses because they may be accepted as legitimate even when the initial compromise happened elsewhere. That means an attacker does not need to break the outer wall if they can authenticate through a trusted vendor path. Strong vendor access controls, credential oversight, and monitoring of partner activity are critical when trust extends beyond your own network.

Q: How do you know if vendor governance is actually working?

A: You know it is working when every critical vendor has a current inventory entry, a risk tier, an owner, a documented revocation path, and a re-assessment trigger. If access changes, incident reports, or subcontractor changes do not automatically force review, the governance process is not keeping pace with operational reality.

Q: Should organisations treat vendor credential exposure as an IAM issue or a data security issue?

A: Both, but the control point is identity. The exposed asset is a credential, token, or service account that authenticates access to data and systems, so IAM, PAM, and NHI governance must own the response. Data security then limits what the credential can reach if it is abused.

Technical breakdown

How SaaS compromise turns into token exposure

Modern SaaS ecosystems are interconnected through delegated trust, OAuth grants, API tokens, and service accounts. When a vendor platform is compromised, attackers often inherit access paths that were never meant to be customer-facing, then use those paths to enumerate connected tenants, locate secrets, and move into adjacent systems. The critical issue is that the credential itself is the bridge, not the application login. Once a token is exposed, it can often be replayed until revoked, which makes lifecycle control, inventory accuracy, and rapid invalidation the decisive technical controls.

Practical implication: inventory every externally stored token and define revocation procedures that work across all connected SaaS systems.

Why vendor-held secrets outlive the breach window

A token or API key embedded in a third-party system can remain valid long after the compromise is discovered. That creates a standing trust problem: the organisation may know the vendor is affected, but it may not know which credentials were exposed, where they are used, or whether they still have access. This is the same governance gap seen in NHI programmes when secrets are shared across tools without strong ownership, rotation, and offboarding. The attacker wins time because the enterprise cannot quickly map secret ownership to runtime usage.

Practical implication: bind every secret to an owner, a purpose, and a revocation path before it is shared outside the core environment.

Why real-time detection matters more than quarterly review

Quarterly assessments and annual security questionnaires are governance artefacts, not containment mechanisms. They can indicate that a vendor had controls at a point in time, but they cannot stop a compromised integration from exfiltrating credentials today. Effective defence depends on continuous detection of secrets in SaaS content, immediate alerting when sensitive tokens appear in chats, tickets, documents, or code, and automated response when exposure is confirmed. Without that runtime layer, vendor risk management remains largely retrospective.

Practical implication: pair third-party assurance with continuous secrets detection and response across collaboration, code, and support platforms.

Threat narrative

Attacker objective: The attacker objective was to collect reusable credentials and tokens that could enable deeper access into connected enterprise environments.

1. Entry occurred through the Salesloft Drift compromise, which gave attackers a foothold in a third-party SaaS environment connected to customer systems.
2. Credential harvesting followed as attackers sought high-value operational secrets, including AWS access keys, passwords, Snowflake access credentials, and VPN keys.
3. Impact emerged when Cloudflare confirmed that 104 API tokens were accessed, creating downstream exposure across integrated systems and customers.

Breaches seen in the wild

• Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor credential exposure is now the primary supply chain risk, not a secondary consequence. The article shows attackers targeting AWS keys, passwords, Snowflake access credentials, VPN keys, and API tokens because those artefacts convert a vendor compromise into operational access. That shifts the control problem from contract review to credential governance across the full SaaS estate. Practitioners should treat vendor-held secrets as first-class identity assets.

Cloudflare and Salesloft expose a governance gap we can call the third-party secret blind spot. Organisations often know which vendors are approved, but they do not know where credentials are stored, who can replay them, or how quickly they can be revoked. That gap is especially dangerous for NHI programmes because service tokens frequently outlive the business process that created them. Practitioners need secret ownership and runtime visibility, not periodic assurance alone.

Supply chain security and data security now converge at the token layer. When a SaaS integration is breached, the practical question is no longer only whether data moved, but whether credentials that authenticate future access were captured. That means IAM, PAM, and NHI teams have to govern third-party access as a living runtime issue. Practitioners should reframe vendor security around the credentials vendors can touch, not the questionnaires they can answer.

Real-time detection is becoming the dividing line between exposure and containment. The article’s critique of quarterly reviews is accurate because credential exposure in SaaS environments is often instantaneous while remediation is delayed. This creates an operational asymmetry that only continuous monitoring can narrow. Practitioners should assume that compromise disclosure will arrive after token exposure unless they have automated detection and response in place.

OWASP-NHI is the right lens for this pattern because the exposed asset is the non-human credential itself. The compromise is not just a vendor trust issue, it is an NHI lifecycle issue involving secret leakage, overexposed tokens, and delayed offboarding. That is why the governance response has to cover inventory, rotation, and revocation across third-party systems. Practitioners should manage vendor secrets as NHI assets with explicit lifecycle controls.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Third-party credential exposure is now a runtime governance problem. The Cloudflare and Salesloft pattern shows that approval status matters far less than whether a vendor can currently touch active secrets. Organisations that rely on periodic reviews will always be behind the point of compromise, especially where API tokens and service accounts can be replayed immediately.

Secret ownership has to extend across the SaaS estate, not stop at the perimeter. When 92% of organisations expose NHIs to third parties, the control question is no longer whether vendor access exists, but whether every externally shared secret has an owner, a revocation path, and continuous monitoring.

Blast-radius control is becoming the practical standard for SaaS supply chain defence. The next maturity step is not more assurance paperwork, it is constraining what any one vendor-linked credential can reach if it is exposed. That means tighter scope, shorter lifetime, and faster invalidation across the integrations that keep the business running.

For practitioners

• Map vendor-held credentials across all SaaS integrations Identify every API token, service account, and access key stored or used by third parties, then assign an owner and business purpose to each one.
• Shorten exposure windows for externally shared secrets Rotate credentials on a defined schedule and revoke any token that cannot be tied to an active business process or live dependency.
• Instrument continuous secrets detection in collaboration tools Scan Slack, GitHub, Salesforce records, tickets, documents, and AI prompts for exposed keys so leakage is detected before attackers can replay the secret.
• Pre-authorise emergency revocation for vendor compromise Define which teams can disable vendor-linked credentials immediately and which systems must be updated first when a third-party breach is confirmed.

Key takeaways

• The incident shows that third-party compromise often matters because it exposes reusable credentials, not because it leaks static information alone.
• The scale question is whether organisations can inventory, monitor, and revoke vendor-linked secrets before attackers replay them across connected systems.
• The control that changes the outcome is runtime secret governance across IAM, PAM, and NHI scope, backed by continuous detection and emergency revocation.

Key terms

• Vendor-Linked Credential: A vendor-linked credential is an authentication artefact, such as an API token, access key, or service account, that a third party can use to reach your systems or data. The risk is not only possession but replayability, scope, and how quickly the credential can be revoked if the vendor is compromised.
• Third-Party Secret Blind Spot: A third-party secret blind spot is the governance gap where organisations cannot fully see which externally stored credentials exist, where they are used, or who owns them. In practice, this means a breach at one vendor can create downstream access risk long after the initial compromise is detected.
• Runtime Secret Governance: Runtime secret governance is the continuous control of credentials while they are in use, not just when they are issued or reviewed. It combines inventory, monitoring, rotation, and emergency revocation so that exposed tokens cannot remain usable during a vendor incident.
• Blast Radius Control: Blast radius control is the practice of limiting how far damage can spread when an identity, system, or workload is compromised. It uses segmentation, least privilege, isolation, and scoped credentials to contain impact. In identity security, it reduces lateral movement, privilege escalation, and data exposure after a breach or misuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational realities of vendor access and credential exposure.