One supplier incident in this period reached courts in eleven US states, the US Virgin Islands and Canada. Another reached more than 1,000 charities. A third disrupted eight warehouses and exposed shipment data belonging to a games company and several retailers.
None of those organizations were breached in the conventional sense. They were connected to something that was. Of the 27 material incidents disclosed between 1 August and 12 September 2026, eight arrived through a third party, making it the single largest identifiable category in the register after identity.
Contents
- What third-party intrusion looked like in this period
- Case 1: one court platform, dozens of courts
- Case 2: one CRM, a thousand charities
- Case 3: logistics disruption that travelled to customers
- The incidents that arrived through external applications
- Why questionnaires do not catch this
- The concentration problem nobody prices
- What controls a supplier connection
- A practical checklist
- What to ask a supplier after an incident
- Frequently asked questions
Key Takeaways
- Eight of 27 incidents in the window reached victims through a supplier, shared platform, data centre or external application.
- A single court case management product exposed records across multiple US states, the US Virgin Islands and Canada, including potentially sealed information.
- Supplier incidents multiply: one provider's compromise becomes dozens or thousands of downstream disclosures.
- Annual assessments measure a supplier's paperwork, not the live connection between their systems and yours.
- The only durable control is at the connection itself: inspected, governed and revocable in seconds.
What third-party intrusion looked like in this period
The eight third-party incidents took several shapes: an upstream compromise of a cloud analytics instance, unauthorized file access at a commercial data centre, a widely used health platform, a flaw in external software used by a hospital, external applications at a healthcare distributor, attacker claims against large manufacturers tied to enterprise file systems, and a court case management platform.
What unites them is that the victim organization did nothing wrong at the moment of intrusion. Their exposure came from a connection they had authorized, to a system they did not control, holding data they were responsible for.
Case 1: one court platform, dozens of courts
Thomson Reuters disclosed that an unauthorized party obtained files from C-Track, the court case management platform sold by its West Publishing unit. Reporting on the disclosure described affected courts across multiple US states, the US Virgin Islands and Ontario, with records that could include personal information and, for some courts, confidential, redacted or sealed material. Further coverage noted the gap between the start of unauthorized access and public disclosure.
Consider what each individual court could have done differently. They procured a mainstream product from a major vendor. Their own networks were not the entry path. Yet the sensitive records were theirs, and so was the notification duty.
Key Insight
When a supplier is compromised, the breach is theirs but the exposure is yours. Courts, charities and hospitals in this register inherited incidents they had no way to detect from inside their own perimeter.
Case 2: one CRM, a thousand charities
A CRM provider used by charities disclosed that a compromised Amazon Web Services access key exposed database backups. More than 1,000 charities were potentially affected, with contact and donor data involved.
Charities are a useful stress test for third-party risk practice. Most have no security team, no leverage over a supplier's engineering decisions and no realistic ability to audit cloud key management. They chose a specialist supplier precisely because it was more capable than they were. The concentration that made the supplier efficient also made it a single point of failure.
Case 3: logistics disruption that travelled to customers
A logistics provider disclosed unauthorized access affecting European warehouse systems over several days. Eight warehouses were disrupted, shipping was delayed, and shipment and customer contact data belonging to its clients was exposed.
This case shows the second form of third-party damage. Data exposure is one outcome. Operational dependency is the other: when a supplier stops functioning, your orders stop moving, and no amount of internal security prevents it.
Case 4: the incidents that arrived through external applications
Two further cases in the window show a quieter version of the same problem. A healthcare distributor disclosed unauthorized access to external applications, with an attacker group claiming a very large volume of patient records, a claim that remained unverified. A hospital disclosed that a flaw in external software exposed employee and applicant information, while patient records, clinical systems and care were unaffected.
The second is instructive because the containment was real: the exposure stopped at the boundary of the affected application. That is what good segmentation looks like from the outside, and it is the difference between an incident and a crisis.
Why questionnaires do not catch this
Most third-party risk programs run on assessments: a questionnaire at onboarding, a certification on file, an annual review. Set against this register, the limits are obvious.
The mismatch is consistent across every measure. Third-party programs check policy documents and certifications, while the incidents in this window involved a compromised cloud access key. They rely on an annual point-in-time review, while the access in these cases ran for months between reviews. They assess the supplier's stated controls, while the actual exposure came from the supplier's upstream provider. They confirm whether an incident process exists on paper, while what mattered was how fast the connection could actually be cut. And they check data categories listed in a contract, while what was exposed was sealed court records inside a shared platform.
An assessment describes intent at a moment. The connection operates continuously, changes without notice and is where the damage happens.
The concentration problem nobody prices
Every efficiency argument for shared platforms is also a concentration argument. One CRM for a sector, one case management product across many courts, one identity verification provider behind many businesses. When these are compromised, the blast radius is the customer list.
Procurement rarely prices this. A supplier with 5,000 customers is usually treated as safer than a small one, and often is, right up to the point where its compromise becomes 5,000 simultaneous disclosures.
Key Insight
Diversifying suppliers is usually impractical. Governing the connection is not. If you cannot reduce concentration, reduce what each connection is allowed to do.
What controls a supplier connection
Three capabilities make supplier risk manageable in practice:
- Visibility of every connection. Not a list of vendors, a live view of which external systems are connected to which internal ones, and what data moves across each.
- Least privilege per connection. A supplier integration should reach one dataset for one purpose, not a general-purpose credential into the environment.
- Revocation in seconds. When a supplier discloses an incident, the question is how fast you can cut and re-establish that connection without stopping the business.
This is the case for a gateway, and it is why zero trust built around human users leaves supplier and machine traffic under-governed. Conux sits in the path of every connection, including supplier and partner traffic, governs the machine identities behind those integrations, applies quantum-safe encryption to each session, and lets five agents detect, block, harden and log without waiting for a human. Because it sits in front of existing cloud, identity and applications, supplier connections do not need rebuilding to be governed, and the same gateway carries the machine-identity controls described in non-human identity. The wider argument is in our piece on choosing a cybersecurity company for the AI and post-quantum era.
A practical checklist
- Inventory live integrations, not just vendors. Include data flows, credentials and permissions for each.
- Rank suppliers by blast radius: what an attacker reaches through that connection, not the contract value.
- Require evidence of MFA and key management from suppliers holding your data.
- Define a revocation runbook per critical supplier and rehearse it.
- Include a notification clause with hours, not "promptly", and ask for the disclosure gap in their last incident.
- Monitor supplier connections continuously for volume, timing and destination changes.
What to ask a supplier after an incident
When a provider discloses, the standard notification tells you little. Four questions produce answers you can act on: when did unauthorized access begin, as distinct from when it was detected and disclosed; which of our datasets were reachable from the compromised component; which credentials, keys or tokens shared with you were in scope; and what has changed in your environment since. The gap between the first and third answers is usually where your own exposure sits.
Ask the same questions before signing, in the form of a scenario: if this happened, what would you tell us and how quickly. A supplier that cannot answer in the sales cycle will not answer faster during an incident.
To map your supplier connections and what each one can reach, talk to our team.
