Third-party access is driving this week’s breach cascade

At a glance

What this is: This is FireCompass’s weekly security report on five incidents from 10 to 16 August 2026, all of which hinged on third-party or platform access rather than direct compromise of the named victim.

Why it matters: It matters because IAM, PAM, NHI, and supplier governance teams must now treat external systems that process their data or run their software as part of the attack surface, not as adjacent risk.

By the numbers:

• CloudSEK counts more than 2,500 organizations impacted and 434,000 CI/CD pipelines exposed.
• At its 27 July peak, the AnMed attack closed 83 of 106 facilities, or 78 percent.

👉 Read FireCompass’s weekly report on third-party breach cascades and supplier access

Context

Third-party access is no longer a peripheral risk. This week’s incidents show how logistics providers, fulfilment partners, SaaS platforms, and software supply chains can become the route into a victim environment even when the victim’s own perimeter was not the initial target. For identity and security teams, the practical question is who can process your data, ship your products, publish your code, or speak for your organisation when that trust relationship breaks.

The common thread across the reported incidents is governance failure around external dependency visibility, credential scope, and data retention. In an NHI context, that includes service accounts, CI tokens, vendor integrations, and platform credentials that are often owned outside the core enterprise. The starting position in these cases was not unusual, which is exactly why the pattern is dangerous.

Key questions

Q: What breaks when a supplier breach exposes customer or build data?

A: What breaks first is the assumption that external systems are outside your control boundary. Supplier breaches often expose customer records, build pipelines, or delegated access that were never meant to be persistent. Once those paths are compromised, the attacker can pivot into downstream phishing, extortion, or software distribution abuse. The fix is lifecycle control over external identities and data, not reliance on trust alone.

Q: Why do third-party integrations create so much downstream risk?

A: Third-party integrations create risk because they combine access, data, and persistence in one relationship. If a supplier holds customer data, API tokens, or publishing rights for too long, one compromise can affect many brands or many pipelines at once. The risk is not just initial entry, but how much privilege and data the supplier still holds when the attack happens.

Q: How do security teams know if supplier access governance is failing?

A: A governance failure shows up when you cannot answer three questions quickly: who has access, what data they can reach, and when that access expires. If the answer depends on email trails, spreadsheets, or a vendor promise, the control is already weak. Frequent breaches through third parties usually indicate that access reviews are not tied to real data flow and credential lifecycle states.

Q: Which matters more for third-party risk, vendor approval or access scope?

A: Access scope matters more than approval. A vendor can be contractually approved and still hold excessive or stale access through a token, integration, or retained data set. Good governance limits what the external identity can reach, how long it can persist, and how quickly it can be revoked when something changes.

Technical breakdown

How third-party access becomes the initial entry path

Modern breaches increasingly begin in systems that the victim does not fully administer. That includes logistics platforms, fulfilment portals, SaaS CRMs, package registries, and CI/CD tooling. Attackers exploit the trust the business grants to those systems, then move through legitimate integrations or exposed workflows rather than through a noisy perimeter breach. In identity terms, the compromise is often not a password theft from the victim, but an abuse of delegated access, stale credentials, or over-broad supplier permissions. The practical lesson is that external trust must be treated as a governed access layer, not an implicit exception.

Practical implication: Map every supplier identity, token, and integration to a named business owner and access scope.

Why software supply chain compromise reaches production so quickly

Package registries and build pipelines create a multiplication effect. A malicious package or compromised dependency can be pulled into hundreds of CI/CD pipelines within minutes, especially when tokens are unrevoked and dependency verification is weak. Once a build runner executes the payload, the attacker inherits the trust of the pipeline environment, which often has access to source code, secrets, and deployment targets. This is why software supply chain attacks so often become identity incidents as well as code integrity incidents. The problem is not only malicious code, but the identities that are allowed to fetch, build, sign, and publish it.

Practical implication: Require token scoping, dependency pinning, and hash verification in every pipeline that touches production assets.

How data retention and exposure amplify downstream harm

A supplier breach becomes a customer breach when the supplier holds more data, for longer, than the business needs. Order histories, shipping details, contact records, and authentication metadata all increase the blast radius once an external account or platform is compromised. Long retention also extends the attacker’s window for phishing, fraud, coercion, and operational disruption. In identity governance terms, this is a lifecycle failure: the enterprise has no effective control over when third parties should stop holding, using, or exposing customer-linked data. The technical issue is not just access, but persistence of access and persistence of data.

Practical implication: Set contractual retention limits and verify them against actual third-party data stores and export paths.

Threat narrative

Attacker objective: The attacker aims to monetise trust relationships by turning supplier access, software distribution, or public channels into leverage over the victim’s data, operations, or reputation.

1. Entry occurs through a trusted third-party system, such as a logistics platform, fulfilment provider, or CI/CD dependency, rather than through the victim’s own perimeter.
2. Escalation follows when the attacker uses delegated access, compromised tokens, or supplier trust to reach customer data, build systems, or public-facing channels.
3. Impact appears as customer data exposure, supply chain propagation, operational disruption, or extortion pressure directed at the victim’s stakeholders.

Breaches seen in the wild

• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party trust is now an identity governance problem, not just a procurement problem. Every incident in this report depends on some external identity, token, or platform being trusted beyond its intended scope. That means IAM and PAM teams must broaden governance to include supplier-owned access paths, not just employee accounts. The control question is no longer whether the vendor is approved, but whether its access can be named, limited, monitored, and retired.

Blast radius is the decisive concept in modern third-party compromise. Once a supplier or dependency is breached, the number of records, systems, and brands affected depends on how much data and privilege that relationship carries. This is the same logic that drives NHI governance failures inside enterprises, where standing access and long-lived secrets turn a narrow compromise into a broad one. The practitioner conclusion is to reduce what any one external identity can reach.

Supply chain compromise increasingly converges with machine identity abuse. CI tokens, package publishing rights, API keys, and vendor integrations behave like non-human identities even when they sit outside classic IAM workflows. That makes the intersection with OWASP Non-Human Identity Top 10 and MITRE ATT&CK especially relevant, because the attack surface is both technical and governance-driven. The field needs to stop treating machine access as a special case and start governing it as a core identity class.

Named concept: third-party access drift. This is the gap between the access a supplier was originally granted and the access it still effectively holds months later through retention, integrations, and unreviewed tokens. Drift appears when contracts, technical controls, and actual data flows diverge. Practitioners should assume drift unless they can prove lifecycle closure, because that is where exposure persists.

Operational resilience now depends on external visibility. The week’s incidents show that a victim can be operationally hit even when its own perimeter remains technically intact. That makes continuous supplier exposure testing, integration inventory, and credential lifecycle review part of resilience, not optional hardening. The practitioner takeaway is to govern external access with the same discipline used for internal privileged access.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
• From our research: Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For related analysis: 52 NHI Breaches Analysis shows how compromised non-human access repeatedly turns isolated failure into repeated incident patterns.

What this signals

Third-party access drift is likely to become a standard audit concern because external identities now create the same persistence problems as internal NHIs. When a supplier token, fulfilment account, or CI credential outlives the business need that justified it, the enterprise inherits unmanaged exposure. Practitioners should expect external access reviews to become more evidence-driven and more frequent, especially where customer data or release pipelines are involved.

The practical shift is toward continuous verification of supplier-held data, not annual questionnaire comfort. If a partner can process customer records, publish builds, or manage communications, that relationship needs the same lifecycle scrutiny as privileged internal access. For identity teams, the signal is clear: external trust must be enumerated, time-bound, and tested, or it will keep reappearing in incident reports.

For practitioners

• Inventory external identities and delegated access Create a live register of every supplier token, service account, API key, and platform integration that can reach your data or workflows. Assign a business owner, expiry date, and least-privilege scope to each one.
• Shorten third-party data retention windows Contract for retention measured in weeks, not quarters, then verify the actual storage lifecycle in downstream systems, exports, and backups. If the supplier cannot prove deletion, treat the data as continuously exposed.
• Test supplier-facing paths from the attacker’s perspective Validate what an unauthenticated or low-privilege attacker can reach through SaaS tenants, fulfilment portals, and build pipelines. Focus on anonymous access, stale credentials, and unreviewed sharing settings.
• Harden CI and package ingestion controls Pin dependencies, verify hashes, revoke unused CI tokens, and restrict outbound network access from build runners. A single compromised package or token should not be able to fan out into production systems.
• Prepare third-party breach communications in advance Pre-draft customer and regulator notification workflows for supplier incidents so the first public statement is not assembled under pressure. Include brand, legal, and security owners in the approval path.

Key takeaways

• This report shows that the weakest link is often not the victim’s perimeter but the third-party identity already inside the workflow.
• The scale of downstream impact is measurable in brands, records, pipelines, and operational closures, not just in breach headlines.
• Reducing external blast radius requires tighter access scope, shorter retention, and faster revocation of supplier-held credentials and data.

Key terms

• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
• Software Supply Chain Compromise: A software supply chain compromise is an attack that inserts malicious code into trusted build, package, or deployment paths. The goal is often not immediate application failure, but secret theft, persistence, or unauthorized changes that travel downstream through automated systems.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full analysis

FireCompass's full report covers the incident-by-incident operational detail this post intentionally leaves for the source:

• Brand-by-brand disclosure timelines and the exact downstream data fields exposed in each case
• Clarification on which incidents were confirmed by victims versus claimed by attackers
• Additional context on the supplier, fulfilment, and platform pathways that enabled each breach
• The report’s full set of remediation recommendations and incident handling observations

👉 FireCompass’s full report includes the incident timelines, victim disclosures, and attacker claims behind each case

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 external access control to the wider identity programme.