The breach that never touched you

Financial institutions are increasingly compromised without being touched. The attacker walks in through a shared software update, a common SaaS platform, or a dependency four layers deep in the stack - and lands inside dozens of banks at once. Third-party risk has quietly become systemic risk, and the frameworks built to manage it were designed for a slower, more contained threat.

There is a category of incident now common enough to name: the breach an institution suffers without being attacked.

No phishing email landed in its inbox. No credential of its was stolen. No perimeter of its was tested. And yet its customer data is on a leak site, its operations are disrupted, and its regulator wants answers. The intrusion happened somewhere else entirely — inside a software vendor, a managed service provider, or an open-source package the institution never knew it depended on.

This is the structural shift third-party risk has undergone. The question is no longer whether a supplier is trustworthy. It is how many institutions that supplier can take down at once.

The mechanism: from one supplier to sector-wide

The reason a single supplier compromise now scales is that the modern BFSI stack is built on shared components, not private ones. The same handful of software vendors, SaaS platforms, and service providers sit behind large numbers of institutions simultaneously. When an attacker compromises one of them, the trust that institution extended to its provider becomes the attacker's access to every other institution behind that same provider.

Four vectors carry it:

• Compromised software updates: A signed, trusted update ships malicious code into every environment that installs it.

• Malicious open-source packages: Poisoned dependencies enter production through ordinary development workflows.

• CI/CD pipeline compromise: The build system itself is subverted, so the product is malicious before it ever ships.

• MSP lateral movement: A managed service provider's privileged access into many client environments becomes a single pivot point into all of them.

The evidence in the field is unambiguous. In 2025, a single vendor breach produced confirmed impact across more than 70 US banks and credit unions, exposing over a million customer records. In April 2026, two major US banks appeared simultaneously on a ransomware leak site after a shared vendor was compromised. Neither pattern is an outlier anymore; it is the shape the threat now takes.

What changed on the attacker's side

Three shifts explain why this became the dominant play.

• First, attackers stopped attacking the strong directly. Well-defended institutions are expensive to breach. A trusted provider with sector-wide reach is a far more efficient target - compromise it once, inherit its access everywhere.

• Second, the encryption stage is being abandoned. Many groups have dropped ransomware's lock-and-decrypt model in favour of pure data exfiltration and extortion. It is faster, harder to detect, and just as coercive - the threat to publish is leverage enough.

• Third, the impact is now concurrent, not sequential. One vendor compromise produces damage across many institutions at the same moment. Incident response can no longer assume it is dealing with an isolated event.

Why current third-party risk management doesn't hold

The discipline of managing suppliers was built for a slower world, and three assumptions inside it have quietly broken.

1. Due diligence is a point-in-time snapshot; the risk is continuous. A vendor assessment describes a supplier on the day it was completed. But the API perimeter that connects you to that vendor changes far more often than the vendor inventory does. The gap between "we assessed them last year" and "their exposure today" is exactly where these incidents live.

2. Visibility stops at the direct vendor; the risk lives deeper. Institutions can usually name their vendors. Very few can name their vendors' vendors. Transitive dependency - your exposure through the suppliers of your suppliers, is structurally invisible at the direct-vendor level, and it is precisely where poisoned packages and downstream compromises originate.

3. Attestation proves a control existed; it doesn't prove it held. Cloud service provider attestation covers the provider's side of the shared-responsibility line. It says nothing about tenant-side IAM drift, OAuth scope sprawl, or the inter-service trust relationships that let a compromise in one SaaS platform chain into the next. The control passed its audit. The attacker operated outside the audit's boundary.

What to do about it

The response is not more vendor questionnaires. It is a shift from periodic, inventory-based assurance to continuous, exposure-based assurance, and an acceptance that a supplier's incident is now your incident.

For third-party risk and procurement teams:

• Require software supply chain attestation - SBOMs, provenance verification, and runtime integrity checks, as a complement to, not a substitute for, vendor due diligence.

• Treat the third-party API perimeter as a continuously monitored surface, separate from the periodic vendor review cycle, because it changes far more frequently.

• Extend risk assessment to transitive dependencies - the exposure carried through your vendors' vendors.

For CISOs and security operations:

• Build incident response plans that explicitly contemplate simultaneous, multi-institution compromise through a shared provider. Assume you will not be the only victim, and that the vendor may be slow to confirm.

• Add runtime integrity attestation for software entering production, so a subverted build is caught at deployment rather than after exfiltration.

• Treat concurrent appearance on a leak site as a supply chain signal, not a coincidence.

For regulators and supervisory authorities:

• Establish cross-institutional information-sharing protocols for supply chain compromise indicators, modelled on the fraud-signal sharing already mature in payment networks.

• Set supervisory expectations for transitive dependency risk across cloud, identity, and SaaS supply chains.

• Align incident-reporting cadence with the compressed, concurrent timelines that shared-vendor compromise produces.

The reframe

For decades, third-party risk was a procurement conversation about whether to trust a given supplier. That framing no longer describes the actual exposure. The real question is one of concentration and blast radius: how many institutions sit behind the same provider, how deep the dependencies run, and how fast a single compromise can propagate across all of them.

Shared infrastructure is what makes the modern financial system efficient. It is also what makes a single supplier's bad day a sector-wide event. Managing that is no longer about vetting vendors one at a time. It is about seeing the whole web of dependencies as shared exposure, and assuring it continuously, because the attackers already treat it as one target.