2026 World Cup cyber risk exposes the limits of perimeter security

At a glance

What this is: The article argues that the 2026 World Cup will be a large, interconnected cyber target where the weakest supplier, contractor, or partner can become the entry point for broader disruption.

Why it matters: It matters because IAM, PAM, third-party risk, and resilience teams must govern access and trust across a multi-organisation ecosystem rather than assume perimeter controls are enough.

By the numbers:

• The 2026 tournament will span three nations and 16 cities.
• NTT Corporation recorded approximately 450 million cyberattack attempts targeting Olympic systems during the 2020 Tokyo Olympics, held in 2021.
• The 2026 World Cup will involve millions of projected visitors.

👉 Read SecurityScorecard's analysis of cyber risk across the 2026 World Cup ecosystem

Context

The primary security problem is not the tournament itself, but the ecosystem it creates. When governments, transport operators, telecoms providers, hospitality firms, broadcasters, sponsors, vendors, and technology platforms all depend on one another, attackers do not need to breach the most visible target first. They only need one weak link in the broader chain.

For identity and access teams, this is a governance problem as much as a cyber one. Third-party access, contractor onboarding, shared operational dependencies, and inconsistent privilege controls all become more dangerous when the event spans borders and multiple trust domains. That makes supplier visibility, access review, and offboarding discipline central to resilience, not peripheral tasks.

Key questions

Q: What breaks when third-party access is not tightly governed in large event ecosystems?

A: When third-party access is not tightly governed, attackers can use the weakest supplier or contractor relationship to reach core operations. The result is usually not a direct breach of the primary organisation first, but uncontrolled lateral exposure across shared systems, fragmented accountability, and slower containment. In event environments, that can disrupt ticketing, payments, logistics, and emergency coordination at the same time.

Q: Why do large events create such a difficult risk picture for identity and access teams?

A: Large events multiply trust relationships across borders, organisations, and technology stacks, which makes identity governance harder to see and enforce. Teams must manage direct users, temporary workers, vendors, and downstream dependencies at the same time. That complexity makes access review, privilege scope, and offboarding discipline critical, because the number of identities involved is much larger than most organisations expect.

Q: How do security teams know whether third-party risk controls are actually working?

A: They know controls are working when they can continuously identify every external party with access, show who owns that access, and revoke it quickly when the relationship ends or the risk changes. If the inventory is incomplete, if shared accounts remain active, or if offboarding depends on manual memory, the control is not working in practice.

Q: Who is accountable when a supplier compromise disrupts a multi-organisation event?

A: Accountability usually sits with the organisation that granted the access, the partner that failed to protect it, and the business owner who accepted the risk without a clear control boundary. Frameworks such as NIST CSF and third-party risk governance approaches expect defined ownership, documented escalation, and provable control over external access. Shared operations do not remove accountability.

Technical breakdown

Why ecosystem exposure creates attack paths beyond the main target

A major event creates a federated attack surface made up of many independent organisations, each with its own tools, controls, and maturity. Adversaries often target the least protected partner because access through a supplier, contractor, or service provider can bypass the stronger controls of the primary organisation. The risk increases when different entities share operational data, ticketing systems, payment flows, or communications infrastructure. In identity terms, the problem is not only exposure, but trust delegation across multiple domains without uniform governance.

Practical implication: map third-party access paths and review who can reach core event systems before the event begins.

How visibility gaps turn third-party risk into operational blind spots

Visibility means knowing which organisations, accounts, services, and technology dependencies actually support the event. Many teams underestimate the number of vendors involved because they see only direct contracts, not sub-contractors or hidden digital dependencies. That blind spot makes it hard to judge where credentials live, who owns them, and whether access is still required. In an ecosystem this large, unmanaged or poorly documented access becomes a governance failure, not just a monitoring issue.

Practical implication: maintain a continuously updated inventory of vendors, service accounts, and privileged connections tied to event operations.

Why resilience depends on control, not just prevention

Resilience is the ability to anticipate, withstand, and recover from disruption, even when an attacker gets through. For large events, that means combining threat intelligence, third-party risk data, and operational playbooks so teams can decide which exposures require immediate action. The article’s core point is that security is measured by how well the ecosystem keeps functioning under pressure, not by whether attack attempts occur. That applies directly to IAM because access governance is one of the few levers that can reduce blast radius across partner organisations.

Practical implication: test containment, escalation, and access-revocation playbooks across vendors and jurisdictions before peak event activity.

NHI Mgmt Group analysis

Perimeter-first security is the wrong model for mega-events. The article shows that the real attack surface sits in the interconnected ecosystem around the event, not inside one organisation’s own network. That means a supplier, contractor, or managed service dependency can become the operational entry point even when the primary target is better defended. For identity programmes, this is a reminder that trust chains extend beyond formal ownership boundaries. Practitioners should treat delegated access as a governance asset that needs lifecycle control, not a static integration.

Third-party visibility is now an identity control, not just a risk dashboard feature. SecurityScorecard’s point about organisations discovering far more vendors than they expected maps directly to access governance failures. If teams cannot identify every external party with operational access, they cannot enforce least privilege, review standing access, or validate offboarding. The named concept here is ecosystem access opacity: the inability to see which external identities and dependencies can reach critical systems. Practitioners should close that visibility gap before they try to optimise anything else.

Event resilience depends on reducing blast radius across organisational boundaries. The article correctly shifts the resilience conversation away from pure prevention toward anticipation and recovery. In practice, that means identity controls must support containment when a partner is compromised, including fast revocation, scoped access, and clear ownership of shared accounts. Without that, one weak link can create a cross-organisation disruption path. Practitioners should design for containment first, then continuity.

Large events expose the governance weakness of informal access arrangements. Temporary contractors, local partners, logistics teams, broadcasters, and technology vendors often receive access under time pressure, which encourages exceptions and manual approvals. Those shortcuts may be tolerated for short periods, but they become risky when scaled across three countries and thousands of participants. That pattern is relevant to IAM, PAM, and third-party access governance alike. Practitioners should assume exception creep unless they build explicit controls around it.

Security teams should read this as a warning about trust sprawl. The article’s broader lesson is that modern operations depend on many more trusted relationships than traditional security models assume. As the number of external dependencies grows, so does the probability that an attacker will use the softer one to reach the harder one. The practical conclusion is straightforward: reduce unnecessary trust, document the rest, and verify continuously.

What this signals

Ecosystem access opacity will become a more common failure mode as major events and distributed operating models continue to expand the number of external identities in play. For identity teams, the practical problem is not whether a vendor exists, but whether its access is visible, owned, and removable on demand. That is why continuous third-party inventory and revocation testing should be treated as baseline governance, not project work.

The article’s resilience framing is directionally correct for IAM and PAM leaders. If access decisions are made once and then left to drift across multiple organisations, the control model cannot keep up with the real exposure window. The stronger approach is to treat access as a living dependency, aligned to the operational period of the event and monitored through its full lifecycle.

This also reinforces a broader governance point: identity controls increasingly define operational resilience. The same principle applies beyond sporting events, because any ecosystem with contractors, sub-processors, and shared digital services can accumulate hidden trust paths. Practitioners should use this as a trigger to tighten offboarding, review standing access, and validate who can still reach critical systems after the initial contract is signed.

For practitioners

• Inventory all external access paths Build a complete list of vendors, contractors, managed service providers, and sub-processors with access to event-related systems, including hidden or inherited dependencies. Reconcile the list against contract records and system logs so you know who can actually touch operational assets.
• Tighten lifecycle control for delegated access Review temporary accounts, shared credentials, and partner integrations for expiry, offboarding, and ownership. Remove standing access where it is not required and define a revocation path that works across jurisdictions and organisations.
• Test containment across partner boundaries Run joint exercises that assume a supplier or contractor is compromised and validate how quickly access can be revoked, routes isolated, and critical operations kept running. Include communication and escalation decisions in the exercise, not just technical containment.
• Prioritise the highest-value operational links Rank vendors and dependencies by the systems they can reach, the data they handle, and the business function they support. Focus first on payments, ticketing, logistics, broadcast, and emergency-response dependencies because those paths create the biggest operational blast radius.

Key takeaways

• Major events create ecosystem risk, not isolated risk, because attackers can move through the weakest partner instead of the primary target.
• Visibility into external access and delegated trust is the control gap that decides whether disruption stays local or cascades across operations.
• Identity governance, especially access review, revocation, and offboarding, is now a core resilience discipline for event-scale ecosystems.

Key terms

• Third-Party Risk: Third-party risk is the possibility that a vendor, contractor, or service provider creates exposure for the organisation that relies on it. In practice, it covers access, data handling, operational dependencies, and the security maturity of connected partners.
• Ecosystem Access Opacity: Ecosystem access opacity is the inability to clearly see which external organisations, accounts, and services can reach critical systems. It becomes a governance problem when hidden dependencies, inherited access, or undocumented integrations prevent teams from enforcing least privilege or timely offboarding.
• Delegated Access: Delegated access is access granted to another party to perform a task, operate a service, or support a business function. It is often necessary, but it becomes risky when ownership, expiry, and revocation are not tracked with the same discipline as internal access.

What's in the full article

SecurityScorecard's full article covers the operational detail this post intentionally leaves for the source:

• How the company detects previously unknown vendors and shadow dependencies across an external ecosystem.
• The specific way threat intelligence and third-party risk data are combined to prioritise which exposures need action first.
• Why continuous monitoring matters when the vendor landscape changes faster than a periodic review can capture.
• How operational teams can separate meaningful signals from background noise during a high-profile event.

👉 SecurityScorecard's full article covers the third-party exposure, resilience model, and ecosystem monitoring detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need stronger control over delegated access. It is suitable for identity, security, and risk professionals building lifecycle governance across complex environments.