Posted in

What does it take to build a SEAL‑4 hyperscale cloud, and is it worth it? – Part 3: Infrastructure (the hardware)

In part 1, I laid out the Cloud Sovereignty Framework (CSF) and discussed whether a SEAL‑4 hyperscale cloud is needed at all, and for whom. I then explained how I would look in more detail at building and operating a hyperscale cloud. In part 2, I started with the bottom layer: the data centers.

In this part, we climb one layer up, to the infrastructure: the compute, storage and network hardware in the data centers. And this is where the framework really becomes interesting. This is the layer where supply chain sovereignty (SOV‑5, the most heavily weighted objective in the CSF at 20%) turns from an abstract concept into a hard map of factories, machines and patents. On that map, Europe is still mostly a bystander.

As promised, for each layer I will address the same two questions: what does the supply chain look like when you build it, and when you operate it?

The supply chain when building

A modern server looks like a box of parts, but in reality it is the endpoint of an extremely complex supply chain consisting of several parts:

  • Electronic Design Automation software: This is the toolkit used to design chips. The market leaders are Synopsys (US), Cadence (US), Siemens EDA (Germany).
  • Instruction sets: Without instructions a chip does nothing, so the intellectual property of the instruction set matters. x86 is under the shared control of Intel and AMD (both US), Arm belongs to Arm Holdings (UK, but with a Japanese owner). RISC‑V is an open standard but does not yet have a mature ecosystem. This is potentially where Europe should focus.
  • Chip design: Chips are designed by Nvidia, AMD, Intel, Ampere, Broadcom, plus the hyperscalers’ own chips (AWS Graviton/Trainium, Google TPU, Microsoft Maia/Cobalt). This is therefore largely American.
  • Fabrication: The actual production of chips takes place at TSMC (Taiwan), Samsung (South Korea) and, to a lesser extent, Intel (US). Memory (DRAM, HBM) comes from Samsung, SK hynix and Micron (Korea, US).

Making this chain SEAL‑4 compliant is an enormous undertaking that requires a great deal of investment and persistence. But there is another crucial part of the chain…

The role of ASML

In part 1, I already mentioned it briefly: the Netherlands has a huge trump card in ASML. Time to turn that card over and look at it properly, because ASML is the best proof that “sovereignty” and “dependence” are two sides of the same coin.

ASML is the only manufacturer in the world that can supply EUV lithography. These are the machines used to make the advanced chips that every modern GPU and CPU needs. Not the biggest, not the best: the only. Without ASML, the fabs of TSMC and Samsung come to a standstill. ASML comes close to a monopoly.

The EUV systems ASML makes consist of hundreds of thousands of components. The optics come from Carl Zeiss SMT (Germany). These are mirrors polished so perfectly that deviations are measured on the scale of an atom, and Zeiss has a de facto monopoly on them. The technology for hitting droplets of tin fifty thousand times per second with a laser to create plasma comes from Cymer (American, but owned by ASML) and Trumpf (German). ASML’s machines are therefore more than a product, they are an ecosystem built over two decades. That is not something you replicate just like that (more on that later).

Now for the nuance, because this is where it becomes interesting for the framework. The fact that ASML is Dutch does not mean that Europe has sovereign compute. ASML sells its machines to TSMC in Taiwan and Samsung in Korea, and they fabricate chips designed by Nvidia (US) with American EDA software on a British or American instruction set. So ASML is only one link in a chain that is otherwise overwhelmingly non-European.

It does show that dependence works both ways, exactly as I touched on in part 1. The whole world needs Europe for the upper end of the chip chain just as much as Europe needs the rest of the world for the lower end. That is not sovereignty, but it is bargaining power. In a geopolitical game, a credible trump card at the negotiating table is worth more than dogmatically pursued autarky that economically does you in. The recent reports that China is taking its own DUV machines into production (July 2026) immediately show how vulnerable even a monopoly is once someone is willing to throw tens of billions and a decade (or two) at it. A lead is not eternal property.

The honest conclusion for the build question: at the hardware layer, a SEAL‑4 chain simply cannot be built today. Not because Europe is stupid or lazy, but because the chain is physically spread across Taiwan, Korea, the US and Japan, and it takes years to decades to duplicate those links, if it can be done at all. The European Processor Initiative and the bet on RISC‑V are serious attempts to catch up, but it will truly take a great deal before they can offer hyperscale volume and performance. The framework reports that honestly, and that is precisely its value: it does not lie about where we stand.

Open Compute Project

If the chips themselves are the most difficult layer, then the way hyperscalers forge those chips into servers, racks and networks is actually the most surprisingly open. That is because of the Open Compute Project (OCP).

OCP was founded in 2011 by Facebook (now Meta), which decided not to treat its server designs as trade secrets but to make them public. The idea: if everyone uses the same open specifications for motherboards, power supplies, racks, cooling and network switches, then hardware becomes a commodity, prices go down and quality goes up. Microsoft, Google and almost every serious player contributed their own designs. Much of what makes a hyperscaler “hyper” on the hardware side (racks, disaggregated storage, hot swappable everything) is publicly available through OCP.

For the sovereignty debate, that is an ambiguous gift. On the one hand, it lowers the threshold enormously: a European party that wants to build a hyperscale base does not have to reinvent the wheel. The designs are ready. You do not have to figure out how to build an efficient rack; that is a solved problem. Ironically, the current European providers hardly use OCP and with that, they are not reaping the benefits of the latest innovations and (cost)efficiencies, even though the hardware isn’t coming from Europe (yet).

However, open hardware solves exactly nothing about the problem of a pure European supply chain: OCP is a collection of open specifications, but not a factory. Sharing the blueprint is free, but production remains the bottleneck. Where OCP has done something in recent years that really matters for sovereignty is security, which brings us to operations.

The supply chain when operating

Suppose that, by magic, you could source all your hardware sovereignly. Even then there is a risk that is separate from where the chip comes from: has it been tampered with along the way? A server passes through dozens of hands (including factory, assembly, transport, distribution, installation) and at each of those points someone could in theory add a malicious component or replace a firmware image. This is the classic nightmare of the “hardware implant”, made famous years ago by a controversial story (denied by all parties involved) about a spy chip on server boards. Whether that specific story was true or not, it woke the industry up in one blow: firmware and hardware that you cannot verify should not be trusted.

Here is an important distinction that often gets mixed up in the sovereignty debate: origin (where was it made — the SOV‑5 question) is different from integrity (has it remained untouched along the way). The framework emphasizes origin, but in daily practice integrity is often the more relevant security question. And the good thing is that you can enforce integrity, regardless of where the components come from.

That is exactly what the hyperscalers do at enormous scale, with an approach called “hardware root of trust”. Project Cerberus (Microsoft), Nitro (AWS), and Titan (Google) are all variants of this. They provide hardware root of trust with an identity that cannot be cloned, that checks every firmware image on the server before boot and refuses to boot if even a single bit is wrong. Because the hardware root of trust is cryptographically verified, you do not have to trust the supplier. You trust the mathematics.

And here OCP comes back into view, because this root of trust does not have to be a closed trade secret. Caliptra is an open source silicon root of trust: a specification, silicon logic, ROM and firmware for an integrated trust block, intended for data center class chips such as CPUs, GPUs, DPUs and TPUs. In other words: the recipe for verifying that your hardware has not been tampered with is openly on the table. Through the OCP Security working group (with initiatives around secure firmware and attestation), this is gradually becoming a shared standard.

Why is this so important for the sovereignty story? Because it shows that the most concrete security measure at the hardware layer, knowing that your equipment has not been tampered with, does not depend on SEAL‑4 origin. You can put a chip from Taiwan into a server and still have mathematical certainty that the firmware is untouched. A country that fixates on “where does the chip come from?” while failing to set up root of trust and attestation has solved the wrong problem. That is exactly the same design flaw I described in part 1: defending against a legal or origin risk while letting your actual security slide.

What does this mean for SEAL‑4?

The hardware layer is where the CSF bites hardest and where Europe has the least say. Origin sovereignty is simply unattainable here today. Most of the chain is overwhelmingly non-European, and even our greatest trump card, ASML, mainly proves how internationally interwoven the chain is.

But there are two bright spots in this gloomy story, and both fit the risk management lens from part 1:

First, thanks to OCP, the hardware base of a hyperscaler is surprisingly open and therefore in principle reproducible. The problem is not the design, but the investments and time needed to produce the required elements at large scale and with high quality.

Second, hardware integrity can be achieved without sovereign origin. For many critical systems, that is the security that really matters. That means origin only becomes a problem if delivery can no longer happen or is no longer allowed, and there is no kill switch on infrastructure already taken into use.

So the lesson remains the same as in the previous parts: use the Cloud Sovereignty Framework to see where the gaps are, but do not apply it dogmatically, because then you are in for a rude awakening. Enforcing a SEAL‑4 requirement at the compute layer today simply means you do not have a modern hyperscale cloud, full stop.

The next question is whether we should do something about that. If we really want to, then policy must be made that solves this over the coming decades. Such policy would be enormously ambitious and would require investments that, if necessary, are even more ambitious. For now, in any case, it is wise to cherish ASML as a strategic trump card.

In the next part, we climb one layer up again, to the platform: the control plane that automates, orchestrates and secures all that hardware. This is the layer where hardware becomes a cloud, and where sovereignty takes on a very different face.