Supply chain, OAuth and OT failures defined the late September breach wave

At a glance

What this is: FireCompass maps a late-September breach wave that linked ransomware, supplier compromise, OAuth abuse and exploited vulnerabilities across multiple industries.

Why it matters: IAM, PAM and security teams need to see how third-party access, token scope and identity monitoring now shape operational resilience and breach containment.

Context

The common failure mode in this breach wave is not a single malware family or one weak perimeter control. It is the combination of identity trust, supplier access and delayed detection across different operational environments, from SaaS to OT and airport operations. For identity and access teams, that makes OAuth tokens, third-party accounts and service access part of the incident perimeter, not just the authentication layer.

These incidents also show why conventional control boundaries break down when business processes depend on external vendors and delegated access. A compromised token, an exposed supplier account or an unpatched gateway can move quickly from access to outage to disclosure. That is especially relevant for programmes governing human access, machine credentials and third-party integrations together.

Key questions

Q: What breaks when third-party access is not reviewed continuously?

A: The break is that access stays active long after the business relationship, vendor task, or application purpose has changed. Without continuous review, teams rely on outdated certifications that do not reflect live permissions. The result is uncontrolled delegated access, especially across SaaS and OAuth-connected systems.

Q: Why does mishandled OAuth token storage create such high compromise risk?

A: Mishandled tokens create risk because OAuth shifts trust to the SaaS provider handling the token, not just the identity provider. If an attacker can read or steal that token, they can act as the user against connected services without needing a password. That makes one exposed token a direct path into GitHub, Azure, Slack, or other linked accounts.

Q: What do security teams get wrong about supplier access?

A: Teams often assume supplier access is temporary or low risk, then fail to review it with the same discipline as internal access. That is a mistake because third-party accounts, shared systems, and lingering permissions create hidden attack paths. Supplier access should be treated as a governed identity lifecycle, not an exception.

Q: Should organisations prioritise token revocation or endpoint hardening first?

A: If the report’s patterns are your concern, token revocation should come first where SaaS persistence or secret theft is active, because those paths preserve attacker access immediately. Endpoint hardening still matters, but it will not contain a live OAuth compromise or a reused developer secret. The right sequence depends on where trust is already exposed.

Technical breakdown

How OAuth token theft turns delegated access into bulk data export

OAuth delegation lets an application act on a user's behalf without sharing the user's password, but that convenience creates a high-value trust boundary. If an attacker steals an OAuth token, they inherit whatever API scope and session persistence the token carries until revocation or expiry. In the Stellantis case, the article describes token theft followed by API calls and bulk export, which is a classic delegated-access abuse pattern. The key technical risk is not authentication failure at login, but overbroad scope plus weak monitoring of token use after issuance.

Practical implication: treat token scope, lifetime and revocation as control points, not just login security.

Why third-party access expands the breach surface across supply chains

Third-party compromise is an access-control problem as much as it is a vendor-risk problem. When a supplier holds privileged connectivity to customer systems or operational platforms, the supplier's compromise becomes a direct path into downstream data and workflows. The Harrods incident in the article shows that an external data processor can become the entry point for record exposure even when the primary brand is not directly breached. Identity governance has to track which external identities can reach which data sets, for how long, and under what offboarding conditions.

Practical implication: inventory and periodically review every external identity with production or customer-data access.

How exploitation chains combine phishing, gateway flaws and lateral movement

The Collins Aerospace incident shows a multi-stage chain that started with spear-phishing and then used an unpatched API gateway vulnerability to escalate privileges before ransomware encryption. That sequence matters because no single control failure explains the impact. Initial access came from human deception, privilege growth came from a technical exposure, and impact came from encrypted systems plus lateral movement through compromised credentials. For defenders, this is a reminder that identity, application exposure and endpoint response must be correlated, not managed in isolation.

Practical implication: map phishing, exploitable gateways and credential reuse into one detection and response workflow.

Threat narrative

Attacker objective: Attacker objectives varied by incident, but they consistently sought either service disruption, data exfiltration or both through abused access paths.

1. Entry began with spear-phishing, vishing or compromise of third-party trust paths, depending on the incident described in the article.
2. Credential or session abuse then enabled API access, privilege escalation or supplier system reach that attackers could use without repeated login challenges.
3. Attackers either encrypted systems, exfiltrated customer data or disrupted production and airport operations once they had durable access.
4. The objective was operational disruption, data theft or both, with downstream recovery delayed by limited detection and external dependency chains.

Breaches seen in the wild

• New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party access is now part of the identity perimeter: When suppliers, integrations and delegated applications can reach production data, the attack surface extends beyond employee IAM. This article shows that breach containment depends on tracking external identities, not only internal users. Practitioners should govern supplier access with the same lifecycle discipline they apply to privileged human accounts.

OAuth abuse exposes a verification gap, not just a token problem: Token theft matters because once a session token is valid, many controls no longer see a traditional authentication event. That creates a trust gap between issued access and observed behaviour, especially for SaaS and CRM platforms. Practitioners should treat post-issuance token behaviour as a first-class governance problem.

Blast-radius control is the real resilience metric: The incidents here differ, but the outcome is similar: one weak trust path can become outage, exfiltration or both. That means security programmes should measure how fast access can be revoked, not just how quickly alerts fire. Practitioners should focus on reducing how far compromised access can travel.

Delegated access needs continuous ownership, not periodic audit: External processors, integration accounts and OAuth grants often survive longer than the business process they were created for. That persistence creates hidden governance debt, especially where offboarding is manual. Practitioners should make revocation and expiry as visible as initial approval.

Operational technology failures and SaaS compromises now share a control pattern: The article connects OT disruption, CRM theft and supplier exposure through the same governance weakness, namely trust in access that outlives its intended context. This is a useful reminder that identity and access policy has to span both business systems and operational environments. Practitioners should align IAM, PAM and third-party governance around shared access boundaries.

What this signals

Delegated access is becoming a governance perimeter: Security teams should assume that OAuth grants, supplier accounts and integration users can outlive the business process they were meant to support. The practical challenge is no longer just issuance, but continuous ownership, revocation and telemetry around how that access is used.

Identity controls now define incident blast radius: The same access path that enables business integration can also accelerate exfiltration, outage or OT disruption if scope is too broad. Programmes that still separate IAM, PAM and third-party risk will miss how quickly one trust relationship can become a cross-domain incident.

Access reviews are not enough when session tokens and APIs are in play: Reviews tell you who should have access, but they often miss whether a token is still live and whether its behaviour matches the business purpose. Practitioners need runtime visibility into delegated access, not just periodic attestation.

For practitioners

• Tighten OAuth token governance Limit token scope to the minimum API actions required, shorten lifetime where possible and maintain rapid revocation procedures for compromised sessions.
• Review third-party identity access Inventory supplier accounts, integration users and delegated application grants that can reach customer or production systems, then assign explicit owners and expiry dates.
• Correlate identity and API telemetry Watch for unusual API access patterns, off-hours exports, new geo-locations and repeated consent grants that suggest token abuse or delegated access misuse.
• Segment operational and business systems Separate OT, order management and customer-data environments so a compromise in one trust zone does not automatically extend into the others.
• Strengthen breach notification and isolation playbooks Test how quickly legal, security and operations teams can contain supplier-driven incidents, preserve evidence and meet notification obligations when access abuse is confirmed.

Key takeaways

• This breach wave was less about one exploit than about multiple trust paths failing at once, from delegated SaaS access to supplier connectivity and OT exposure.
• The incidents show that token scope, third-party ownership and revocation speed can shape impact as much as malware or vulnerability severity.
• Practitioners should treat external identities, API grants and operational dependencies as part of the same control surface.

Key terms

• 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.
• Token abuse: Misuse of a valid session or access token after an attacker has obtained it. The key risk is that the attacker acts as an authenticated user or workload without needing to break the password layer again.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• 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.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps practitioners connect identity lifecycle control to the broader security programme they already run.