Third-Party Breach
A third-party breach occurs when an attacker compromises a vendor, supplier, or service provider and uses that access to reach the vendor's customers or downstream partners. The entry point is shared integrations, credentials, or software. The breached organization is not the primary target. It is the pathway. The downstream organizations bear the data loss, operational disruption, and regulatory liability without having been directly attacked.
How does a third-party breach happen?
Third-party breaches follow a consistent attack architecture. The attacker identifies a vendor with weaker security controls that has meaningful access to multiple downstream organizations. Breaching the vendor once creates access to many.
The mechanism varies. In the SolarWinds breach, attackers compromised the vendor's software build process and inserted malicious code into a legitimate product update that downstream customers then installed. In the MOVEit breach, attackers exploited a previously unknown vulnerability in a vendor's software before patches existed. In credential-based attacks, leaked or phished vendor employee credentials provide direct access to systems the vendor manages on behalf of its customers.
What these paths share is that the downstream organization's own defenses are largely irrelevant. The attack arrives via a trusted channel: a software update, a managed service login, an API connection. These are expected and permitted. The security controls the organization built to keep attackers out did not account for the trusted vendor who was already inside.
How is a third-party breach different from a direct cyberattack?
In a direct attack, the attacker targets the organization itself: phishing its employees, probing its public-facing infrastructure, or exploiting vulnerabilities in its own systems. The affected organization is both the target and the victim.
In a third-party breach, the attacker targets a vendor. The downstream organization becomes a victim without being a target. This distinction has significant implications for detection and response.
Detection is harder because the intrusion arrives via a trusted source. The vendor's software is already on the organization's systems. The vendor's credentials are already authorized. There is no obvious anomaly to detect at the point of entry. Black Kite research has shown that organizations often learn of a third-party breach when the vendor discloses it or when they see it in the news. They do not discover it through their own detection systems. Understanding which vendors carry elevated ransomware susceptibility or observable compromise indicators is how downstream organizations get ahead of the breach rather than react after the fact.
What are the most significant third-party breaches in recent history?
Three breaches define the current understanding of third-party risk at scale.
- SolarWinds (2020). Attackers inserted malicious code (later named SUNBURST) into a software update for the Orion IT monitoring platform. The update was distributed to approximately 18,000 customers, including U.S. government agencies, defense contractors, and Fortune 500 companies. The attackers had access to those environments for months before detection.
- MOVEit (2023). The Clop ransomware group exploited a zero-day SQL injection vulnerability in Progress Software's MOVEit file transfer tool. Hundreds of organizations had data exfiltrated, including government agencies, financial institutions, healthcare organizations, and major retailers. Many learned of the breach through media reports rather than direct notification.
- Okta (2023). Attackers accessed Okta's customer support system and obtained files containing authentication tokens for Okta's enterprise customers. Organizations that relied on Okta for identity management were exposed through a vendor they had specifically chosen for security purposes.
These are not outliers. They are the clearest examples of a pattern that repeats regularly at smaller scale across industries.
What is the downstream impact of a third-party breach?
Black Kite research found that a single breached vendor creates downstream exposure for an average of 5.28 victim organizations. At enterprise scale, where a single vendor may serve hundreds or thousands of customers, the multiplier effect is the defining characteristic of third-party breaches. A compromise that affects one vendor can simultaneously affect dozens or hundreds of the vendor's customers. Each of those customers faces data exposure, operational disruption, regulatory notification requirements, and potential cascading risk to their own customers.
For the downstream organization, the impact does not differ materially from a direct attack. Regulated data that was accessible through the vendor is treated as compromised data for notification purposes. Operational systems that were disrupted require the same incident response. The legal and reputational consequences are identical.
What differs is the starting point for response. The organization cannot patch the vendor's vulnerability. It cannot revoke credentials the vendor issued. Its primary levers are how quickly it was aware of the vendor's compromise, what data the vendor could actually access, and whether it had a documented response plan for this scenario.
How do organizations detect and respond to third-party breaches?
Early detection depends on continuous monitoring of the vendor ecosystem, not periodic reviews. An organization that monitors its vendors' external risk posture continuously can see warning signals before a breach is confirmed or disclosed. New vulnerabilities, credential exposure, and darkweb indicators all appear before most vendors issue a formal notification. Threat actor monitoring tools identify when specific threat groups are targeting vendors in your ecosystem, enabling proactive outreach and risk reduction before an incident occurs.
When a breach occurs, response requires knowing exactly what the vendor had access to. Not just which systems, but which data sets, which credentials, and which integrations. Organizations with mature vendor inventory and tiering programs can answer these questions quickly. Organizations without them spend the first hours of an incident trying to establish the basic facts of their own exposure.
Documented vendor breach response workflows reduce response time and limit the window during which the attacker can move. These workflows define what to demand from the vendor, what notifications to prepare, and what containment steps to take.