The TfL Cyberattack: How Scattered Spider Stole 7 Million Customer Records Without Disrupting a Single Train

The TfL Cyberattack: How Scattered Spider Stole 7 Million Customer Records Without Disrupting a Single Train
Over GBP 30 million in remediation costs across the organisation. Up to 10 million people's personal data accessed. Around 5,000 bank account numbers and sort codes exposed. All 30,000 staff forced through in-person identity verification over several weeks. And every Tube, bus, DLR (Docklands Light Railway), and Elizabeth line service kept running throughout.
The cyberattack on Transport for London (TfL) in September 2024 was the largest in the organisation's history. But most of the public conversation focused on the wrong thing.
What everyone thinks happened
The early coverage framed this as a transport disruption story. Contactless payments were affected, Oyster cards were not working properly, and journey histories were unavailable. The assumption was that an attack on TfL meant an attack on London's transport network, which carries around nine million journeys a day.
That framing misses what actually matters here. Every safety-critical transport system kept operating throughout the incident. Trains and buses continued to run on their normal schedules. Oyster and contactless tapping at gates continued to collect fares. The DLR, Overground, Elizabeth line, and trams were unaffected. No passenger was stranded because of this attack.
What actually happened was a data breach on an enormous scale, combined with an identity compromise so severe that TfL could not trust its own directory services. The transport disruption story is the minor subplot, and the data story is the main event.
What actually happened
The intrusion
The attack began on 31 August 2024. TfL identified suspicious activity the following day, 1 September, and took immediate action to restrict access. On 2 September, TfL publicly disclosed that it was dealing with an "ongoing cyber security incident." That's a detection window of roughly 24 hours, which is fast by most standards.
TfL brought in the National Crime Agency (NCA) and the National Cyber Security Centre (NCSC) immediately. On 6 September, TfL issued its first detailed press release, stating there was no evidence of customer data compromise at that stage.
Six days later, the picture changed significantly.
The data exposure
On 12 September, TfL confirmed that customer data had been accessed. The initial disclosure mentioned names, contact details, and Oyster card refund data including bank account numbers and sort codes for approximately 5,000 customers. Those 5,000 customers were contacted directly by TfL.
The full scale only became clear much later. In March 2026, a BBC investigation obtained a database from the hacking community containing nearly 15 million lines of information. The data included names, email addresses, landline and mobile phone numbers, and street addresses. The BBC estimated around 10 million people were affected.
TfL's own confirmed figure came in slightly lower than that estimate. The organisation sent notification emails to approximately 7.1 million customers. Only 58 percent of those emails were opened, which means roughly 3 million people whose data was accessed may not know about it. (as noted in the February 2026 governance review).
The identity crisis
The data breach is the part that gets the headlines. But the operational detail that reveals the true depth of the compromise is what happened to TfL's internal systems.
TfL required all 30,000 employees, every single one, to attend in-person appointments at designated TfL locations. Each person's identity was verified individually before they were allowed to reset their password. The process took several weeks to complete across the entire workforce.
That decision tells you something critical about what the attackers reached. You don't force 30,000 people through face-to-face identity checks unless you've lost confidence in your directory services. If TfL could have trusted its Active Directory or identity provider, a remote password reset would have been sufficient. The in-person requirement strongly suggests the attackers had access to, or had compromised, the identity infrastructure itself.
During this period, staff at TfL's Southwark headquarters were asked to work from home where possible. Wi-Fi was reportedly disabled in TfL offices during the early stages. Internal systems access was restricted as a precaution. The practical effect was that thousands of staff could not do their normal work for weeks.
The systems that went down
The attack did not touch transport operations, but it hit customer-facing digital services hard.
Contactless and Oyster journey history access was suspended from 1 September until 4 December 2024, roughly three months. During that period, customers couldn't check their journey records, and TfL couldn't process refunds. Around 96,000 contactless customers were unable to submit webforms to TfL's contact centre. The contact centre recorded 36,936 cases related to Oyster and contactless payment cards, and TfL anticipated that 67 percent of those would result in a refund.
Photocard applications (Zip cards for young people, 18+ Student, and 60+ London Oyster cards) were suspended from September through November 2024. By the time the system was restored, TfL had a backlog. By 4 December, they'd processed and dispatched over 85,000 photocards: 33,000 Zip cards, 40,000 student cards, and 13,000 60+ cards.
The Dial-a-Ride booking system went offline in early September, though pre-existing bookings were still fulfilled and phone bookings were restored for essential journeys. TfL Go app live data, next train information displays, JamCams, and third-party API feeds (used by apps like Citymapper) all went dark at various points.
A planned expansion of contactless pay-as-you-go to 47 stations outside London, scheduled for 22 September 2024, was postponed by more than four months until 2 February 2025.
The financial damage
TfL's board papers from December 2024 put the remediation cost at over GBP 30 million. That figure covers external cybersecurity support, investigation costs, remedial security measures, and software upgrades. Of that, GBP 5 million was specifically spent on incident response, investigation, and remedial cybersecurity measures in the three months to December 2024.
The wider financial picture paints an even worse outcome. Before the attack, TfL had forecast an operating surplus of GBP 61 million for the 2024/25 financial year. After the incident, that forecast dropped to GBP 23 million, a reduction of GBP 38 million. Some reporting puts the total impact approaching GBP 39 to 40 million when including the full operating surplus reduction, though TfL's confirmed figure remains "over GBP 30 million" for direct remediation costs.
The Scattered Spider connection
TfL has not publicly attributed the attack to any named group. But investigators have since identified those believed to be responsible.
On 16 September 2025, the NCA and City of London Police arrested two individuals at their home addresses. Thalha Jubair, 19, from East London (also known online as EarthtoStar, Brad, Austin, and @autistic) was charged with conspiracy to commit unauthorised acts in relation to a computer causing or creating risk of serious damage to human welfare or national security. That charge, under the Computer Misuse Act, carries a maximum sentence of life imprisonment. He was also charged under the Regulation of Investigatory Powers Act (RIPA) 2000 for refusing to provide device passcodes. Jubair also faces separate US Department of Justice charges linked to at least 120 network intrusions and extortion targeting 47 US entities.
Owen Flowers, 18, from Walsall in the West Midlands, was charged with conspiracy to commit unauthorised acts under the Computer Misuse Act, plus two additional charges relating to the infiltration of SSM Health Care Corporation and Sutter Health, both US healthcare companies. Flowers was the 17-year-old initially arrested in September 2024, just 13 days after TfL disclosed the incident.
Both appeared at Westminster Magistrates Court on the day of their arrest, and then at Southwark Crown Court on 21 November 2025, where they pleaded not guilty to all charges. Both defendants were remanded into custody pending trial. The trial is scheduled for June 2026.
The NCA's head of the National Cyber Crime Unit, Paul Foster, stated that "this attack caused significant disruption and millions in losses to TfL." The investigation was supported by the West Midlands Regional Organised Crime Unit and British Transport Police.
The charges link both defendants to the Scattered Spider cybercriminal collective, described as an "English-speaking" group responsible for attacks in both Britain and the United States. Scattered Spider is known for social engineering techniques, particularly targeting helpdesk and identity systems, and SIM swapping. The same collective has been linked to high-profile attacks on MGM Resorts, Caesars Entertainment, Marks and Spencer, the Co-op, and Harrods.
Myth vs fact
Myth: The attack disrupted London's transport network.
Every Underground, bus, DLR, Overground, Elizabeth line, and tram service continued operating throughout the incident. Oyster and contactless tapping at fare gates worked normally. Safety-critical systems were maintained at all times. The attack hit data systems and customer-facing digital services, not transport operations. The architectural separation between TfL's operational technology (the systems that run trains and manage signalling) and its IT environment (customer databases, journey history, refund systems) meant that a compromise of the data layer didn't cascade into the physical transport layer. That separation is exactly the kind of network segmentation that limits blast radius, and in this case it worked.
Myth: This was a ransomware attack on transport systems.
Some early media reports speculated that ransomware was involved. TfL has never described this as a ransomware attack, and the available evidence doesn't support that characterisation. There's no public indication of file encryption, ransom demands, or data destruction. What happened was an intrusion focused on data exfiltration and, based on the scale of the identity recovery effort, likely compromise of directory services or identity infrastructure. The distinction matters because the response to ransomware (restore from backups, decrypt, rebuild) is different from the response to an identity compromise (verify every user, reset every credential, audit every access path).
Myth: Only around 5,000 customers were affected by the breach.
The 5,000 figure refers specifically to customers whose Oyster card refund data (including bank account numbers and sort codes) was accessed. That's the subset with financial data exposure. The total number of people whose personal information was accessed is vastly larger. TfL sent notification emails to 7.1 million customers. The BBC's investigation found a database in the hacking community containing data on approximately 10 million people. Even at the lower 7.1 million figure, this is one of the largest data breaches in UK public sector history.
Myth: Teenagers can't cause this level of damage.
Both charged defendants were teenagers at the time of the attack (17 and 18 years old). Scattered Spider's membership skews young, and the group is known for social engineering rather than traditional exploit development. Social engineering attacks bypass technical controls entirely. They target people, specifically helpdesk staff, IT support teams, and anyone with the authority to reset credentials or grant access. The attackers do not need to find a software vulnerability when they can convince someone to hand over access. The age of the attacker is irrelevant to the scale of the damage when the technique is social rather than technical.
What could have limited the blast radius
TfL detected the intrusion within approximately 24 hours. The NCSC, NCA, and Microsoft all assessed that TfL "responded well" and "disrupted the attack to some extent, potentially preventing a far worse outcome." The response was good. The question is what would have reduced the amount of data accessible in the first place.
Identity and access management
The in-person password reset of 30,000 employees is the single most significant operational indicator in this incident. It suggests the attackers reached identity infrastructure, which is consistent with Scattered Spider's known techniques. Phishing-resistant multi-factor authentication (MFA) using FIDO2 or WebAuthn standards on all employee accounts would make initial access through social engineering significantly harder. Conditional access policies that restrict authentication to managed devices would limit what an attacker can do even after stealing credentials. These controls don't make social engineering impossible, but they remove the simplest paths.
Network segmentation between data stores
The separation between operational transport systems and IT systems worked. All train and bus services were completely unaffected throughout. But the volume of customer data accessed (up to 10 million records) suggests the attacker could move across customer data stores after gaining initial access. Stronger segmentation between different customer databases, separating journey history from contact details from financial refund data, would have reduced the amount of information accessible from a single compromise point. If the Oyster refund database containing bank details had been isolated behind its own access controls, the 5,000 customers with financial data exposure might not have been affected.
Data minimisation and retention
A database containing 10 million customer records with names, addresses, email addresses, and phone numbers is a high-value target. The question every organisation holding that volume of personal data should ask is how much of it they still need. Retention policies that archive or delete customer records after a defined period would reduce the volume of data available to an attacker. Tokenisation of sensitive fields, particularly the bank account numbers and sort codes in the Oyster refund database, would have meant the attacker got tokens rather than usable financial data.
Privileged access management
The breadth of systems affected suggests the attackers gained access to privileged credentials. Just-in-time privileged access, where administrative rights are elevated for a specific task and automatically revoked afterwards, limits what an attacker can reach even after compromising an account. Separate privileged access workstations for administration of critical systems create additional barriers that social engineering alone can't easily overcome.
Rapid identity recovery planning
The in-person identity verification process was thorough but extremely slow. Requiring 30,000 people to attend face-to-face appointments took weeks and significantly affected productivity. Pre-planned rapid identity recovery procedures, such as hardware token-based recovery or pre-staged clean credentials, could have accelerated the process from weeks to days. This is a planning question, not a technology question. Organisations with large workforces should have a tested playbook for "what do we do if we can't trust our identity provider?"
What changed after
The ICO response
TfL notified the Information Commissioner's Office (ICO) of the data breach. On 13 February 2025, the ICO confirmed that no regulatory action would be taken against TfL. The ICO considered TfL's overall response to be proportionate.
That outcome, no regulatory action despite a breach affecting up to 10 million people, is notable. It suggests the ICO assessed TfL's detection speed, containment actions, notification process, and remediation efforts as meeting the standard expected under UK General Data Protection Regulation (UK GDPR). The scale of the breach alone does not determine the regulatory outcome. The adequacy of the response is what determines the outcome.
The independent review
TfL's board commissioned an independent review of the incident, announced in November 2024. The review covers the circumstances of the attack, its impact, TfL's response, and whether further improvements to cybersecurity strategy are needed. Because the NCA's criminal investigation is ongoing, the review may be conducted in phases. It's overseen by members of TfL's board.
London Assembly oversight
The Greater London Authority (GLA) Oversight Committee published a report on 12 February 2026 describing this as "the biggest cyber-attack in TfL's history." The report contained eleven recommendations, including cybersecurity investment benchmarking, contingency plans for loss of email and file access, and a joint cybersecurity exercise between the GLA and TfL. The committee chair, Emma Best AM, stated: "For the sake of Londoners, we seek further assurance that everything possible is being done to defend against the next attack."
The broader Scattered Spider picture
The TfL attack doesn't exist in isolation. Scattered Spider has been linked to attacks on MGM Resorts, Caesars Entertainment, and more recently Marks and Spencer, the Co-op, and Harrods in the UK. The group's consistent use of social engineering, particularly targeting helpdesks and identity systems, suggests a pattern that organisations should be actively testing against. If your helpdesk can reset a password or grant MFA bypass without strong identity verification, you have the same exposure that Scattered Spider exploits repeatedly.
Service recovery
All TfL fares services affected by the incident were reinstated by 4 December 2024, roughly three months after the attack began. Contactless and Oyster journey history was restored, refund processing resumed, and the photocard backlog was cleared. The contactless expansion to 47 stations outside London, originally scheduled for 22 September 2024, was rescheduled to 2 February 2025.
The uncomfortable maths
TfL is a public body, a functional body of the Greater London Authority. It's funded by a combination of fares revenue, government grants, and the London congestion charge. Over GBP 30 million in remediation costs is public money. The GBP 38 million reduction in forecast operating surplus affects TfL's ability to invest in services that Londoners depend on.
The attackers were teenagers at the time of the incident. The primary technique they used was social engineering. The data of up to 10 million people was accessed. And every train kept running, which made it easy for the public to assume the impact was minor.
The impact was not minor by any reasonable measure. The financial cost alone was enormous by any standard. The data exposure was one of the largest in UK public sector history. And the recovery effort, 30,000 face-to-face identity verifications over several weeks, is one of the most operationally demanding workforce recovery exercises ever documented in a UK cyber incident.
The organisations watching this should be asking themselves three questions. Could a social engineering attack compromise your identity infrastructure? If it did, how would you verify 100 percent of your workforce? And how long would that verification process realistically take?
Related articles
- The County Mayo Water Hack: How a Default Password Took 180 Homes Offline
- The CrowdStrike Outage: What Actually Happened Inside 8.5 Million Machines
- The HSE Ireland Ransomware Attack: Eight Weeks of Missed Signals
- The Cost of Not Having an Incident Response Plan
Get cybersecurity insights delivered
Join our newsletter for practical security guidance, Cyber Essentials updates, and threat alerts. No spam, just actionable advice for UK businesses.
Related Guides
The Stryker Attack: When Your Own Device Management Becomes the Weapon
How Iranian-linked hackers weaponised Stryker's Microsoft Intune to wipe devices globally, disrupting medical device manufacturing across 79 countries.
The JLR Cyber Attack: How a Single Breach Contracted UK GDP
Inside the Jaguar Land Rover cyber incident that shut down production for five weeks, cost GBP 1.9 billion, and triggered the UK's first cyber-related government loan guarantee.
The Ivanti VPN Zero-Day: How a Buffer Overflow in a VPN Appliance Breached the UK's Domain Registry
In December 2024, a suspected Chinese state-sponsored group exploited CVE-2025-0282, a critical stack-based buffer overflow in Ivanti Connect Secure, to breach Nominet, the registry responsible for over 11 million .uk domain names. The vulnerability required no authentication. Five days after the patch was released, only 120 of 33,542 exposed appliances had been updated.
Ready to get certified?
Book your Cyber Essentials certification or check your readiness with a free quiz.