By NHI Mgmt Group Editorial TeamBased on Oak: “One Phone Call. 148 Systems. £29 Million.” (October 12, 2026)

TL;DR: Scattered Spider used a help-desk impersonation and stolen account to reach 148 Transport for London systems, leading to £29 million in losses and sixteen hours of escalation, according to Oak. The real control failure is not authentication alone but unchecked identity reach, because standing privilege turns one reset into enterprise-wide impact.


At a glance

What this is: This is an analysis of the Transport for London attack in which a help-desk reset and impersonation gave Scattered Spider access that expanded to 148 systems and £29 million in damage.

Why it matters: It matters because IAM and IGA teams need to govern effective permissions, inherited access, and help-desk recovery paths, not just authentication events.

By the numbers:

  • Two members of Scattered Spider were sentenced in July 2026 for the 2024 Transport for London attack.
  • The attack reached 148 systems and caused roughly £29 million in losses.

Context

Transport for London suffered a help-desk impersonation attack in 2024 that turned one account reset into access across 148 systems. The article frames the event as an identity governance failure, not a login failure, because the attack succeeded through recovery processes, inherited permissions, and standing privilege.

For IAM and IGA teams, the important question is not whether every phone scam can be blocked. It is how far a compromised account can move once a reset, MFA re-enrollment, or help-desk exception has been granted. That is the blast radius problem.

The article’s central claim is that reach, not deception, determines impact. If a single account can touch too many systems, then a successful social engineering call becomes a business outage and a costly remediation exercise.


Key questions

Q: What breaks when a help desk can reset access for a compromised user account?

A: When support can reset passwords or re-enrol MFA for an impersonated user, the recovery path becomes the real attack path. The login may still look legitimate to the identity provider, but the attacker now has a trusted session boundary. Teams need to govern support actions with the same scrutiny they apply to privileged administrative changes.

Q: Why does standing privilege still create so much identity risk?

A: Standing privilege keeps elevated access available long after the work that justified it has ended. That increases blast radius, weakens accountability, and makes review processes chase a moving target. Just-in-time access only helps when elevation is short-lived, context-aware, and paired with clean role design and reliable offboarding.

Q: How do security teams know whether identity governance is reducing risk?

A: Look for shorter time from access change to visibility, fewer unmanaged entitlements, and faster completion of review and remediation cycles. If access risk remains unchanged after deployment, the programme may be reporting activity without changing control outcomes.

Q: Should organisations prioritise just-in-time access over more verification at the help desk?

A: They should do both, but just-in-time access changes the consequence of a successful social-engineering call. Better verification reduces the chance of compromise, while short-lived access reduces what the attacker can do after compromise. When reach is large, reducing standing privilege usually has the bigger effect on business impact.


Technical breakdown

Help-desk impersonation as a recovery-path compromise

The entry point was not a traditional exploit but a phone call that tricked support into resetting a password and bypassing 2FA. That matters because recovery workflows often carry more privilege than the login they protect. Once an attacker controls a verified recovery path, downstream authentication can look legitimate to the identity provider even though the actor behind it is not. In other words, the security boundary shifted from the login screen to the human support process, where verification quality and exception handling determine whether access is restored to the rightful user or handed to the attacker.

Practical implication: treat help-desk recovery as a privileged control surface, not a clerical function.

Effective permissions versus assigned roles

The article distinguishes between role assignment and what an identity can actually reach. That distinction matters because nested groups, inherited admin rights, and legacy entitlements can turn a modest user account into a path across dozens of systems. Effective permissions are the permissions that matter operationally, because they define blast radius. Assigned roles are only the starting point. If governance reviews focus on row counts and role names without resolving inheritance, teams will miss the true access graph that an attacker can traverse after one successful reset.

Practical implication: review effective permissions through inheritance and group nesting, not just role labels.

Why standing privilege multiplies the damage

The breach narrative shows how unused but persistent access accumulates over time until one account becomes a launch point into many systems. Standing privilege is dangerous because it exists before a task is needed and remains after the task ends, which gives an attacker durable reach once the identity is compromised. The problem is not only excess permission. It is the gap between entitlement and use. Role mining, just-in-time access, and continuous certification all aim at that gap, but the article’s core lesson is that standing privilege itself is the multiplier that turns deception into material loss.

Practical implication: minimise standing privilege so a single account compromise cannot scale into enterprise-wide access.


Threat narrative

Attacker objective: The attackers aimed to convert one compromised identity into broad operational access and monetisable disruption across the Transport for London environment.

  1. Entry occurred through a phone-based help-desk impersonation that led to a password reset and 2FA bypass for a stolen employee account.
  2. Credential access followed because the attackers obtained a legitimate-enough identity path after buying partial credentials and convincing support to reset access.
  3. Escalation unfolded over sixteen hours as the attackers moved from the initial account into inherited entitlements, standing privilege, and broader system reach.
  4. Impact was reached when that one identity path expanded to 148 systems, forcing large-scale remediation and contributing to roughly £29 million in losses.
  • MGM Resorts breach 2023: A help desk call gave attackers Okta and Azure admin access at MGM, leading to ransomware, ten days of outages and a $100 million hit.
  • Caesars Entertainment breach 2023: Social engineering of an IT support vendor let attackers copy Caesars loyalty database; about $15 million was reportedly paid.

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

Identity reach, not authentication strength, is the decisive variable in help-desk attacks. The Transport for London case shows that a compromise path can begin with perfectly ordinary recovery steps and still produce major impact. Strong authentication on a compromised enrollment or reset path simply authenticates the attacker more reliably. Practitioners should therefore measure how much an identity can reach after recovery, not just whether login controls worked.

Effective permissions are the real governance object, because assigned roles hide inherited power. The article’s description of nested groups and accumulated entitlements shows why role names do not tell the governance story. Access reviews that stop at role labels will miss resource-level reach and therefore miss the blast radius that attackers exploit. The practical conclusion is that identity governance must inspect inherited permissions as a first-class control problem.

Standards for review cadence assume access is visible and stable long enough to be certified. That assumption failed here because the attacker’s value came from hidden, accumulated access that reviewers could not contextualise from 130 rows of permissions. The implication is that certification processes built for static entitlements do not control dynamic reach unless entitlement data and usage data are joined. Governance teams should treat this as an access-graph problem, not a checkbox exercise.

Just-in-time access is not a convenience feature, it is the control that removes the standing-privilege multiplier. When a reset can open access to 148 systems, every default entitlement becomes part of the attack surface. The article sharpens a useful concept: identity blast radius. That is the practical unit of measurement for whether an account is overpowered, and it should drive every remediation discussion.

Help-desk identity recovery must be governed as privileged access, because the recovery path is now the attack path. The incident shows that social engineering often lands in the support workflow rather than the login flow. That shifts ownership from only IAM engineering to help-desk governance, IGA, and PAM oversight. The programme implication is clear: if support can reset it, support has become part of the privilege model.

What this signals

Identity blast radius is the control gap this incident exposes. Programmes that focus on authentication strength but ignore inherited reach will keep seeing social engineering turn into systemic access. The practical shift is to govern what an identity can touch after a reset, not only how it logs in.

Access reviews need effective-permission context, not raw entitlement rows. When reviewers cannot see nested groups, delegated rights, and dormant admin paths in the same graph, certification becomes a rubber stamp rather than a risk decision.

Help-desk workflows now sit inside the identity control plane. If a support analyst can restore access that materially widens blast radius, then recovery governance belongs in the same conversation as PAM and IGA.


For practitioners

  • Map identity blast radius Resolve each high-value account’s effective permissions through nested groups, inherited admin, and resource-level entitlements so you know what one reset can touch.
  • Govern help-desk recovery as privileged access Treat password resets, MFA re-enrollment, and exception handling as controlled privileged workflows with explicit approvals and audit evidence.
  • Convert excess access into just-in-time grant paths Split genuinely needed access into birthright permissions and ephemeral access windows so standing privilege does not persist by default.
  • Join entitlement data with actual usage Use role mining and access analytics to compare granted permissions with what accounts really use, then remove the gap that hides dormant reach.

Key takeaways

  • The Transport for London attack shows that social engineering becomes much more damaging when one account has broad inherited reach.
  • The incident moved from one phone call to 148 systems and roughly £29 million in losses, which is the scale blast radius can create.
  • Reducing standing privilege and exposing effective permissions are the controls most likely to limit the next recovery-path compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingThe article shows how recovery and account state outlived the original trust boundary.
NHI-05 — Overprivileged NHIThe core problem is excessive effective access, not just account takeover.
NHI-10 — Human Use of NHIA human support workflow was abused to re-issue privileged access to a non-human-like account path.
Recommendation — Audit recovery paths and revoke stale access so compromised accounts cannot retain broad reach. Reduce effective permissions and inherited access until each account can only reach what it needs. Separate support-driven recovery from privileged access administration and log every exception.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe incident is fundamentally about uncontrolled entitlements and authorization scope.
Recommendation — Review entitlements at the effective-access level and remove excess authorization paths.
CIS Controls v8CIS-5 — Account ManagementAccount state and recovery handling enabled the escalation chain.
Recommendation — Tighten account lifecycle controls and verify that recovery actions are separately authorised.

Key terms

  • Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
  • Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
  • Recovery Path: The set of backup methods, reset flows, and help-desk procedures that restore access when a user loses their primary credential. Recovery paths often become the weakest part of identity governance because they can reintroduce shared secrets, manual override, or inconsistent verification standards.

Deepen your knowledge

NHI governance, identity lifecycle management, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org