On the morning of 1 September 2024, someone called Transport for London's IT helpdesk. They were polite. They had the right information. They convinced the helpdesk to reset credentials. And with that single act of social engineering, a cybercriminal group gained access to internal systems holding the personal data of millions of passengers.
The breach — attributed to Scattered Spider — cost TfL £39 million and disrupted services for three months. Over 7 million customers were ultimately notified. Bank account details for thousands had been accessed. Core transit services kept running, but the digital layer around them — customer portals, account management, third-party data feeds — was knocked offline while engineers scrambled to contain the damage.
The most striking part of the TfL story isn't the scale. It's the method. No sophisticated zero-day exploit. No nation-state malware. A phone call to a helpdesk. That is the cybersecurity reality facing modern fare collection systems — and it is fundamentally different from anything the industry was designing against when it first moved from cash to contactless.
A closed-loop transit card from fifteen years ago had a narrow security perimeter. The card talked to the reader. The reader talked to the back office. Almost nothing else was connected. Today's AFC ecosystem looks nothing like that.
Open-loop payments connect validators directly to global EMV payment networks. Account-based ticketing platforms run in cloud environments that must integrate with acquiring banks, payment gateways, clearing and settlement systems, customer account portals, and MaaS applications. Every integration that makes the system more useful for a passenger also creates a potential entry point for an attacker. The data flowing through a modern AFC platform — payment credentials, journey histories, personally identifiable information, account balances — is exactly what sophisticated criminal groups are looking for.
The transportation sector saw a 181% year-over-year rise in data breaches in 2023, with 12 million individuals affected — more victims than any other industry in that period. The average cost of a data breach in the sector now stands at $4.4 million. These are not abstract statistics. They represent passengers whose bank details were exposed, operations staff diverted from running services to managing incident response, and transport networks whose public credibility took damage measured in years.
The pattern across transit cyberattacks of the last three years is consistent, and it points to something important: the attacks that cause the most damage are rarely the most technically sophisticated ones.
A social engineering call to a helpdesk bypassed every technical control in place, giving attackers access to customer databases. Core transit operations were unaffected — the digital layer around them was not.
The Medusa ransomware gang took down ticketing systems, online top-ups, and customer service centres simultaneously. The network's response — offering free travel — kept people moving but cost millions in lost revenue.
A ransomware attack disrupted rail services and affected the processing of concessionary travel cards — hitting the most vulnerable riders first. Investigation later confirmed employee personal data, including identity documents, had been compromised.
Running through all three incidents are the same vulnerabilities: systems that hadn't been updated, access controls that were too permissive, and — in the TfL case — a human process that bypassed the entire technical stack. Research shows that 85% of OT environments in transport don't patch regularly, leaving known vulnerabilities exposed for months at a time. That figure alone explains more cyberattacks than any sophisticated threat actor analysis.
Most transit cyberattacks don't succeed because the attacker was exceptionally skilled. They succeed because a legacy system hadn't been updated, an access control was misconfigured, or a staff member was deceived into granting access. Governance failures, not technical ones, are the dominant root cause.
When an AFC system accepts EMV bank cards or mobile wallets, it enters the regulated world of card payments. Three frameworks define what operating in that world responsibly looks like.
The Payment Card Industry Data Security Standard sets the baseline for any organisation handling card data. For transit authorities, PCI DSS compliance must be designed into the AFC architecture from the outset. Retrofitting controls into an existing deployment is considerably more expensive than building them in — security is far easier to architect than to recover.
EMV specifications are what make a bank card tap at a fare gate as secure as a tap at a café. EMV certification at validator level ensures the device communicates securely with any compliant card or wallet, protecting against counterfeiting and card cloning. When a passenger uses their Mastercard to board, they're relying on an assumption of safety. EMV standards are what make that assumption valid.
When a passenger's bank card is used in an account-based ticketing system, the card number itself is never stored in the transit environment. A unique token — useless if intercepted — travels through the AFC system instead. This reduces PCI compliance scope, lowers fraud exposure, and fundamentally changes the risk profile of cloud-based AFC deployments. It is now the cornerstone of secure open-loop fare collection.
Security is far easier to architect than to recover. The time to have the PCI DSS conversation is before the validator procurement — not after the first declined transaction.
Behind every open-loop AFC implementation sits an infrastructure component that rarely appears in passenger-facing communications but carries an enormous amount of operational and security weight — the Transit Payment Gateway.
Think of it as the secure air lock between the transport world and the financial world. It handles payment authorisation, routes transactions to acquiring banks, manages the token lifecycle, and monitors for fraud signals in real time. When a passenger's bank card is declined at a fare gate, the TPG is why the decline happened gracefully rather than catastrophically. When a fraudulent card attempts repeated taps across a network, the TPG is what flags the pattern before the damage compounds.
A well-designed Transit Payment Gateway also handles one of transit's trickiest problems: offline transactions. Validators in tunnels and remote locations can't always maintain a live connection to a payment network. The TPG governs how much financial risk the operator absorbs during offline periods, how long a card can be accepted without a real-time authorisation check, and how those transactions are reconciled when connectivity is restored. Getting this wrong doesn't just create financial exposure — it creates a fraud surface that sophisticated attackers will find and exploit.
Transit agencies don't build their own AFC systems. They procure them from technology vendors, integrate them with payment processors, and run them with support from multiple third-party service providers. Each of those relationships is a potential entry point.
In 2022, a cyberattack on a third-party IT provider disrupted software used by Danish rail operators, causing temporary service interruptions — without the rail operator itself being directly breached. The lesson was unambiguous: agencies must manage not only their own cybersecurity posture, but also the resilience of every supplier in their ecosystem.
The TfL breach reinforces this from a different angle. The initial access was a social engineering call — but the damage was amplified by the breadth of systems reachable once valid credentials had been obtained. The technical perimeter held. The human perimeter did not.
CISA, the FBI, and NSA have all issued warnings about AI-enabled phishing, impersonation attacks, and increasingly sophisticated social engineering — precisely the techniques used in the TfL breach — becoming more targeted and more convincing. The helpdesk call that breached one of the world's most sophisticated transit networks required no technical expertise. It required a convincing voice and some background research. No firewall solves that.
There's a question worth sitting with: why do passengers trust that a tap of their bank card at a transit gate is safe?
They don't think about it consciously. They just tap — and the assumption underneath that tap is that someone, somewhere, has done the work to make it trustworthy. That assumption is not an accident. It is engineered. And it is more fragile than the passenger experience suggests.
When a passenger uses their Mastercard at a fare gate, they are borrowing trust that the payments industry spent decades building. The moment an AFC system becomes the vector for a fraud, a data exposure, or a breach tied to a payment credential, it doesn't just damage that operator. It damages the case for open-loop transit payments everywhere. Security in fare collection is therefore not just an individual operator risk problem — it is a collective industry responsibility. The architecture decisions one authority makes have implications for the credibility of the entire ecosystem.
And as account-based systems deepen the connection between mobility accounts and financial identities, that responsibility only grows. The AFC platform of the future isn't just processing fare transactions. It is a custodian of how people move, pay, and identify themselves in a city.
That is not a system you secure after the fact. That is a system you build secure from the start — because in digital mobility, trust isn't a feature you can add in the next release.
"What's the biggest security challenge you've faced in digital ticketing?"
Is it PCI DSS compliance, integrating with payment ecosystems, protecting passenger data, or managing supply chain risk? Drop a comment — these conversations surface the things that don't make it into the formal case studies.