Recent 3 Third-Party Cyber Incidents and What CISOs Should Learn


- Three third-party cyber incidents landed on CISOs between September 3 and September 8, 2026, at Thomson Reuters, Trezor, and Veradigm. Two were first disclosures. One was a scope revision that grew the victim count almost six times.
- Each one used a different path into the enterprise: a stolen vendor credential, data that was never deleted, and a shared platform sitting inside hundreds of downstream environments.
- Verizon now puts third-party involvement at 48% of breaches, up 60% year over year [verizon.com].
- The number that matters in all three is the silent window: the days between a provider knowing it has a problem and the market of its customers being able to act. Thomson Reuters knew for 65 days before it went public.
- Questionnaires and ratings describe a vendor. Neither tells you a vendor is being attacked right now.
Third-party cyber risk is not theoretical. Between September 3 and September 8, 2026, three disclosures showed how quickly a trusted vendor, service provider, or technology platform becomes the path to enterprise exposure. Each one is a third-party data breach in the strict sense. The attacker never touched the affected organization's own network.
Veradigm disclosed that credentials compromised at a third-party vendor were used to access patient data through a legitimate API. Trezor revealed that customer information remained in a fulfillment provider's systems despite written assurances that it had been deleted. Separately, an incident involving Thomson Reuters' C-Track platform exposed information tied to court systems across the United States and Canada.
The incidents are different. The lesson is the same. Your security posture now depends on conditions you do not directly control.
This is why third-party cyber risk management can no longer stop at questionnaires, security ratings, contracts, and periodic assessments. Security teams need to know what is happening across the ecosystem while it is happening.
What are some recent top third-party cyber incidents?
Three third-party cyber incidents disclosed between September 3 and September 8, 2026, stand out for enterprise security leaders:
- Veradigm. Compromised vendor credentials were used to access patient personal information through an authorized API.
- Trezor and ShipMonk. A fulfillment provider retained historical customer data that Trezor says should have been deleted, and the affected population grew almost six times.
- Thomson Reuters C-Track. Unauthorized access to a widely used court management platform affected courts in at least a dozen US states, the US Virgin Islands, and Ontario.
Each represents a different third-party attack path.
1. Veradigm and the vendor credential that became a possible attack path
On September 8, Veradigm disclosed in a Form 8-K filing [sec.gov] that one of its third-party vendors experienced a cybersecurity incident.
An unauthorized party obtained credentials from that vendor's environment for a Veradigm application programming interface used for customer services. The attacker used those legitimate credentials to access the environment and download patient personal information, including Social Security numbers in some cases. Veradigm said no clinical or medical information was involved, and that the credentials did not reach its broader network, servers, or databases.
Three days before that filing, a ransomware group had already listed Veradigm on its leak site and claimed roughly 3.5 million patient records [hipaajournal.com]. Veradigm has not confirmed that figure or attributed the attack.
Why the Veradigm incident matters
The attacker never had to breach Veradigm's core infrastructure. They took a credential from a trusted third party and walked an access path that already existed.
Enterprises now hand vendors, SaaS applications, managed service providers, and partners authenticated access to APIs, data, identities, and cloud environments. Those relationships extend the attack surface past the enterprise boundary, which is why compromised APIs behave like supply chain threats [icounter.com].
The security question is no longer whether your API is secure. It is who outside your organization holds credentials to it, what those credentials reach, and whether anyone would notice that access behaving abnormally.
A vendor can pass an assessment and be compromised months later. That gap between vendor assurance and operating reality is where this incident lives.
Healthcare carries this risk through a specific channel. Verizon puts third-party involvement at 32% of confirmed healthcare breaches [verizon.com]. Analysis of federal breach reporting shows 35.8% of 2025 US healthcare breaches originated at a business associate [hipaajournal.com] instead of at the provider. More than a third of the sector's breaches begin at a vendor, which is what the Veradigm disclosure looks like in aggregate.
2. Trezor and ShipMonk when deleted data was never deleted
The Trezor incident exposes the gap between contractual assurance and actual operating conditions.
Attackers compromised fulfillment provider ShipMonk and accessed Trezor customer data held by that third party. ShipMonk notified Trezor on August 10, and Trezor disclosed three days later. At that point the incident covered 13,689 customers.
Then the scope widened. On September 4, Trezor disclosed that the breach also reached historical order data from its prior relationship with ShipMonk between November 2019 and August 2021. That added exactly 67,000 US customers and brought the total to 80,689, nearly six times the original figure, 25 days after Trezor first learned of the incident.
Trezor had repeatedly requested, and received, written confirmation that this data was deleted under its contractual requirements and retention policies. In its own disclosure, Trezor states that it "repeatedly requested and received written assurance confirming the deletion of the data," and that "despite receiving this confirmation, the data was not deleted in their systems."
It had not been.
Why the Trezor and ShipMonk incident matters
A written confirmation is evidence of an assurance process. It is not evidence of a condition.
Traditional vendor risk programs run on artifacts: questionnaires, certifications, data-processing agreements, security attestations, and deletion confirmations.
Those artifacts remain important.
An attacker does not read them. An attacker works with what is actually there.
Data deletion is a named control, not a courtesy. ISO/IEC 27001:2022 Control 8.10 covers information deletion and NIST Special Publication 800-88 Revision 2 [csrc.nist.gov] defines what sanitized means. Neither standard verifies itself.
So the operational question is this. How many former vendors, processors, and partners still hold your data, credentials, backups, or access paths long after the business considers the relationship closed?
Offboarding a vendor in procurement does not remove it from your attack surface. Your third-party risk program is running on a clock that already ran out [icounter.com] when the only evidence of closure is a signed confirmation.
3. Thomson Reuters C-Track and the concentration risk problem
The third incident demonstrates concentration risk.
C-Track, operated by West Publishing, a Thomson Reuters unit, provides court management technology used by judicial systems across North America.
Thomson Reuters discovered unauthorized activity on June 30 and determined that an unauthorized party held access to C-Track storage from March 1 through June 29, 2026. That access window closed the day before anyone noticed it. The company disclosed publicly on September 3 and stated the incident took place inside its own cloud environment, not in court systems.
The affected information spans court systems in at least a dozen US states, the US Virgin Islands, and Ontario, Canada. No single notice listed every jurisdiction. The roster was assembled from individual court disclosures and has kept growing, which means the full scope is still not public. Exposed data included names alongside Social Security numbers, driver's license numbers, dates of birth, medical information, and health insurance information. The notification also warns that confidential, redacted, or sealed court information may have been affected at some courts.
Why the C-Track incident matters
Enterprises do not operate as isolated networks.
One technology provider sits inside the operating environment of hundreds of customers.
One SaaS provider can support multiple business units.
One MSP can administer hundreds of environments.
One identity provider becomes a critical dependency.
One supplier connects numerous companies to the same upstream risk.
C-Track is that shape exactly. A single case management platform serving court systems in at least a dozen US states, the US Virgin Islands, and Ontario, and every one of them inherits its security decisions.
The Identity Theft Resource Center measured this directly. In the first half of 2026, supply chain attacks produced 280.6 million victim notices from just 38 initial breach events [idtheftcenter.org], reaching 206 total entities. That is roughly five affected organizations for every initial breach event.
A compromise at one highly connected provider creates a blast radius across many organizations at once.
That is why CISOs need visibility into live and active third-party breaches. A spreadsheet of vendor assessments cannot show that in real time, and an A rating will not tell you a vendor is being targeted.
What do these three third-party incidents have in common?
At first glance, Veradigm, Trezor, and C-Track share very little. Read through an operational risk lens, one pattern holds across all three.
Veradigm. A legitimate third-party credential became the attack path.
Trezor. Vendor assurances did not reflect the actual state of customer data.
C-Track. A shared technology dependency created downstream exposure across many organizations.
Knowing whether a vendor has controls is not the same as knowing whether that vendor represents third-party cyber risk right now. Questionnaires describe what a company says about its security program, ratings describe observable posture, and contracts establish obligations. None of them tells a security team that a vendor credential was just compromised or that an adversary is moving against a connected provider.
Verizon found that only 23% of third-party organizations fully remediated missing or improperly secured MFA [verizon.com] on cloud accounts, and that weak passwords and permission misconfigurations took close to eight months to reach 50% resolution. A vendor reviewed quarterly can therefore carry an unfixed control gap through two consecutive reviews.
The silent window is the metric your program is missing
The silent window is the gap between the moment a provider knows it has been compromised and the moment the wider market of its customers can act on that knowledge. All three of this week's incidents have one, and each is calculable from primary disclosures.
Read the third row carefully. For Veradigm the earliest public signal was the extortion listing, not the company. Anyone watching leak-site activity knew three days before the market did.
Nobody publishes this number for you. You can compute it for every vendor in your portfolio from public disclosures, and the distribution tells you how long your organization typically operates blind after a supplier is breached. That distribution is a third-party cyber risk measurement you own outright, built from public filings instead of vendor self-reporting.
The macro data points the same way. IBM ranks supply chain compromise among the slowest breach types to resolve, at 258 days to identify and contain, against a 247-day average [hipaajournal.com] across all breach types. Containment takes the same 64 days either way, so the whole gap sits in detection.
Meanwhile, only 33% of organizations comprehensively map their supply chain ecosystems [weforum.org], according to the World Economic Forum, which describes supply chain risk management as something treated as a compliance checklist instead of a continuous process.
What should CISOs do about third-party cyber risk now?
Security leaders do not need to abandon existing third-party risk management programs. They need to add an operational layer on top. Start with five questions.
Do we know our actual ecosystem?
Do we understand access, not just vendor names?
Can we identify concentration risk?
Are we detecting change between assessments?
Can we turn intelligence into action?
CISO concern is already moving this direction. The World Economic Forum found that 65% of large companies by revenue name third-party and supply chain vulnerabilities as their greatest challenge, up from 54% [weforum.org] the year before. For teams starting from scratch, a practical plan for rebuilding third-party risk [icounter.com] covers the first 90 days.
Third-party risk management must become operational
The enterprise perimeter has expanded into an ecosystem of vendors, SaaS providers, suppliers, managed service providers, partners, identities, and infrastructure. Security programs have to expand with it.
iCOUNTER's Counter Threat Operating System, CTOS [icounter.com], adds that operational layer to existing third-party cyber risk programs. CTOS maps the enterprise ecosystem, collects signals tied to third-party relationships, determines which represent real risk to your organization, and routes validated Compromise Intelligence into security and risk workflows.
The goal is not another dashboard of vendor alerts. It is to determine risk at the point of collection, then give defenders the context to act.
The next third-party incident begins outside your network. It still becomes your incident. Ecosystem risk is enterprise risk.



.avif)