Why World Cup cyber risk sat in the city services residents use every day

The week

On June 11, 2026, the FIFA World Cup opened at Estadio Azteca in Mexico City. It was a tournament of firsts: the first with 48 teams, the first with 104 matches and the first shared by three countries. Matches were scheduled in sixteen host cities, eleven in the United States, three in Mexico and two in Canada, and the final was set for July 19 at MetLife Stadium in East Rutherford, New Jersey.

The security preparation had begun long before the first whistle. In March 2025, an executive order created a White House Task Force on the FIFA World Cup 2026. Federal, state and local agencies had been planning security for more than a year, working out how to protect the stadiums, the crowds and the people moving between them.

Most of that planning, and nearly all of the public attention, focused on the venues, with good reason. A stadium on match day is a visible, high-value target, and the agencies that protect it have decades of experience with large events.

But in the week of June 8, with the first US matches only days away, a less visible group of public servants was bracing for something different. City and county technology teams in the host regions, the people who keep parking payment sites, traffic signals, 311 phone lines and 911 dispatch systems running, were about to enter five weeks of sustained, elevated demand on everyday public services.

A stadium is secured for a few hours at a time; the city around it stays open for five weeks. Visitors arrive who have never used the local transit app, never paid for parking on that city’s website and never needed to know how its emergency services work. Residents still need permits processed, buses running and emergency calls answered. Every one of those services depends on software, networks and outside suppliers, and every one of them was about to carry more weight than usual.

This week’s story lies outside the stadiums, in the exposure that belonged to host-city agencies themselves: the ordinary services residents rely on every day. That exposure was harder to see, harder to own and easier to underestimate than the security everyone was watching.

Security inside and around the stadiums was planned by federal agencies, state police and venue operators with long experience of large events. That work drew most of the attention, and rightly so. The exposure that belonged to city and county agencies was less visible and more spread out.

It sat in four places that do not overlap. The first is the channels residents and visitors use to find official information and pay for things. The second is the operational technology that moves traffic and transit. The third is the emergency communications chain, and the fourth is the vendors that several host jurisdictions share. Each called for a different kind of plan, owned by a different part of local government, which is what made it hard.

What “cyber risk” means on a city street

For anyone who does not spend their days thinking about technology, “cyber risk” can sound abstract. In a city, it is concrete: the chance that a computer system residents depend on stops working, gives wrong answers or is used to deceive people, because someone attacked it or because it buckled under pressure.

A few terms come up again and again, and they are worth knowing.

• Ransomware is malicious software that locks up an organization’s files and systems, then demands payment to unlock them.
• Denial of service is an attack that floods a website or phone line with so much fake traffic that real users cannot get through.
• Impersonation, or phishing, is the use of fake websites, emails or text messages that look official in order to trick people into paying money or handing over personal details.
• Operational technology, often shortened to OT, is the hardware and software that controls physical things: traffic lights, train signals, pumps, garage gates. Ordinary IT handles information. OT moves the physical world.

The distinction between IT and OT matters. When an email system fails, people are inconvenienced. When a traffic signal network fails near a stadium as a full crowd pours onto the streets, the problem becomes physical and immediate. A major event raises the stakes on both kinds of system at once, and it does so in public, with cameras everywhere.

Not every failure is an attack. Systems fail because they are overloaded, misconfigured or simply old. During a big event, an honest surge in demand and a deliberate attack can look almost identical in the first hour. Good planning prepares for both, because the response, keeping the service running and telling the public what is happening, is largely the same.

Resident and visitor channels

Large events attract fraud that borrows a host city’s identity. Fake parking permits, counterfeit transit passes, impostor visitor-information sites and bogus fan-zone registrations all exploit the same moment: someone searching quickly on a phone for official information. Agencies cannot take every lookalike site down. They can make the official channel easy to find and easy to recognize.

In practice that means registering likely lookalike domains before the event, monitoring for new impersonation sites, and publishing one short list of official channels that every department and partner repeats. A domain is a website’s address. Fraudsters register addresses that differ from the real one by a letter, a hyphen or a different ending, betting that a hurried visitor will not notice. Buying the most obvious variations first is cheap insurance.

Pages built for a small screen and offered in the languages visitors actually use do security work too. A visitor who finds the parking page in Spanish or Portuguese is less likely to follow a link from a text message. Good customer experience works as a security control, because people go looking for alternatives when the official option is confusing.

The same channels face legitimate surges. Permit portals, parking payment systems and 311 lines can see volume they were never sized for. Load testing, which means deliberately sending a simulated crowd of users at a system to see where it slows down or breaks, gives a team the answer before real visitors do. A written decision about which features to switch off under strain matters just as much. Without them, a capacity failure can look like an attack, and an attack can hide inside a capacity failure.

Suppose a city’s parking payment site normally handles a few hundred transactions an hour, and on match day faces many times that. If the team has decided in advance to turn off a rarely used account-history feature under heavy load, the core payment function survives. If no one has made that call, the whole site may slow to a crawl, social media fills with complaints and someone posts a “working” alternative link that leads to a fraudster. The owner of this work is usually the digital services team, working with communications staff who control the public message.

Transit and traffic technology

Traffic signal controllers, transit fare and signaling systems, parking garage equipment and building management systems near venues are operational technology. Many were designed for reliability and long service lives. A traffic controller might sit in a roadside cabinet for well over a decade. It was built to keep working through heat, cold and power fluctuations, and fending off a determined intruder was never part of the brief.

Some of these systems are reachable from the internet for remote maintenance. That convenience has a cost. If a contractor can log in from their office to adjust a signal timing plan, then, unless that access is carefully controlled, someone else may be able to as well. Federal advisories in recent years have repeatedly warned about exposed control interfaces in municipal water and other local systems. The same pattern applies to transportation.

Six weeks is too short to re-architect any of this. It is long enough to do four things.

1. Agencies can list the OT systems within the event footprint and who maintains each one.
2. They can close or gate internet exposure they find.
3. They can confirm that vendor remote access runs through a controlled, logged path, and can be cut off without stopping operations.
4. And they can rehearse the manual fallback, such as fixed signal timing plans or staffed fare gates, with the people who would actually run it.

The third point deserves a moment. Cutting off a vendor’s remote access is the obvious response if something looks wrong. But if the system cannot run without that connection, the cure becomes as damaging as the disease. Knowing in advance that the switch can be flipped safely gives decision-makers a real option in a crisis, rather than a choice between two bad outcomes.

The fourth point is the one most often skipped. A fallback plan that lives in a binder but has never been practiced by the night-shift crew is a hope rather than a plan. The owner here is the transportation or public works department, which often has its own technology staff outside the city CIO’s reporting line. That organizational detail matters more than it sounds, because it means the city’s central security team may not even know what equipment exists.

The emergency communications chain

Public safety answering points and computer-aided dispatch are the most consequential systems a city runs during an event. A public safety answering point, or PSAP, is the call center that picks up when someone dials 911. Computer-aided dispatch, or CAD, is the software dispatchers use to log each incident, see which police, fire and ambulance units are available and send the right one.

These systems face heavier call volumes during an event and can be targeted with call flooding or ransomware. Call flooding is a denial-of-service attack aimed at phone lines: automated systems place large numbers of calls so that genuine emergencies wait in the queue. They also depend on carriers, regional 911 networks, radio systems and software vendors that the agency does not control.

The planning questions are about continuity, the ability to keep serving the public when a piece of the system fails.

• A center needs to know where calls route if it is overwhelmed or offline.
• Dispatchers need a way to work if CAD is down, with paper run cards and current unit status boards.
• Mutual aid partners need a way to share incident information if a shared platform fails.
• And someone has to be able to tell, quickly, that a pattern of calls is malicious.

Many centers had answers in their continuity plans. A major event was a reason to test those answers under realistic load, with the regional partners in the room, before the first match. Testing is where plans meet reality. A rerouting arrangement may work perfectly on paper and then reveal, in a drill, that the backup center has two open seats on a Saturday night, or that the paper run cards were last updated before a fire station moved.

The reason to care is simple. A delay in answering emergency calls during a world-famous event would quickly become a public safety story, a political story and a story about trust in government, all at once.

Vendors shared across host jurisdictions

Host cities and neighboring counties often buy from the same small group of vendors for parking, mobility apps, public Wi-Fi, digital signage, permitting and event management. That is efficient. It also concentrates risk. A compromise or outage at one provider can hit several jurisdictions at the same time. No single city sees the whole dependency map: each may have checked its supplier carefully without being able to see that its neighbors share it.

The useful response is regional. Agencies can share their lists of event-critical vendors with neighbors and with the state fusion center, so overlaps become visible. A fusion center is a state or regional hub where federal, state and local agencies share information about threats; it is a natural meeting point for this kind of coordination. Agencies can agree in advance who will contact a shared provider during an incident, and how findings will be passed along, so one vendor is not fielding a dozen uncoordinated calls. They can also ask each critical vendor directly about event staffing, escalation contacts and how it would notify customers.

These are inexpensive steps. They depend on someone, usually a state or regional body, being willing to convene them. And they pay off long after the event, because the same shared dependencies exist on an ordinary Tuesday.

Why the mayor’s office owns part of this

A mayor, county executive or city manager cannot hand the whole subject to the IT department as a technical matter, for reasons that have nothing to do with technology.

Money. Recovering from ransomware is expensive, and the costs land in unbudgeted places: overtime, emergency contractors, replacement hardware and lost fee revenue while payment systems are down. A parking system that fails on match day loses real income on the busiest days of the year.

Trust. Residents judge their government by whether things work. Visitors judge a city by its first impression. A fraud wave that uses the city’s name, or a 311 line that never answers, erodes confidence in ways that outlast the event.

Accountability. When something fails in public, elected officials, oversight bodies and the press will ask who owned the risk and what was done beforehand. “We assumed the stadium security covered it” is a poor answer.

Staff. The people who run these systems were working through five weeks of elevated demand. Plans that are clear, practiced and realistic protect them from improvising under pressure.

Four owners who actually meet

Sound preparation in this space tends to share a few features. It names an owner for each of the four areas, and those owners meet. It produces short, usable artifacts: a list of event-area OT systems and their maintainers, a single page of official public channels, a tested 911 reroute plan and a shared vendor list. It treats drills as essential rather than optional. And it agrees on who speaks to the public, and through which channels, before anything goes wrong.

The failures are just as consistent.

• Assuming someone else has it. Each department assumes the central IT team or the federal partners are covering the risk. Often no one is.
• Planning only for attackers. Teams prepare for a hacker and forget that sheer volume can break a system just as thoroughly.
• Untested fallbacks. Manual procedures exist on paper but have never been rehearsed with the staff who would use them.
• Too many official channels. Different departments publish different links, which teaches visitors that any official-looking link is plausible.
• Treating it as a one-off. The work is filed away when the event ends instead of being folded into standing programs.

Where a host city is most exposed

Nobody needs to understand how a traffic controller is wired to ask sharp questions. These are a good start, whether a city faces a major event or simply wants to know how ready it is for the next storm.

• Which of our public-facing websites and phone lines would get the most traffic during a major event, have we tested them at that volume, and who decides which features to switch off under strain?
• If a lookalike website started collecting payments in our name tomorrow, how would we find out, and how quickly could we warn the public?
• Do we have one list of every traffic, transit and building control system in the area that matters, with a named person responsible for each, and can we cut vendor remote access without stopping those systems?
• If our 911 center went offline at 8 p.m. on a Saturday, where would calls go, could dispatchers work without CAD, and when did we last test both?
• Which of our critical vendors do our neighbors also use, and who would call them first in an incident?

Bringing the four parts together

The four parts have different owners and budgets, which is why they tend to be planned unevenly. Digital services, transportation, public safety and procurement rarely sit in one governance meeting. Each has its own leadership, vocabulary and priorities, and each can reasonably believe the risk sits somewhere else.

The host regions that brought them together for the World Cup also built a working group they can reuse for the next large event or the next regional emergency, which may be the most valuable result of all. A tournament provides a deadline, a budget justification and a reason for busy people to sit in the same room. The relationships and inventories it produces are just as useful when the threat is a hurricane, a regional power outage or a vendor failure on an ordinary weekday.

With hindsight

The tournament ended without a disruptive cyberattack on a US host-city government being widely reported during the matches, as far as public reporting shows. Security firms had warned beforehand of fraud, hacktivist denial-of-service activity and ransomware aimed at hospitality and ticketing.

The news is good, but it needs careful reading. The absence of a public incident does not prove the plans were tested, and many after-action reviews will stay internal. An uneventful tournament could mean the preparation worked. It could also mean attackers chose other targets, or that smaller problems were handled without anyone outside the agency noticing. Officials should resist the temptation to declare victory and move on, because “nothing bad happened” is a weak basis for next year’s budget decisions.

What carries forward is the planning itself. Inventories of event-area operational technology, rehearsed 911 continuity procedures, shared vendor lists and regional contact trees do not expire when the crowds leave. The traffic controllers are still in their roadside cabinets. The 911 center still depends on carriers and software vendors it does not control. Neighboring counties still buy from the same suppliers. All of the risks the World Cup made visible remain in place on an ordinary day.

Agencies that folded this work into standing programs are better placed for storms, outages and the next large event. In practical terms, that means keeping the OT inventory current as equipment changes, repeating the 911 rerouting drill on a regular schedule, keeping the regional vendor list alive and holding on to the cross-department working group that the tournament brought together.

There is also a human dimension. The staff who ran operations during those five weeks now carry knowledge no document fully captures: which systems strained, which procedures were clumsy, which partners answered the phone. Host agencies would be wise to write down their own findings while the staff who ran operations are still in place. Elsewhere, the riskiest part of a big event is often the ordinary services around it rather than the event itself, and those services deserve an owner every day of the year.