Data dive: Mapping the UK public sector’s hyperscale dependence

The investigative pipeline

To map these digital boundaries, Computer Weekly used a four-stage passive reconnaissance data pipeline that gathered architectural data without touching internal servers.

The first stage utilised a custom DNS reconnaissance gatherer to iterate through 29 major entities. By performing queries for A, AAAA, MX, TXT and NS records, the tool mapped the public-facing perimeter of these organisations (see “research methodology” below). These records provide a “Who’s Who” of the digital supply chain. MX records identify the “mailrooms” (email gateways), TXT records reveal authorised software-as-a-service (SaaS) senders, and A/AAAA records define the “property lines” – the specific IP addresses where government services reside.

This was supplemented by Certificate Transparency (CT) logs, a public registry of every security certificate issued on the internet. These logs often reveal “hidden” subdomains or internal testing portals that standard DNS queries might miss and provide a more granular view of third-party integration.

The subsequent stages processed this raw data through an RDAP ownership resolver to identify the physical network blocks behind the IP addresses. Finally, an interpretive classifier used heuristic pattern-matching to tag infrastructure with specific suppliers and jurisdictions to calculate an “entanglement score” to quantify the concentration of third-party risk.

The hyperscale triopoly

Our analysis uncovered a total of 2,823 infrastructure connections across the public sector sample. The results confirm dependence on a narrow corridor of hyperscale environments. The digital footprint is dominated by just three providers: Microsoft Cloud (466 connections), Google Cloud (264), and Amazon Web Services (137).

The big three hyperscalers are not interchangeable commodities. The research indicates a distinct functional split. So, while Microsoft acts as a “full-stack” partner – anchoring public-facing transit (DNS and routing) and internal identity management – other providers have other specialised roles. 

For example, Google’s footprint is heavily weighted towards the identity and application layer that handles domain verification and secure authentication, rather than acting as a primary traffic gateway. 

That means government departments don’t merely use these clouds; they are structurally embedded into specific, non-interchangeable levels of their operational stack. That means resilience is rarely achieved by simply mixing suppliers, as each provider controls a separate, unique link in the infrastructure chain, creating “silos of failure” rather than true redundancy.

Beyond the “big three”, the research identified a secondary layer of specialised technology providers that handle critical operational tasks:

• Content delivery and performance: Infrastructure from Cloudflare (present in 14 entities surveyed), Akamai (7), and Fastly (7) acts as a distributed “caching layer”, absorbing incoming traffic and protecting against distributed denial of service (DDoS) attacks.

• Ecosystem integration: Apple Enterprise (16) provides the underlying infrastructure for mobile device management and ecosystem services.

• SaaS operations: Critical business workflows are managed through Salesforce (7) and ServiceNow (5).

• Cyber security gateways: Specialised email inspectors like Mimecast (4) and Proofpoint (2) act as the primary defence against phishing and malware before data reaches the internal server.

Only one of these companies – Mimecast – is not headquartered in the US.

While individual departments gain efficiency, the aggregate view potentially presents a picture of operational fragility. When hundreds of independent government functions share the same underlying physical infrastructure, traditional concepts of redundancy can be nullified.

The sovereign core

The data also identified 1,894 connections attributed to internal or localised government infrastructure. These represent the core of physical servers, private circuits and authoritative name servers that government departments still own directly, often hosted in datacentres such as Crown Hosting.

But entanglement with US hyperscalers and other providers means this core is vulnerable. Government and local authorities hold the keys to the rooms in their digital house, but have outsourced the front door, letterbox and lighting to commercial landlords. Should a hyperscaler suffer an application programming interface (API) failure or a regional outage, for example, the internal infrastructure could become cut off from the public.

The attack surface of convenience

By aggregating services into hyperscaler nodes, the public sector has created a so-called “attack surface of convenience”. This introduces four primary structural risks identified by our architectural analysis:

1. Single point of failure: Centralisation in routing means that if a single supplier like Cloudflare or Microsoft experiences a significant outage, an entity’s ability to resolve its own domain names or receive emails can be completely severed.
2. The visibility gap: If internal teams treat commercial gateways as “black boxes” and these external providers are compromised – as seen in supply chain attacks like that of SolarWinds – the attackers potentially gain a “golden key” to communication streams that can be invisible to internal monitoring tools.
3. Configuration brittleness: Secure architecture requires redundancy. The data shows departments using a single supplier for both email security (eg, Mimecast) and DNS hosting. This creates a situation where an attacker that gains administrative access to one can potentially hijack the entire domain identity.
4. The jurisdictional trap: Our research indicates that 96.55% of surveyed entities are subject to US jurisdictional risk. Because they rely on suppliers subject to the US Clarifying Lawful Overseas Use of Data (Cloud) Act and Foreign Intelligence Surveillance Act (FISA) section 702, their data – and access logs that show who viewed that data – reside in a foreign legal jurisdiction. US agencies could theoretically issue a secret warrant to access these communication gateways without UK authorities ever being notified.

A tale of two models

The degree of “entanglement” varies significantly across the sample. The Department for Transport, for example, is one of the least entangled, with 79% of its identified digital footprint within a single supplier’s ecosystem (Google Cloud). While this provides seamless integration and a single control plane, a single supplier dispute or technical failure could paralyse the entire department.

In contrast, other entities follow a hybrid model that provides resilience by way of diversification. While this reduces the risk of a single point of failure, it introduces “integration debt” – a more complex environment that is harder to secure and audit across multiple distinct security policies.

One of the leanest footprints identified was the Department for Energy Security and Net Zero (DESNZ). This could be a clean slate advantage. As a relatively new department, DESNZ has not yet accumulated the legacy debt seen in older organisations – the archived websites, forgotten subdomains and abandoned third-party integrations that inflate the digital footprint of more established departments.

The strategic crossroads

As departments move beyond simple storage and into integrated as-a-service models, the technical gravity of major providers increases. The cost of exit – in terms of financial spend and technical debt – becomes prohibitive.

The risk is that without meaningful diversification of the digital boundary, the resilience the cloud was intended to provide may become a casualty. The UK risks a future where its essential services operate at the mercy of a global infrastructure triopoly, bound by foreign laws and shielded by commercial black boxes.

Research methodology 

To map the digital boundaries of the UK public sector, Computer Weekly used a data extraction pipeline built for passive reconnaissance. The primary dataset was built by identifying registered domains for 19 government departments and 10 local councils.

Analysis stages

• DNS data gathering: Iterated through target entities to perform DNS queries (A, AAAA, MX, TXT, NS records) that mapped the perimeter and identified authorised mail routers and SaaS providers.

• RDAP ownership queries: Processed raw DNS data to identify physical network blocks (IP ranges) behind the domains, to determine which organisations actually own those network segments.

• Interpretive classifier: Used pattern-matching to interpret technical data into business categories, to identify suppliers and assess legal jurisdictions.

• Dependency tree generator: Transformed enriched data into a visualisation of the relationship between root organisations, subdomains and external suppliers.

Key definitions

• MX records: Direct email to responsible mail servers.

• TXT/SPF records: List authorised third-party suppliers allowed to send email on behalf of the domain.

• A/AAAA records: Map domains to physical server locations (IPv4/IPv6).

• NS records: Identify the authoritative name servers in charge of the domain’s records.

• Entanglement score: A metric of digital risk calculated by dividing unique supplier connections by the total infrastructure footprint.