As promised, I ask the same two questions here as well: What does it take to build and what does it take to operate?

What does the platform actually do?

The platform is not one thing. It is useful to make the distinction between control plane and data plane. The data plane is where the work happens for customers. This is where their virtual machines, storage, network, and so on live. The control plane is the operating system of the cloud itself. It processes requests such as “give me four VMs with these specifications in this region”, looks for capacity, sets up the networks, connects the storage, keeps track of the desired state and intervenes if reality deviates from it. The control plane also includes systems for access control, logging, monitoring, encryption and much more to keep the cloud running and secure.

The distinction between control plane and data plane is not a technical detail. The data plane is where customer data lives and where each customer has control over their own environment. The control plane, on the other hand, is under the control of the cloud provider and must be set up in such a way that the cloud provider does not have access to customer data. Or at least that if it is unexpectedly necessary, that this is done in a controlled manner and an audit log is made of it, so that all actions are traceable. This is important to be able to find out what went wrong or how a leak could have occurred in a (security) incident, but also because it can be demonstrated that all kinds of laws and regulations are complied with, and global, local, or industry certifications such as ISO 27001 and 27018, SOC 1 to 3, BIR 2012 (NL), PCI-DSS and SOX. Hyperscale clouds have many such certifications, making them among the most audited systems on the planet.

The fact that clouds are audited so much is extremely important. Because whoever controls the control plane, controls the cloud. That means cloud providers need to be able to demonstrate that they’re doing everything they can to keep their customers’ systems up and running during all kinds of incidents and protect them from cyberattacks, without seeing customer data unless strictly necessary. And this is where in the sovereignty debate the question is asked, “who can turn off my services?” This is actually about the platform layer and largely about SOV3 and SOV6 from the framework, about operational autonomy and management.

Virtualization: where the platform relies on the infrastructure

The platform virtualizes the infrastructure, but it can only do so safely by relying on what is in the hardware in terms of security. That is the direct continuation of part 3.

The hardware root of trust I described there (Cerberus, Nitro, Titan, and in open form Caliptra) verifies the firmware before the machine boots up. The platform builds on this with measured boot: each link in the start-up chain measures the next and records that measurement, so that the hypervisor only runs when it is proven that nothing has changed along the way. Without that hardware layer, a secure hypervisor is an assumption; With that layer, it is a cryptographically verifiable fact. That’s why you can’t buy these layers separately: a sovereign platform on unattested hardware is a lock on a door without a wall.

The same applies to the insulation between customers. The hypervisor separates VMs from each other, but relies entirely on memory protection in the processor. And the modern step further, Confidential Computing, goes one level deeper. With technology such as AMD SEVSNP and Intel TDX, a VM’s memory is encrypted with a key that the hypervisor itself does not have. The administrator of the platform can start, stop and move the machine, but not look into memory.

In the sovereignty debate, this received less attention than it should. The fear behind SOV2 and SOV7 is that someone with management rights (or someone who legally enforces those rights) can access your data. Confidential Computing technically removes exactly that possibility. It’s the same reasoning as with hardware integrity in part 3: you don’t have to trust the administrator if the math takes over. It doesn’t make provenance irrelevant, but it shifts the question from “who owns it” to “who can technically access it”, and that’s the question that matters in practice.

A third piece that is often forgotten: with hyperscalers, a growing part of the control plane no longer runs on the server’s CPU at all, but on separate hardware. Network virtualization, storage traffic and security rules are handled there, physically separated from the environment where the customer runs his code. This means that there is no software from the customer that runs on the same processor as the management layer. That’s architecture as security, and it’s one of the clearest examples of what scale gives you: you can only develop a map like that if you use hundreds of thousands of them.

Access: how to make sure no one has too many rights

Now the question that in my opinion touches the heart of this layer. Because if the control plane is the power, then the human being with access to the control plane is the risk.

The reflex in small organizations is a group of trusted administrators with broad rights, screened and of impeccable behavior. That works, until someone makes a mistake, until someone’s account is taken over, or until someone is put under pressure. Screening protects against bad intentions, not stolen credentials, and most incidents don’t start with a malicious employee but with a compromised legitimate session.

Hyperscalers solve this structurally differently, and the principle is confrontationally simple: by default, no one has rights. No engineer has permanent access to production. What it says instead is a pile of measures that work together:

• Just-in-time access – Access is requested for a specific task, a specific system and a limited duration, with an explicit reason associated with a ticket or incident. Afterwards, access expires automatically. A compromise of an engineer account therefore yields nothing at any time, because there is nothing attached to it.
• Approval by another person – Sensitive actions require a more or less randomly chosen second person to approve the request. This is not bureaucracy but the same principle as two keys to a safe: one person cannot gain access on his own.
• No human access to customer data – The management interfaces are designed so that an engineer can do diagnostics without seeing the content. Where that is unavoidable, there is an explicit, approved and logged procedure around it, and in Confidential Computing it is technically excluded.
• Break-glass as an exception, not as a backdoor – There is always an emergency procedure, but its use sets off alarms, can be fully reconstructed afterwards and is examined as standard.
• Not people at the controls, but code – This is perhaps the most important and at the same time the least understood. Management is not done by logging in and typing commands, but by offering a change to an automated pipeline: code review, automated testing, phased rollout across zones and regions, automatic rollback in case of anomalous signals. The engineer has no rights to the system; the pipeline has them. This means that every change is by definition assessed, logged and traceable to a person and a reason.

What you see here is that “no one with too many rights” is not a matter of trust, but of design. And here is an uncomfortable point for the sovereignty discussion. The requirement that you often see in tenders, “only EU staff with EU nationality should have access to management”, measures nationality. What really matters is whether there is anyone at all who can do something without a second person, without a ticket, without logging and without a time limit. A small sovereign “cloud” with ten fully Dutch administrators who have permanent root rights is arguably more vulnerable than an environment where no one has standard rights, regardless of passport.

And there is another operational aspect to this. If you can guarantee access in this way, it is possible to have administrators all over the world, which is a great advantage for 24×7 operation, because it allows you to reduce costs (for example, no extra costs for night shifts) and allow the best experts in the world to perform operations in a safe, controlled manner.

Automation and Monitoring: Crucial to scale and scale is crucial

In part 1 I wrote that the security signal from a hyperscaler is global and that a protected national island only sees a fraction of it. At the platform layer, it becomes clear why that matters so much, because it is precisely automation and monitoring that reinforce each other here.

Monitoring without automation produces alarms that have to be handled by humans. That doesn’t scale. More systems means more alarms means more noise means alarm fatigue, and alarm fatigue is how real incidents are missed. Automation without monitoring is blind. You roll out errors as efficiently as improvements. And this is also why the telemetry is so crucial. It builds the feedback loop that enables constant improvement.

The combination is what makes the difference. With a hyperscaler, the platform itself is the source of truth. It knows exactly which configuration is supposed to run and any deviation from it is by definition suspicious. A server that deviates from the norm is not examined but automatically taken out of rotation and rebuilt. A pattern of behavior that is different (a management account calling an unusual API at an unusual time) is detectable precisely because the normal behavior is so tightly defined.

On top of that, the volume argument comes up, and that’s not marketing but statistics. Detection of anomalous behavior requires a reliable picture of normal behavior. The more signal, the sharper that image and the smaller the deviation that you can still reliably notice. An environment with a thousand servers sees too little to lift subtle patterns above the noise. An environment with millions can see them, and can roll out a detection rule that works for one customer worldwide within minutes. The same goes for patching. With fully automated fleet management, the entire fleet can be updated in hours to days, with proof that it has happened everywhere. With (partly) manual patching, this takes much longer and evidence must be collected.

And then there is the personnel argument, which I already touched on in part 1. A security team that has to provide 24/7 coverage, with holidays, illness and turnover, easily needs eight to ten people for one position. For a fully-fledged operational security center with detection, response, threat intelligence, forensics and red teaming, you are looking at tens to hundreds of people. For the hyperscalers, there are thousands. For a European player with a few thousand employees in total, this is not a matter of will, but of ability, in a labor market where these people are structurally scarce.

I don’t say this to write off small parties, but to show that scale in itself is a factor. To have a serious European cloud, you not only need to have the supply chain and operations under control, but scale is a prerequisite for success. This creates a chicken-and-egg problem, because the scale is needed to achieve lower costs and higher quality, but you can only achieve that scale if your cost-quality ratio is not too far out of line with what the American clouds can deliver.

The building question: what options are there?

There are several routes to build the control plane. For example, you could start with a virtualization platform such as VMWare and Nutanix, or an open source alternative to them such as Proxmox. You could also get started on the basis of Kubernetes and use KubeVirt for when you do need to support virtual machines (and you should). Since Kubernetes is open source, and also a defacto standard for cloud-native applications, there are plenty of options. But a virtualization and container platform is not yet a cloud. First, such an environment is primarily intended for one organization and not a multi-tenant environment for many organizations. Second, the control plane does more than just set up some virtualized compute, storage, and network. It’s the heart of the cloud, and there’s a rib cage around it to keep the cloud robust and secure, and to be able to offer Other Services on top. There are a number of options for this.

OpenStack is the best known. The project started in 2010 and is managed by the Open Infrastructure Foundation. It has grown into a collection of loosely coupled services: Nova for compute, Neutron for networking, Cinder and Swift for storage, Keystone for identity, Ironic for bare metal. A number of European providers use OpenStack: OVHcloud, T-Systems, Cleura and smaller national players. Its strength is its modularity and the fact that it has been proven on a large scale. The price is complexity: OpenStack is notorious for its operational heaviness, and the knowledge to keep it running at scale is a scarce and expensive commodity. It’s not a product that you install, it’s a discipline that you build.

OpenNebula is the opposite of OpenStack. It’s much simpler in design and designed to manage a significant environment with a small team. It scales well to thousands of hosts and is strong in edge and distributed scenarios. That is precisely why it is interesting for a European player that does not have the personnel depth of a hyperscaler. What it doesn’t do is deliver the breadth of services that customers expect from a hyperscaler.

Apache CloudStack falls into the same category as OpenNebula. It is a mature alternative that is mainly used by hosting providers and is considerably easier to operate than OpenStack.

The fact that these platforms are open source has the advantage that there is something to build on. But this is fundamentally different from how a hyperscaler works. In a hyperscaler, the platform software is highly integrated with the hardware, which makes the whole thing faster, more robust and safer than bringing together parts that are not compatible with each other. That is not open source, but as indicated, there are all kinds of other safeguards for customers that are perhaps more important.

The fair conclusion for the construction question: SEAL-4 is technically feasible on the platform layer. The software can be European, the code can be written in Europe, and the open projects are there. What is missing is not the blueprint, but the years of operational experience needed to make such a platform reliable at hyperscale. You can’t buy that, you have to experience it. And then you come to the operation and the supply chain.

The operation and supply chain

The fact that the platform software can be open source and thus made European is of course great. But although the software itself is important, in this layer it is mainly the constant improvements to make the operation even more robust, even safer, and with even less overhead. Open source is an important component in this, also for hyperscalers, but not the only one. The open source part consists of the Linux kernel, KVM, the container runtimes, cryptographic libraries, hundreds of packages, each with its own dependencies. Formally, this is not a SOV5 problem, because an open license has no jurisdiction and cannot be revoked retroactively. Practically speaking, it is indeed a dependency, just a different one than the framework measures. Because you can’t revoke a license, but you can lose, take over, or put pressure on the people who maintain the code.

Furthermore, it is about the operation of the shell around it: capacity planning that looks months ahead, automated rollout of new hardware without downtime, live migration of hundreds of thousands of workloads during maintenance, fault domains that are designed in such a way that a defective hardware does not affect a customer, and a control plane that is itself divided over three availability zones and forms a quorum (exactly the reason why in part 2 there were three zones and not two). That layer is not open source with the hyperscalers, and that is the real hole.

The maintainer as a critical component… and risk

This is the layer where the supply chain is not made up of factories but of people, and that makes it harder to measure and easier to ignore.

The image that most administrators have of open source is that of a worldwide mass of volunteers who check each other’s work: many eyes, so few bugs. This is also true for the largest projects. For the vast majority of what’s in your stack, it’s not right. The Census II study by Harvard and the Linux Foundation looked at the fifty most commonly used non-npm components and found that in 23% of those projects, a single developer wrote more than 80% of the added lines of code, and that in 94% of the projects, fewer than ten developers accounted for more than 90% of the code. That is the real form of this dependence. Not a country that turns off a tap, but a handful of people that keep it up. And that’s exactly what the 2024 XZ Utils incident picked up on: A contributor patiently built trust with an exhausted solo maintainer of a widely used compression library for years, took over maintenance, and put in a backdoor that would have reached into the authentication chain of virtually any Linux distribution. It was discovered because a Microsoft engineer found a half-second performance deviation when logging in too strange and started digging. Coincidence, in other words. The vulnerability was not in the code, but in the maintenance model: one overburdened volunteer on a package that half the world relies on.

For the sovereignty debate, this is more important than it seems. An EU tender may require the supplier to be European and management to be in the EU, and both ticks may be green while the critical dependency is a non-European volunteer who has no contract, no SLA and no successor. And then we haven’t even mentioned a scenario where malicious parties target the open source software supply chain. This is (fortunately) easier to detect with AI, but for the time being it is not 100% foolproof. Closed source in-house can therefore be safer in some cases.

Who really contributes?

The figures here are more confrontational than the open-source rhetoric suggests. Take the Linux kernel, the foundation of every cloud platform we’ve discussed in this section. In 2025, 84.3% of all kernel commits were written by people who are paid to do so, spread over more than 1,780 organizations. Only about 16% came from independent or non-assignable contributors. The kernel is therefore no longer a volunteer project, but an industrial partnership, and the question of who contributes is therefore the question of which companies invest in it. Google, Intel, Meta and Oracle account for more than 60% of the contributions, and on top of that are parties such as AMD, Huawei, and Red Hat.

If you zoom out to open source in general, the picture does not change. The Open Source Contributor Index, which ranks companies by the number of active contributors on GitHub, will be led by 8 US companies by mid-2026, followed by Huawei and SUSE in 10th place. If you compare those ten against each other, more than 90% of the active contributors come from American companies, about 4.8% from China and about 4.5% from Europe, and the latter percentage consists almost entirely of one company: SUSE.

With OpenStack, the platform on which the European cloud sector relies the most, the distribution is more favorable: Red Hat and SUSE are large, and European providers such as OVHcloud, TSystems, Cleura and the German SysEleven are actually contributing. But OpenStack is also a project where commercial energy has actually declined since the departure of a number of major American and Chinese sponsors, and that is not without risk if you build your entire platform layer on it. OpenNebula is one of the few truly European cloud projects with a European enterprise around it, but the contributing community is comparatively small, and that’s exactly the pattern from Census II in miniature.

One important nuance with all these figures: they measure employer, not nationality. A German developer employed by Google in Munich counts as Google in this statistic. There is remarkably little reliable data on where contributors are physically located, and that in itself is a finding: the discussion about “who writes the code we run” is being conducted without anyone having good measurement data about it. What we do know is who pays the bill, and that is overwhelmingly non-European.

What does that really mean?

I want to avoid two wrong conclusions.

The first is the panic conclusion: “the code is American, so we are not sovereign”. That’s not how open source works. The GPL and the Apache license are irrevocable for code that has already been released, and the kernel source code is in hundreds of thousands of places. No one can turn off Linux. If Intel were to stop contributing tomorrow, everything that is running will continue to run.

The second is the reassurance conclusion: “it’s open source, so it belongs to everyone and there’s no problem”. That is not true either, because the dependence is not in today’s code but in tomorrow’s development. Whoever dominates the contributions determines the direction: which hardware is supported, which security features are introduced, which architecture is prioritized and how quickly a vulnerability is patched. If Europe makes 4.5% of the contributions, Europe has 4.5% of the vote about where the foundation of its own cloud is moving. And the practical risk is sharper than the principled one: if a project is maintained by a handful of people whose employer pulls the plug, then you have code that is formally free but actually poses a risk.

There is also an asymmetry that is rarely mentioned: the American hyperscalers finance a large part of the open-source maintenance from which the European providers benefit for free. Every European OpenStack cloud runs on a kernel that is largely maintained by Intel, Google, Red Hat, Oracle, Meta and AMD. That’s not a reproach to those providers, it’s how open source is supposed to work, but it does make the rhetoric of “independent of the Americans” a bit less solid than it sounds.

What you can do about it

The good news is that, unlike a chip factory, this is a problem that can be solved with relatively modest amounts. The measures are well known and largely the same movement as with hardware in part 3: from origin to integrity, and from consumption to contributions.

On the technical side: reproducible builds, signed artifacts, a software bill of materials that records exactly what is in an image, automated checking for this with every rollout, and our own controlled construction chain instead of pulling packages directly from the internet.

On the human side: mapping out which components in your platform are maintained by less than a handful of people (that can be automated), and structurally putting money and manpower into it. Initiatives such as the Sovereign Tech Agency in Germany, which invests directly in the maintenance of critical open-source components, and the Dutch and European policies to promote open source in the public sector, are much more effectively spent here than many a sovereign data center project.

That, I think, is the most underestimated investment opportunity in this whole sovereignty debate. A factory for advanced chips costs tens of billions and a decade. A serious European position in the maintenance of the open source on which the platform layer runs costs a few hundred million and a few years, and provides direct control over the direction of the software that you are going to run anyway.

What does this mean for SEAL-4?

The platform layer can theoretically be European. The software can be European, the open building blocks are there, the code can be written and managed in Europe, and the operation can be fully covered by EU law. Unlike the hardware, there is no physical impossibility here. However, there are a number of important caveats.

The protection of this layer heavily affects the layer below. Measured boot, attestation and confidential computing are platform functions that only work thanks to properties of hardware that is predominantly non-European. A sovereign platform on non-sovereign hardware is perfectly defensible, but it is not a SEAL-4 according to the framework.

Second, the real distinction of a hyperscaler at this layer is not the virtualization but the operation around it: the automation, the fleet management, the detection capacity and the access discipline. That is not software that you install, it is an organization that you build, and it takes years. It consists of institutionalized knowledge and processes. There is also some good news here. The people who built it up are not exclusively Americans in the United States. The hyperscalers have all kinds of nationalities in Service and in several places. There are also development teams in various European countries. The people who have already done this also live in Europe. A point of attention here is that smaller European providers are often unable to offer nearly the same rewards.

Third, the open source on which the whole story rests is only to a limited extent European. You can build a fully European platform on a foundation of which more than nine out of ten contributions come from American companies. That is not a kill-switch risk, but it is a control risk, and in the longer term a continuity risk for the smaller components. Contributing is the only real answer here: sovereignty in software is not bought, it is earned with commits.

Fourthly, and this is the point that I would prefer to see the procurement practice adopt: at this layer, the most important security question is not “who is the owner” but “who can access it technically, and under what conditions”. Zero standing access, second-person approval, full logging and management via automated pipelines arguably provide more security than a nationality requirement. They are also easy to measure and audit. Ask for both, but start with the second.

This layer ends where the previous two also ended: the framework is excellent at exposing where the vulnerabilities are, and dangerous as soon as you apply it dogmatically. In the next section, we’ll move on to core services: VMs, containers, storage, networking, identity, and keys, where the promise of sovereignty first comes into direct contact with what customers are actually taking.

Zoals beloofd stel ik ook hier dezelfde twee vragen: Wat heb je nodig voor de bouw en wat heb je nodig voor de operatie?

Wat doet het platform eigenlijk?

Het platform is niet één ding. Het is nuttig om het onderscheid te maken tussen control plane en data plane. De data plane is waar het werk gebeurt voor klanten. Hier leven hun virtuele machines, opslag, netwerk, enzovoorts. De control plane is het besturingssysteem van de cloud zelf. Het verwerkt aanvragen zoals “geef mij vier VM’s met deze specificaties in deze regio”, zoekt er capaciteit bij, richt de netwerken in, koppelt de opslag, houdt de gewenste toestand bij en grijpt in als de werkelijkheid daarvan afwijkt. De control plane omvat verder systemen voor toegangsbeheer, logging, monitoring, encryptie en nog veel meer om de cloud draaiende en veilig te houden.

Het onderscheid tussen control plane en data plane is geen technisch detail. De data plane is waar de data van klanten leeft en waar elke klant controle heeft over de eigen omgeving. De control plane daarentegen staat onder controle van de cloud provider en dient zo ingericht te zijn dat de cloud provider geen toegang heeft tot klantdata. Of in ieder geval dat wanneer dat onverhoopt toch nodig is, dat dit gecontroleerd gebeurt en er een auditlog van gemaakt wordt, zodat alle acties traceerbaar zijn. Dat is belangrijk om na te kunnen gaan wat er fout is gegaan of hoe een lek heeft kunnen ontstaan bij een (security) incident, maar ook omdat aangetoond kan worden dat voldaan wordt aan allerlei wet- en regelgeving, en globale-, lokale-, of industrie-certificeringen zoals ISO 27001 en 27018, SOC 1 tot 3, BIR 2012 (NL), PCI-DSS en SOX. Hyperscale clouds hebben vele van dit soort certiceringen en behoren daarmee tot de meest geaudite systemen op de planeet.

Dat clouds zoveel geaudit wordt is enorm belangrijk. Want wie het control plane beheerst, beheerst de cloud. Dat betekent dat cloud providers moeten kunnen aantonen dat ze er alles aan doen om de systemen van hun klanten in de lucht te houden tijdens allerlei soorten incidenten en te beschermen tegen cyberaanvallen, zonder dat ze klantdata zien tenzij strikt noodzakelijk. En dit is waar in het soevereiniteitsdebat de vraag gesteld wordt “wie kan mijn diensten uitzetten?” Dat gaat namelijk feitelijk over de platformlaag en grotendeels over SOV‑3 en SOV‑6 uit het framework, over operationele autonomie en beheer.

Virtualisatie: waar het platform op de infrastructuur leunt

Het platform virtualiseert de infrastructuur, maar het kan dat alleen veilig doen door te steunen op wat er in de hardware aan beveiliging zit. Dat is de directe voortzetting van deel 3.

De hardware root of trust die ik daar beschreef (Cerberus, Nitro, Titan, en in open vorm Caliptra) verifieert de firmware voordat de machine opstart. Het platform bouwt daarop verder met measured boot: elke schakel in de opstartketen meet de volgende en legt die meting vast, zodat de hypervisor pas draait als bewezen is dat er onderweg niets veranderd is. Zonder die hardwarelaag is een veilige hypervisor een aanname; met die laag is het een cryptografisch controleerbaar feit. Dat is de reden waarom je deze lagen niet los kunt kopen: een soeverein platform op niet-geattesteerde hardware is een slot op een deur zonder muur.

Datzelfde geldt voor de isolatie tussen klanten. De hypervisor scheidt VM’s van elkaar, maar leunt daarbij volledig op geheugenbeveiliging in de processor. En de moderne stap verder, Confidential Computing, gaat nog een niveau dieper. Met technologie als AMD SEV‑SNP en Intel TDX wordt het geheugen van een VM versleuteld met een sleutel die de hypervisor zelf niet heeft. De beheerder van het platform kan de machine starten, stoppen en verplaatsen, maar niet in het geheugen kijken.

In het soevereiniteitsdebat dit minder aandacht dan zou moeten. De angst achter SOV‑2 en SOV‑7 is namelijk dat iemand met beheerrechten (of iemand die die rechten juridisch afdwingt) bij je data kan. Confidential Computing haalt precies die mogelijkheid technisch weg. Het is dezelfde redenering als bij hardware-integriteit in deel 3: je hoeft de beheerder niet te vertrouwen als de wiskunde het overneemt. Het maakt herkomst niet irrelevant, maar het verschuift de vraag van “wie is de eigenaar” naar “wie kan er technisch bij”, en dat is de vraag die er in de praktijk toe doet.

Een derde stuk dat vaak vergeten wordt: bij hyperscalers draait een groeiend deel van het control plane helemaal niet meer op de CPU van de server, maar op aparte hardware. Netwerkvirtualisatie, opslagverkeer en beveiligingsregels worden daar afgehandeld, fysiek gescheiden van de omgeving waar de klant zijn code draait. Daarmee is er geen software van de klant die op dezelfde processor draait als de beheerlaag. Dat is architectuur als beveiliging, en het is een van de duidelijkste voorbeelden van wat schaal je oplevert: zo’n kaart ontwikkel je alleen als je er honderdduizenden van gebruikt.

Toegang: hoe je zorgt dat niemand te veel rechten heeft

Nu de vraag die in mijn ogen het hart van deze laag raakt. Want als het control plane de macht is, dan is de mens met toegang tot het control plane het risico.

De reflex in kleine organisaties is een groep vertrouwde beheerders met brede rechten, gescreend en van onbesproken gedrag. Dat werkt, tot iemand een fout maakt, tot iemands account overgenomen wordt, of tot iemand onder druk gezet wordt. Screening beschermt tegen slechte intenties, niet tegen gestolen credentials, en de meeste incidenten beginnen niet bij een kwaadwillende medewerker maar bij een gecompromitteerde legitieme sessie.

Hyperscalers lossen dat structureel anders op, en het principe is confronterend simpel: standaard heeft niemand rechten. Geen enkele engineer heeft permanente toegang tot productie. Wat er in plaats daarvan staat, is een stapel maatregelen die samenwerken:

• Just-in-time access- Toegang wordt aangevraagd voor een specifieke taak, een specifiek systeem en een beperkte tijdsduur, met een expliciete reden die aan een ticket of incident gekoppeld is. Na afloop vervalt de toegang automatisch. Een compromittering van een engineer-account levert daarmee op een willekeurig moment niets op, want er hangt niets aan.
• Goedkeuring door een ander – Voor gevoelige acties is een min-of-meer willekeurig gekozen tweede persoon nodig die de aanvraag goedkeurt. Dat is geen bureaucratie maar hetzelfde principe als twee sleutels voor een kluis: één persoon kan niet op eigen houtje toegang krijgen.
• Geen menselijke toegang tot klantdata – De beheerinterfaces zijn zo ontworpen dat een engineer diagnostiek kan doen zonder de inhoud te zien. Waar dat onvermijdelijk is, zit er een expliciete, goedgekeurde en gelogde procedure omheen, en bij Confidential Computing is het technisch buitengesloten.
• Break-glass als uitzondering, niet als achterdeur – Er is altijd een noodprocedure, maar het gebruik daarvan zet alarmen af, is achteraf volledig te reconstrueren en wordt standaard onderzocht.
• Geen mensen aan de knoppen, maar code – Dit is misschien wel het belangrijkste en tegelijk het minst begrepen. Beheer gebeurt niet door in te loggen en commando’s te typen, maar door een wijziging aan te bieden aan een geautomatiseerde pijplijn: code review, geautomatiseerde tests, gefaseerde uitrol over zones en regio’s, automatische terugrol bij afwijkende signalen. De engineer heeft geen rechten op het systeem; de pijplijn heeft ze. Daarmee is elke wijziging per definitie beoordeeld, gelogd en herleidbaar tot een persoon en een reden.

Wat je hier ziet is dat “niemand met te veel rechten” niet een kwestie van vertrouwen is, maar van ontwerp. En hier zit een ongemakkelijk punt voor de soevereiniteitsdiscussie. De eis die je in aanbestedingen vaak ziet, “alleen EU-personeel met EU-nationaliteit mag toegang hebben tot het beheer”, meet nationaliteit. Wat er werkelijk toe doet is of er überhaupt iemand is die iets kan zonder tweede persoon, zonder ticket, zonder logging en zonder tijdslimiet. Een kleine soevereine “cloud” met tien volledig Nederlandse beheerders die permanente rootrechten hebben, is aantoonbaar kwetsbaarder dan een omgeving waar niemand standaard rechten heeft, ongeacht paspoort.

En hier zit nog een ander operationeel aspect aan. Als je toegang op deze manier kunt waarborgen, is het mogelijk om beheerders te hebben over de hele wereld, hetgeen voor 24×7 operatie een groot voordeel is, omdat je daarmee kosten kunt beperken (bijvoorbeeld geen extra kosten voor nachtdienst) en de beste experts in de wereld operaties kan laten uitvoeren op een veilige, gecontroleerde manier.

Automatisering en monitoring: waarmee de schaal mogelijk wordt

In deel 1 schreef ik dat het securitysignaal van een hyperscaler wereldwijd is en dat een afgeschermd nationaal eiland slechts een fractie daarvan ziet. Op de platformlaag wordt concreet waarom dat zo veel uitmaakt, want het zijn juist automatisering en monitoring die elkaar hier versterken.

Monitoring zonder automatisering levert alarmen op die door mensen afgehandeld moeten worden. Dat schaalt niet. Meer systemen betekent meer alarmen betekent meer ruis betekent alarmmoeheid, en alarmmoeheid is hoe echte incidenten gemist worden. Automatisering zonder monitoring is blind. Je rolt fouten net zo efficiënt uit als verbeteringen. En dit is ook waarom de monitoring data zo belangrijk is. Het is de motor van constante verbeteringen.

De combinatie is wat het verschil maakt. Bij een hyperscaler is het platform zelf de bron van de waarheid. Het weet exact welke configuratie er hoort te draaien en elke afwijking daarvan is per definitie verdacht. Een server die van de norm afwijkt wordt niet onderzocht maar automatisch uit rotatie gehaald en opnieuw opgebouwd. Een gedragspatroon dat afwijkt (een beheeraccount dat op een ongebruikelijk tijdstip een ongebruikelijke API aanroept) is detecteerbaar juist omdat het normale gedrag zo strak gedefinieerd is.

Daar komt het volumeargument bovenop, en dat is geen marketing maar statistiek. Detectie van afwijkend gedrag vereist een betrouwbaar beeld van normaal gedrag. Hoe meer signaal, hoe scherper dat beeld en hoe kleiner de afwijking die je nog betrouwbaar kunt opmerken. Een omgeving met duizend servers ziet te weinig om subtiele patronen boven de ruis uit te tillen. Een omgeving met miljoenen ziet ze wel, en kan een detectieregel die bij één klant werkt binnen minuten wereldwijd uitrollen. Datzelfde geldt voor patchen. Bij volledig geautomatiseerd vlootbeheer kan in uren tot dagen de hele vloot bijgewerkt zijn, met bewijs dat het overal gebeurd is. Bij (deels) handmatig patchen duur dit veel langer en moet bewijs verzameld worden.

En dan is er nog het personele argument, dat ik in deel 1 al aanstipte. Een securityteam dat 24/7 dekking moet bieden heeft, met vakantie, ziekte en verloop, al gauw acht tot tien mensen nodig voor één functie. Voor een volwaardig operationeel securitycentrum met detectie, respons, threat intelligence, forensics en red teaming zit je op tientallen tot honderden mensen. Bij de hyperscalers zijn dat er duizenden. Voor een Europese speler met een paar duizend medewerkers in totaal is dat niet een kwestie van willen, maar van kunnen, in een arbeidsmarkt waar deze mensen structureel schaars zijn.

Ik zeg dit niet om kleine partijen af te schrijven, maar om te laten zien dat schaal op zichzelf een factor is. Om een serieuze Europese cloud te hebben, moet je niet alleen de supply chain en operatie onder controle hebben, maar is schaal een voorwaarde voor succes. Dat levert een kip-ei probleem op, want de schaal is nodig om lagere kosten en hogere kwaliteit te realiseren, maar die schaal haal je alleen maar als je kosten-kwaliteit verhouding niet te ver uit de pas loopt met wat de Amerikaanse clouds kunnen leveren.

De bouwvraag: welke opties zijn er?

Er zijn verschillende routes om de control plane op te bouwen. Zo zou je kunnen beginnen met een virtualisatieplatform zoals VMWare en Nutanix, of een open source alternatief daarvoor zoals Proxmox. Ook zou je op basis van Kubernetes aan de slag kunnen gaan en KubeVirt gebruiken voor als je toch virtuele machines moet ondersteunen (en dat moet je). Aangezien Kubernetes open source is, en ook nog eens een defacto standard voor cloud-native applicaties, zijn er voldoende opties. Maar een virtualisatie- en containerplatform is nog geen cloud. Ten eerste is een dergelijke omgeving vooral bedoeld voor één organisatie en niet een multi-tenant omgeving voor vele organisaties. Ten tweede doet de control plane meer dan alleen wat gevirtualiseerde compute, opslag en network optuigen. Het is het hart van de cloud en er zit een ribbenkast aan zaken omheen om de cloud robuust en veilig te houden, en om Andere diensten bovenop aan te kunnen bieden. Hier zijn wel een aantal opties voor.

OpenStack is de bekendste. Het project startte in 2010 en het wordt beheerd door de Open Infrastructure Foundation. Het is uitgegroeid tot een verzameling van losjes gekoppelde diensten: Nova voor compute, Neutron voor netwerken, Cinder en Swift voor opslag, Keystone voor identiteit, Ironic voor bare metal. Een aantal Europese providers gebruikt OpenStack: OVHcloud, T-Systems, Cleura en kleinere nationale spelers. De kracht is de modulariteit en het feit dat het bewezen is op grote schaal. De prijs is complexiteit: OpenStack is berucht om zijn operationele zwaarte, en de kennis om het op grote schaal draaiend te houden is een schaars en duur goed. Het is geen product dat je installeert, het is een discipline die je opbouwt.

OpenNebula is de tegenpool van OpenStack. Het veel eenvoudiger van opzet en ontworpen om met een klein team een aanzienlijke omgeving te beheren. Het schaalt prima naar duizenden hosts en is sterk in edge- en gedistribueerde scenario’s. Precies daarom is het interessant voor een Europese speler die niet de personele diepte van een hyperscaler heeft. Wat het niet doet, is de breedte van diensten leveren die klanten van een hyperscaler verwachten.

Apache CloudStack valt in dezelfde categorie als OpenNebula. Het is een volwassen alternatief dat vooral bij hostingproviders gebruikt wordt en aanzienlijk eenvoudiger te bedienen is dan OpenStack.

Dat deze platformen open source zijn heeft het voordeel dat er iets is waarop voortgebouwd kan worden. Maar dit verschilt wezenlijk van hoe een hyperscaler werkt. De platformsoftware is bij een hyperscaler sterk geintegreerd met de hardware, wat het geheel sneller, robuuster en veiliger maakt dan het bij elkaar brengen van onderdelen die niet op elkaar afgestemd zijn. Dat is geen open source, maar zoals aangegeven zijn er allerlei andere waarborgen voor klanten die misschien wel belangrijker zijn.

De eerlijke conclusie voor de bouwvraag: op de platformlaag is SEAL‑4 technisch haalbaar. De software kan Europees zijn, de code kan in Europa geschreven worden, en de open projecten liggen er. Wat ontbreekt is niet de blauwdruk, maar de jaren aan operationele ervaring die nodig zijn om zo’n platform op hyperscale betrouwbaar te maken. Dat is niet te kopen, dat moet je meemaken. En dan kom je bij de operatie en de toeleveringsketen.

De operatie en toeleveringsketen

Dat het de platform software open source kan zijn en daarmee Europees gemaakt kan worden is natuurlijk mooi. Maar hoewel de software an sich belangrijk is, gaat het in deze laag vooral de constante verbeteringen om de operatie nog robuuster, nog veiliger, en met nog minder overhead te kunnen maken. Open source is daar een belangrijke component in, ook voor hyperscalers, maar niet de enige. Het open source deel bestaat uit de Linux-kernel, KVM, de container-runtimes, cryptografische bibliotheken, honderden pakketten die elk hun eigen afhankelijkheden meebrengen. Formeel gezien is dat geen SOV‑5-probleem, want een open licentie kent geen jurisdictie en kan niet met terugwerkende kracht ingetrokken worden. Praktisch gezien is het wel degelijk een afhankelijkheid, alleen een andere dan het framework meet. Want een licentie kun je niet intrekken, maar de mensen die de code onderhouden kun je wel kwijtraken, overnemen, of onder druk zetten.

Verder gaat het om de operatie van de schil eromheen: capaciteitsplanning die maanden vooruit kijkt, geautomatiseerde uitrol van nieuwe hardware zonder downtime, live migration van honderdduizenden workloads tijdens onderhoud, foutdomeinen die zo ontworpen zijn dat een defecte hardware geen klant raakt, en een control plane dat zelf ook nog eens over drie availability zones verdeeld is en een quorum vormt (precies de reden waarom er in deel 2 drie zones stonden en geen twee). Die laag is bij de hyperscalers geen open source, en dat is meteen het echte gat.

De maintainer als kritieke component… en risico

Dit is de laag waar de toeleveringsketen niet uit fabrieken bestaat maar uit mensen, en dat maakt hem lastiger te meten en makkelijker te negeren.

Het beeld dat de meeste bestuurders van open source hebben, is dat van een wereldwijde massa vrijwilligers die elkaars werk controleert: veel ogen, dus weinig bugs. Voor de grootste projecten klopt dat ook. Voor het overgrote deel van wat er in je stack zit, klopt het niet. Het Census II-onderzoek van Harvard en de Linux Foundation keek naar de vijftig meest gebruikte niet-npm-componenten en vond dat bij 23% van die projecten één enkele ontwikkelaar meer dan 80% van de toegevoegde regels code schreef, en dat bij 94% van de projecten minder dan tien ontwikkelaars goed waren voor meer dan 90% van de code. Dat is de werkelijke vorm van deze afhankelijkheid. Niet een land dat een kraan dichtdraait, maar een handvol mensen dat het volhoudt. En dat is precies waar het XZ Utils-incident van 2024 op inhaakte: een bijdrager bouwde jarenlang geduldig vertrouwen op bij een uitgeputte solo-maintainer van een breed gebruikte compressiebibliotheek, nam het onderhoud over en plaatste er een achterdeur in die tot in de authenticatieketen van vrijwel elke Linux-distributie zou hebben gereikt. Het werd ontdekt doordat een ingenieur van Microsoft een prestatieafwijking van een halve seconde bij het inloggen te vreemd vond en ging graven. Toeval, met andere woorden. De kwetsbaarheid zat niet in de code, maar in het onderhoudsmodel: één overbelaste vrijwilliger op een pakket waar de halve wereld op leunt.

Voor het soevereiniteitsdebat is dit belangrijker dan het lijkt. Een EU-aanbesteding kan eisen dat de leverancier Europees is en dat het beheer in de EU plaatsvindt, en beide vinkjes kunnen groen staan terwijl de kritieke afhankelijkheid bestaat uit een niet-Europese vrijwilliger die geen contract, geen SLA en geen opvolger heeft. En dan hebben we het nog niet eens gehad over een scenario waar kwaadwillenden zich op de open source software supply chain richten. Dat is met AI (gelukkig) steeds beter op te sporen, maar vooralsnog is dat niet 100% waterdicht. Closed source in eigen beheer kan daarom in sommige gevallen veiliger zijn.

Wie draagt er dan werkelijk bij?

De cijfers zijn hier confronterender dan de open-sourceretoriek suggereert. Neem de Linux-kernel, het fundament van elk cloudplatform dat we in dit deel besproken hebben. In 2025 werd 84,3% van alle kernelcommits geschreven door mensen die daarvoor betaald worden, verdeeld over ruim 1.780 organisaties. Slechts zo’n 16% kwam van onafhankelijke of niet-toewijsbare bijdragers. De kernel is dus geen vrijwilligersproject meer, maar een industrieel samenwerkingsverband, en de vraag wie er bijdraagt is daarmee de vraag welke bedrijven erin investeren. Google, Intel, Meta en Oracle tekenenen voor meer dan 60% van de bijdragen, en daar komen partijen als AMD, Huawei, en Red Hat nog bovenop.

Zoom je uit naar open source in het algemeen, dan wordt het beeld niet anders. De Open Source Contributor Index, die bedrijven rangschikt naar het aantal actieve bijdragers op GitHub, wordt medio 2026 aangevoerd door 8 Amerikaanse bedrijven, gevolgd door Huawei en op plaats 10 SUSE. Reken je die tien tegen elkaar af, dan komt ruim 90% van de actieve bijdragers uit Amerikaanse bedrijven, ongeveer 4,8% uit China en ongeveer 4,5% uit Europa, en dat laatste percentage bestaat vrijwel volledig uit één bedrijf: SUSE.

Bij OpenStack, het platform waar de Europese cloudsector het meest op leunt, ligt de verdeling gunstiger: Red Hat en SUSE zijn er groot, en Europese providers als OVHcloud, T‑Systems, Cleura en het Duitse SysEleven dragen daadwerkelijk bij. Maar OpenStack is ook een project waar de commerciële energie sinds het vertrek van een aantal grote Amerikaanse en Chinese sponsors juist is teruggelopen, en dat is niet zonder risico als je er je hele platformlaag op bouwt. OpenNebula is een van de weinige echt Europese cloudprojecten met een Europese onderneming eromheen, maar de contribuerende gemeenschap is naar verhouding klein, en dat is precies het patroon uit Census II in het klein.

Één belangrijke nuance bij al deze cijfers: ze meten werkgever, niet nationaliteit. Een Duitse ontwikkelaar in dienst van Google in München telt in deze statistiek als Google. Er is opvallend weinig betrouwbare data over waar bijdragers fysiek zitten, en dat is op zichzelf al een bevinding: de discussie over “wie schrijft de code die wij draaien” wordt gevoerd zonder dat iemand er goede meetgegevens over heeft. Wat we wél weten is wie de rekening betaalt, en dat is overweldigend niet-Europees.

Wat betekent dat nu echt?

Ik wil twee verkeerde conclusies voorkomen:

• De paniekconclusie: “de code is Amerikaans, dus we zijn niet soeverein”. Zo werkt open source niet. De GPL en de Apache-licentie zijn onherroepelijk voor code die al vrijgegeven is, en de kernelbroncode staat op honderdduizenden plekken. Niemand kan Linux uitzetten. Als Intel morgen zou stoppen met bijdragen, blijft alles draaien wat er draait.
• De geruststellingsconclusie: “het is open source, dus het is van iedereen en er is geen probleem”. Ook dat klopt niet, want de afhankelijkheid zit niet in de code van vandaag maar in de ontwikkeling van morgen. Wie de bijdragen domineert, bepaalt de richting: welke hardware ondersteund wordt, welke beveiligingsfuncties er komen, welke architectuur prioriteit krijgt en hoe snel een kwetsbaarheid gepatcht is. Als Europa 4,5% van de bijdragen levert, heeft Europa 4,5% van de stem over waar het fundament van zijn eigen cloud heen beweegt. En het praktische risico is scherper dan het principiële: raakt een project onderhouden door een handvol mensen wiens werkgever de stekker eruit trekt, dan heb je code die formeel vrij is maar feitelijk een risico vormt.

Er is bovendien een asymmetrie die zelden benoemd wordt: de Amerikaanse hyperscalers financieren een groot deel van het open-source-onderhoud waar de Europese providers gratis van profiteren. Elke Europese OpenStack-cloud draait op een kernel die voor het overgrote deel door Intel, Google, Red Hat, Oracle, Meta en AMD onderhouden wordt. Dat is geen verwijt aan die providers, het is hoe open source hoort te werken, maar het maakt de retoriek van “onafhankelijk van de Amerikanen” wel wat minder stevig dan ze klinkt.

Wat je eraan kunt doen

Het goede nieuws is dat dit, anders dan een chipfabriek, een probleem is dat met relatief bescheiden bedragen wél op te lossen valt. De maatregelen zijn bekend en grotendeels dezelfde beweging als bij hardware in deel 3: van herkomst naar integriteit, en van consumeren naar bijdragen.

Aan de technische kant: reproduceerbare builds, ondertekende artefacten, een software bill of materials die vastlegt wat er precies in een image zit, geautomatiseerde controle daarop bij elke uitrol, en een eigen gecontroleerde bouwketen in plaats van pakketten rechtstreeks van internet trekken.

Aan de menselijke kant: in kaart brengen welke componenten in je platform door minder dan een handvol mensen worden onderhouden (dat is te automatiseren), en daar structureel geld en menskracht in stoppen. Initiatieven als het Sovereign Tech Agency in Duitsland, dat rechtstreeks investeert in het onderhoud van kritieke open-sourcecomponenten, en het Nederlandse en Europese beleid om open source in de publieke sector te bevorderen, zijn hier veel effectiever besteed geld dan menig soeverein datacenterproject.

Dat is, denk ik, de meest onderschatte investeringskans in dit hele soevereiniteitsdebat. Een fabriek voor geavanceerde chips kost tientallen miljarden en een decennium. Een serieuze Europese positie in het onderhoud van de open source waar de platformlaag op draait, kost een paar honderd miljoen en een paar jaar, en levert directe zeggenschap op over de richting van de software die je hoe dan ook gaat draaien.

Wat betekent dit voor SEAL‑4?

De platformlaag kan in theorie Europees zijn. De software kan Europees zijn, de open bouwstenen liggen er, de code kan in Europa geschreven en beheerd worden, en de operatie kan volledig onder EU-recht vallen. Anders dan bij de hardware is er hier geen fysieke onmogelijkheid. Er zijn echter wel een aantal belangrijke kanttekeningen.

De beveiliging van deze laag zwaar op de laag eronder. Measured boot, attestatie en confidential computing zijn platformfuncties die alleen werken dankzij eigenschappen van hardware die overwegend niet-Europees is. Een soeverein platform op niet-soevereine hardware is prima verdedigbaar, maar het is conform het framework geen SEAL‑4.

Ten tweede is het echte onderscheid van een hyperscaler op deze laag niet de virtualisatie maar de operatie eromheen: de automatisering, het vlootbeheer, de detectiecapaciteit en de toegangsdiscipline. Dat is geen software die je installeert, het is een organisatie die je opbouwt, en daar gaan jaren overheen. Het bestaat uit geïnstutionaliseerde kennis en processen. Hier is ook nog wel wat goed nieuws. De mensen die dat opgebouwd hebben zijn niet uitsluitend Amerikanen in de VS. De hyperscalers hebben allerlei nationaliteiten in dienst en op meerdere plaatsen. Zo zijn er ook ontwikkelteams in verschillende Europese landen. De mensen die dit al eens gedaan hebben, wonen ook in Europa. Aandachtspunt daarbij is wel is dat kleinere Europese providers vaak bij lange na niet dezelfde beloningen kunnen bieden.

Ten derde is de open source waarop het hele verhaal rust maar in beperkte mate Europees. Je kunt een volledig Europees platform bouwen op een fundament waarvan meer dan negen van de tien bijdragen uit Amerikaanse bedrijven komen. Dat is geen kill-switch-risico, maar het is wel een zeggenschapsrisico, en op de langere termijn een continuïteitsrisico bij de kleinere componenten. Bijdragen is hier het enige echte antwoord: soevereiniteit in software koop je niet, die verdien je met commits.

Ten vierde, en dat is het punt dat ik het liefst zou willen dat de aanbestedingspraktijk overneemt: op deze laag is de belangrijkste beveiligingsvraag niet “wie is de eigenaar” maar “wie kan er technisch bij, en onder welke voorwaarden”. Zero standing access, goedkeuring door een tweede persoon, volledige logging en beheer via geautomatiseerde pijplijnen leveren aantoonbaar meer beveiliging op dan een nationaliteitseis. Ze zijn ook nog eens goed te meten en te auditen. Vraag beide, maar begin bij de tweede.

Daarmee eindigt deze laag waar de vorige twee ook eindigden: het framework is uitstekend in het blootleggen van waar de kwetsbaarheden zitten, en gevaarlijk zodra je het dogmatisch toepast. In het volgende deel klimmen we naar de kerndiensten: VM’s, containers, storage, networking, identity en keys, waar de belofte van soevereiniteit voor het eerst rechtstreeks in aanraking komt met wat klanten daadwerkelijk afnemen.

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.

We start at the bottom, with the layer that is least glamorous and most often skipped in sovereignty debates: the datacenter itself. Buildings, power, cooling and fiber. No software, no chips, but concrete, copper and water. This is probably the layer where European sovereignty is most achievable, although there are obstacles, especially physical ones. The advantage of a datacenter in itself is that it can be nationalized and thereby shielded from possible government interference from abroad. As the case of Nexperia in 2025 shows, that is diplomatically complex.

The anatomy of a hyperscale region

A hyperscale cloud does not think in datacenters, but in regions. A region is not a building but a cluster of buildings, usually divided into three availability zones. Each zone is a self contained collection of datacenters with its own power, cooling and network. An outage in one must not affect the other. The zones are far enough apart not to be taken down by the same flood, fire or power failure, usually from a few kilometers up to about 100 kilometers, but close enough to communicate over fiber with less than about 2 milliseconds round trip latency. Those 2 milliseconds are not an arbitrary number: they are the boundary below which you can replicate synchronously, meaning a database in zone 1 and its copy in zone 2 behave as one system.

Why three, and not two? Because with three you can form a majority, a quorum. If one zone fails, the other two together hold the truth and the service keeps running. Two zones give you redundancy, but no majority: in a network split, neither knows whether it is still in charge. Three is the minimum for a system that keeps itself upright without human intervention. That is also the essence of why a hyperscale region is more expensive than “a datacenter”: you effectively build the capacity one and a half to three times over.

Connection with other regions

One region, however robust, is still one place on the map. To protect against disasters that can affect an entire region, such as a prolonged regional power crisis, a flood, or a human error that spreads across the whole region, you need multiple regions. Unlike between zones, that connection is not synchronous: over hundreds of kilometers the speed of light is simply too slow for those 2 milliseconds, so you replicate asynchronously. You accept that the copy in the other region or regions lags a fraction behind, in exchange for the certainty that your data exists in multiple places.

And this is where the physical layer suddenly touches sovereignty. Hyperscalers offer options to replicate to other regions within the same jurisdiction. For data residency, that is exactly what you want: your failover site falls under the same law as your primary region. At this layer, “data stays in the EU” is therefore not a promise but an architectural choice you can point to on a map. The connections themselves, especially the fiber backbone and submarine cables, are located in Europe for Europe and can therefore, if they are not already owned by a European party, be made European.

Sovereignty, however, is also about resilience, keeping systems available under extreme circumstances. Ukraine has therefore placed many of its systems outside the country, and thus outside its explicit jurisdiction. As Johan Cruijff used to say, “every disadvantage has its advantage.”

Energy: the real bottleneck

Now the bill. A single hyperscale datacenter easily draws tens of megawatts, enough to power hundreds of thousands of households. A region with three zones and multiple buildings per zone therefore quickly reaches several hundred megawatts, and the newest AI regions are heading toward a gigawatt or more. For comparison: that is on the order of a medium sized power plant, permanently, day and night, for one region.

For the Netherlands this is not an abstraction but the bottleneck. Our high voltage grid is at or beyond its limit in large parts of the country. The grid congestion that TenneT had warned about for years is now a reality. New large consumers are in the queue, and that queue is not measured in weeks but in years. In some markets, the connection time for a large consumer has risen to as much as eight years. You can order the fastest chips in the world, but without a grid connection a datacenter can do nothing. Energy is therefore not the most expensive line in the budget, it is the line that determines whether the project happens at all, and when. It also explains why energy is so central in Dutch policy, which I will return to shortly: a hyperscaler competes for exactly the same scarce sustainable electrons as the energy transition of households and industry. At the same time, it is precisely hyperscalers that drive investments in renewable energy, and there are places where they play a role in balancing the power grid by feeding electricity back into it.

What hyperscalers do to save energy

The hyperscalers are painfully aware of that bill, if only because electricity is their largest operating cost. Efficiency is measured with PUE, Power Usage Effectiveness: the ratio between total power and the power that actually goes to the servers. An average enterprise datacenter is around 1.5 to 2.0. Over the past two decades, the hyperscalers have made all kinds of improvements to bring this down to 1.1 to 1.2. That difference, the “overhead” that goes not to computing but to cooling and losses, is exactly where the savings lie, and where a small player loses out to scale.

They achieve this in the usual ways: cooling with outside air, free cooling, when the climate allows it, which is one reason why the Netherlands is an interesting place for a datacenter; hardware that can tolerate higher temperatures so less cooling is needed; and AI that optimizes cooling in real time. Here, scale again works in their favor. An improvement of 0.01 in PUE delivers enormous savings at the scale of hundreds of megawatts.

Water and cooling

Cooling is energy’s twin sister, and mainly requires water. Classic datacenter cooling evaporates water to remove heat. That is good for the electricity bill, but it consumes millions of liters per year per location, often ordinary drinking water. Given increasing water scarcity, this is a growing social problem, and the industry is therefore shifting rapidly. Microsoft, for example, began rolling out a closed cooling system at chip level in mid 2024 that makes evaporative water entirely unnecessary. It is filled once during construction and then circulates, saving millions of liters per location each year. Other approaches include air cooling and cooling with non drinkable, rain or recycled water.

And then there is residual heat. Removed heat does not have to simply disappear into the air. Residual heat can be used, for example, to heat greenhouses or homes through a connection to a district heating network. For the latter, however, a datacenter must be close to the city, where spatial pressure and therefore land costs are highest. Here too, advantages and disadvantages have to be weighed against each other.

The supply chain of a datacenter

Back to the two questions from the roadmap: what does the chain look like when building, and when operating?

When building, you need a surprisingly long list of heavy, critical components: transformers and medium voltage switchgear to convert and distribute grid power, emergency generators, usually diesel, for when the grid fails, batteries to bridge the seconds until those generators are running, and cooling systems and pipework. And of course also concrete, steel, copper and fiber.

And this is the bright spot for the sovereignty story. Unlike chips or advanced software, this is a chain that Europe largely controls itself. Transformers and switchgear come from European players such as Siemens Energy, Hitachi Energy, Schneider Electric and ABB. Emergency generators come mainly from Germany’s MTU, and cooling technology also comes mostly from European companies such as STULZ, Munters and Schneider. Concrete and steel are in principle local. The big exception is batteries. The lithium ion cells required come mainly from Asia, CATL, LG, Samsung SDI and Panasonic. Some alternatives exist and European production is emerging, but this remains Europe’s weak point in an otherwise well covered chain.

That will have to be scaled up further to reduce supply problems. An AFCOM study indicates that 94% of datacenter operators face supply problems, with generators, transformers and switchgear as the biggest bottlenecks. Lead times for large emergency generators have risen to between 72 and 104 weeks. There is therefore much to gain here.

When operating, the dependency shifts from things to flows: electricity, diesel fuel for the generators, water, spare parts and the technicians who keep it running. None of those flows is a direct sovereignty problem, although parts of that chain may currently fall outside Europe.

Permits and physical reality

Alongside the technical reality, there is also a process that must be completed to obtain the necessary permits. And that also has a political component.

In February 2022, the Dutch government adopted a preparatory decision that restricted the establishment of hyperscale datacenters throughout the country. The motivation was explicit and reveals exactly the tension from the energy section: hyperscale datacenters place “a disproportionately large claim on the available sustainable energy in relation to their social and or economic added value”. The national government took control and set admission criteria for permits. The best known case, the planned mega site near Zeewolde, became a national dividing line and got stuck. Not a technical problem, but a social and administrative one.

On top of that decision come the familiar Dutch files: the nitrogen crisis that delays almost every major building permit, grid congestion that can postpone a connection for years, spatial pressure in a crowded country, and water extraction that meets local resistance. Each of these files can halt a project by itself. Together they form a permitting process that takes longer and is more uncertain than ordering any long lead time component. For a truly European hyperscaler, this need not be as much of a problem. After all, there are more countries where datacenters can be located. But that brings us back to one of the earlier elements: the network connection. Building datacenters in places without a digital highway is of little use; laying tens of kilometers of cable, over multiple routes for redundancy, also requires permits and the like. Apart from the work that needs to be done.

So, is it worth it?

Back to the main question: can a SEAL 4 datacenter layer be built? On the sovereignty axis, the answer is positive. The building, the power infrastructure, the cooling and the fiber can largely be designed, delivered and operated within the EU. The only real non EU dependency of significance is the battery cell, and even that is not a showstopper.

So the fact that not many sovereign hyperscale datacenters are being built actually has little to do with the datacenter layer in itself. It is the interaction with the other layers plus the political and financial barriers. No one wants to invest billions if there is no predictable return. The American hyperscalers, by contrast, have the money themselves and, because they control all layers, the return is predictable. That does not change the fact that there are all kinds of parties building datacenters, among other things to lease them to hyperscalers. And if those companies are not European, they could be made European in a crisis.

In dit deel klimmen we één laag omhoog, naar de infrastructuur: de compute-, storage- en netwerkhardware die in de datacenters staat. En hier wordt het framework pas echt interessant. Dit is de laag waar toeleveringsketen-soevereiniteit (SOV‑5, met 20% de zwaarst wegende doelstelling in CSF) van een abstract begrip verandert in een keiharde landkaart van fabrieken, machines en octrooien. Op die kaart is Europa vooralsnog grotendeels toeschouwer.

Zoals beloofd stel ga ik bij elke laag in op dezelfde twee vragen: hoe ziet de toeleveringsketen eruit wanneer je het bouwt, en wanneer je het exploiteert?

De toeleveringsketen bij het bouwen

Een moderne server lijkt een doos met onderdelen, maar is in werkelijkheid het eindpunt van een uiterst complexe toeleveringsketen die bestaat uit meerdere delen:

• Electronic Design Automation-software: Dit is de gereedschapskist waarmee chips ontworpen worden. De marktleiders zijn Synopsys (VS), Cadence (VS), Siemens EDA (Duitsland).
• Instructiesets: Zonder instructies doet een chip niets en dus is het intellectueel eigendom van de instructieset van belang. x86 valt onder gedeelde controle van Intel en AMD (beide VS), Arm is van Arm Holdings (VK, maar met een Japanse eigenaar). RISC‑V is een open standaard maar heeft nog geen volwassen ecosysteem. Dit is potentieel waar Europa zich op zou moeten richten.
• Chipontwerp: Chips worden ontworpen door Nvidia, AMD, Intel, Ampere, Broadcom, plus de eigen chips van de hyperscalers zelf (AWS Graviton/Trainium, Google TPU, Microsoft Maia/Cobalt). Dit is daarmee grotendeels Amerikaans.
• Fabricage: De daadwerkelijke productie van chips gebeurt bij TSMC (Taiwan), Samsung (Zuid-Korea) en in mindere mate Intel (VS). Geheugen (DRAM, HBM) komt van Samsung, SK hynix en Micron (Korea, VS).

Deze keten SEAL-4 compliant maken is een enorme onderneming die heel veel investeringen vergt en een lange adem. Maar er is nog een cruciaal onderdeel van de keten…

De rol van ASML

In deel 1 noemde ik het al kort: Nederland heeft met ASML een enorme troef in handen. Tijd om die kaart om te draaien en goed te bekijken, want ASML is het beste bewijs dat “soevereiniteit” en “afhankelijkheid” twee kanten van dezelfde medaille zijn.

ASML is de enige fabrikant ter wereld die EUV-lithografie kan leveren. Dit zijn de machines waarmee de geavanceerde chips gemaakt worden die elke moderne GPU en CPU nodig heeft. Niet de grootste, niet de beste: de enige. Zonder ASML staan de fabrieken van TSMC en Samsung stil. ASML komt dichtbij een monopolie.

De EUV-systemen die ASML maakt bestaat uit honderdduizenden componenten. De optiek komt van Carl Zeiss SMT (Duitsland). Dit gaat om spiegels die zo perfect gepolijst zijn dat de afwijkingen op de schaal van een atoom worden gemeten, en waar Zeiss een de-facto monopolie op heeft. De techniek om druppeltjes tin vijftigduizend keer per seconde door een laser te raken om plasma te maken komt van Cymer (Amerikaans, maar in bezit van ASML) en Trumpf (Duits). De machines van ASML zijn daarom meer dan een product, het is een ecosysteem dat in twee decennia is opgebouwd. Dat is niet zo 1-2-3 te repliceren (later meer daarover).

Nu de nuance, want dit is waar het interessant wordt voor het framework. Het feit dat ASML Nederlands is, betekent niet dat Europa soevereine compute heeft. ASML verkoopt zijn machines aan TSMC in Taiwan en Samsung in Korea, en die fabriceren chips die door Nvidia (VS) zijn ontworpen met Amerikaanse EDA-software op een Britse of Amerikaanse instructieset. ASML is dus maar één schakel in een keten die verder overweldigend niet-Europees is.

Het laat wel zien dat afhankelijkheid twee kanten op werkt, precies zoals ik in deel 1 aanstipte. De hele wereld heeft Europa nodig voor de bovenkant van de chipketen, net zo hard als Europa de rest van de wereld nodig heeft voor de onderkant. Dat is geen soevereiniteit, maar het is wel onderhandelingspositie. In een geopolitiek spel is een geloofwaardige troef aan de onderhandelingstafel meer waard dan een dogmatisch nagestreefde autarkie die je economisch de das omdoet. De recente berichten dat China eigen DUV-machines in productie neemt (juli 2026) laten meteen zien hoe kwetsbaar zelfs een monopolie is zodra iemand bereid is er tientallen miljarden en een decennium (of twee) tegenaan te gooien. Een voorsprong is geen eeuwigdurend bezit.

De eerlijke conclusie voor de bouwvraag: op de hardwarelaag is een SEAL‑4-keten vandaag simpelweg niet te bouwen. Niet omdat Europa dom of lui is, maar omdat de keten fysiek verspreid is over Taiwan, Korea, de VS en Japan, en het jaren tot decennia duurt om die schakels te dupliceren, als het al kan. Het European Processor Initiative en RISC‑V zijn serieuze pogingen om bij te komen, maar het zal echt een heleboel vergen voor ze hyperscale-volume en -prestaties kunnen bieden. Het framework rapporteert dat eerlijk, en dat is precies zijn waarde: het liegt niet over waar we staan.

Open Compute Project

Als de chips zelf de moeilijkste laag zijn, dan is de manier waarop hyperscalers die chips tot servers, racks en netwerken smeden juist het meest verrassend open. Dat komt door het Open Compute Project (OCP). OCP is in 2011 opgericht door Facebook (nu Meta), dat besloot zijn serverontwerpen niet als bedrijfsgeheim te behandelen maar openbaar te maken. Het idee: als iedereen dezelfde open specificaties gebruikt voor moederborden, voedingen, racks, koeling en netwerkswitches, dan wordt hardware een commodity, gaat de prijs omlaag en gaat de kwaliteit omhoog. Microsoft, Google en vrijwel iedere serieuze speler droegen hun eigen ontwerpen bij. Een groot deel van wat een hyperscaler “hyper” maakt aan de hardwarekant (racks, gedisaggregeerde storage, hot-swappable alles) is publiek beschikbaar via OCP.

Voor het soevereiniteitsdebat is dat een dubbelzinnig cadeau. Aan de ene kant verlaagt het de drempel enorm: een Europese partij die een hyperscalebasis wil bouwen, hoeft het wiel niet opnieuw uit te vinden. De ontwerpen liggen klaar. Je hoeft niet te bedenken hoe je een efficiënt rack bouwt; dat is een opgelost probleem. Ironisch genoeg maken de huidige Europese partijen niet of nauwelijks gebruik van OCP en daarmee laten ze een grote mate aan innovatie en (kosten)efficiëntie liggen, ook al komt de hardware van buiten Europa.

Echter, open hardware lost precies niets op aan het probleem van een puur Europese toeleveringsketen: OCP is een verzameling open specificaties, maar nog geen fabriek. De blauwdruk delen is gratis, maar de productie blijft de bottleneck. Waar OCP de laatste jaren wel iets doet dat er voor soevereiniteit echt toe doet, is beveiliging, hetgeen on brengt bij de exploitatie.

De toeleveringsketen bij het exploiteren

Stel dat je op magische wijze al je hardware soeverein zou kunnen inkopen. Dan nog is er een risico dat losstaat van waar de chip vandaan komt: is er onderweg mee geknoeid? Een server passeert tientallen handen (o.a. fabriek, assemblage, transport, distributie, installatie) en op elk van die punten kan iemand in theorie een kwaadaardig component bijplaatsen of een firmware-image vervangen. Dit is het klassieke schrikbeeld van de “hardware-implant”, jaren geleden groot geworden door een omstreden (en door alle betrokken partijen ontkend) verhaal over een spionagechip op serverboards. Of dat specifieke verhaal nu klopte of niet, het maakte de industrie in één klap wakker: firmware en hardware die je niet kunt verifiëren, moet je niet vertrouwen.

Hier is een belangrijk onderscheid dat in het soevereiniteitsdebat vaak door elkaar loopt: herkomst (waar is het gemaakt — de SOV‑5-vraag) is iets anders dan integriteit (is het onderweg ongemoeid gebleven). Het framework hamert op herkomst, maar in de dagelijkse praktijk is integriteit vaak de relevantere beveiligingsvraag. En het mooie is dat je integriteit kunt afdwingen, ongeacht waar de onderdelen vandaan komen.

Precies dat is wat de hyperscalers op enorme schaal doen, met een aanpak die “hardware root of trust” heet. Project Cerberus (Microsoft), Nitro (AWS), en Titan (Google) zijn hier allemaal varianten van. Ze zorgen voor hardware root of trust met een identiteit die niet te klonen is, die voor het opstarten elke firmware-image op de server controleert en niet te opstart als er ook maar één bit niet klopt. Omdat de hardware root of trust cryptografisch geverifieerd wordt, hoef je de leverancier niet te vertrouwen. Je vertrouwt de wiskunde.

En hier komt OCP terug in beeld, want deze root of trust hoeft geen gesloten bedrijfsgeheim te zijn. Caliptra is een open-source silicon root of trust: een specificatie, silicium-logica, ROM en firmware voor een geïntegreerd vertrouwensblok, bedoeld voor datacenter-klasse chips als CPU’s, GPU’s, DPU’s en TPU’s. Met andere woorden: het recept om te verifiëren dat er niet met je hardware is geknoeid, ligt open op tafel. Via de OCP Security-werkgroep (met initiatieven rond veilige firmware en attestatie) wordt dit stukje bij beetje een gedeelde standaard.

Waarom is dit voor het soevereiniteitsverhaal zo belangrijk? Omdat het laat zien dat de meest concrete beveiligingsmaatregel op de hardwarelaag, weten dat er niet met je spullen is geknoeid, niet afhankelijk is van SEAL‑4-herkomst. Je kunt een chip uit Taiwan in een server bouwen en er alsnog wiskundig zeker van zijn dat de firmware onaangetast is. Een land dat zich blindstaart op “waar komt de chip vandaan?” en ondertussen geen root of trust en geen attestatie inricht, heeft het verkeerde probleem opgelost. Dat is exact dezelfde weeffout die ik in deel 1 beschreef: het verdedigen tegen een juridisch of herkomst-risico terwijl je je feitelijke security laat versloffen.

Wat betekent dit voor SEAL‑4?

De hardwarelaag is de waar CSF het hardst bijt en waar Europa het minst te vertellen heeft. Herkomst-soevereiniteit is hier vandaag simpelweg onhaalbaar. Het grootste deel van de keten is overweldigend niet-Europees, en zelfs onze grootste troef, ASML, bewijst vooral hoe internationaal verweven de keten is.

Maar er zitten twee lichtpuntjes in dit sombere verhaal::

• De hardwarebasis van een hyperscaler dankzij OCP verrassend open en dus in principe reproduceerbaar. Het probleem is niet het ontwerp, maar de investeringen en de tijd die nodig is om op grote schaal en met hoge kwaliteit de benodigde zaken te produceren.
• Hardware-integriteit is te bereiken zonder soevereine herkomst. Voor veel kritieke systemen is dat de beveiliging die er werkelijk toe doet. Daarmee is de herkomst pas een probleem als de levering niet meer kan of mag en is er geen kill-switch op reeds in gebruik genomen infrastructuur.

De les blijft dus dezelfde als in de vorige delen: gebruik het Cloud Sovereignty Framework om te zien waar de gaten zitten, maar zet het niet dogmatisch in, want dan kom je van een koude kermis thuis. Een SEAL‑4-eis op de compute-laag afdwingen betekent vandaag simpelweg dat je geen moderne hyperscalecloud hebt, punt.

De vraag is vervolgens of we daar wat aan moeten doen. Als we dat echt willen, dan moet daar beleid op gemaakt worden waarmee dit in de komende decennia wordt opgelost. Dergelijk beleid zou enorm ambitieus zijn en investeringen vergen die zo nodig nog ambitieuzer zijn. Vooralsnog is het in ieder geval verstanding om ASML als strategische troef te koesteren.

In het volgende deel klimmen we opnieuw een laag omhoog, naar het platform: het control plane dat al die hardware automatiseert, orkestreert en beveiligt. Dit is de laag waar hardware verandert in een cloud, en waar soevereiniteit een heel ander gezicht krijgt.

Het Cloud Sovereignty Framework wat DG DIGIT van de Europese Commissie in oktober 2025 presenteerde is een poging om die vraag te beantwoorden. Het framework is geen keurmerk, maar een aanbestedingsinstrument om te meten hoe soeverein een dienst werkelijk is. Het beoordeelt acht soevereiniteitsdoelstellingen (SOV‑1 tot en met SOV‑8) en kent aan elk daarvan een Sovereignty Effectiveness Assurance Level (SEAL) toe, van 0 tot 4:

• SEAL‑0 – Geen soevereiniteit.
• SEAL‑1 – EU-recht geldt in theorie; het afdwingen ervan kent uitdagingen.
• SEAL‑2 – Datasoevereiniteit: EU-recht is afdwingbaar over je data, zonder bijzondere inspanning van de klant.
• SEAL‑3 – Digitale weerbaarheid: echte EU-invloed, en niemand in het buitenland kan je uitknop omzetten.
• SEAL‑4 – Volledige digitale soevereiniteit: technologie én operatie volledig onder EU-controle, uitsluitend EU-recht, geen kritieke niet-EU-afhankelijkheden. Dit laatste betekent dat de gehele toeleveringsketen, van chips tot software volledig in de EU moet liggen.

De weging verklapt waar het werkelijk om draait, want toeleveringsketen-soevereiniteit(SOV‑5) telt voor 20% mee, de zwaarste doelstelling. Je kunt je niet juridisch of via certificering naar soevereiniteit toe redeneren. De bepalende factor is waar het silicium wordt geproduceerd en waar de code wordt geschreven. Dit verraad mogelijk ook een onderliggend doel van de EU, namelijk een manier om de economie een impuls te geven door productie van deze zaken naar de interne markt te duwen. Aangezien dit deels om specialistische kennis gaat die niet in Europa beschikbaar is, is de vraag hoe kansrijk dat is. Een poging van het om Taiwanese TSMC om een chipfabriek in de Verenigde Staten te bouwen gaat op zijn zachtst gezegd stroef.

De realitycheck van april 2026

Inmiddels is het framework geen theorie meer. Op 17 april 2026 gunde de Europese Commissie een Sovereign Cloud-aanbesteding van €180 miljoen (over een periode van zes jaar) aan vier aanbieders. De toelatingsdrempel was SEAL‑2; de meeste winnaars haalden SEAL‑3; niemand haalde SEAL‑4. Geen enkele partij. Dat betekent niet dat de inschrijvers faalden, maar dat het framework eerlijk rapporteert dat Europa afhankelijkheden heeft die op dit moment niet te omzeilen zijn.

Een kleine olifant in de kamer: zijn dit eigenlijk wel hyperscale clouds?

Het is hierbij ook nog wel even goed om stil te staan bij de omvang van de providers die de aanbesteding gegund is, in vergelijking met de Amerikaanse hyperscalers. Hyperscale gaat niet over ambitie, maar over schaal: miljoenen servers, regio’s op verschillende continenten, en investeringsbudgetten die lezen als defensiebegrotingen. Langs die meetlat is zelfs OVHcloud, Europa’s grootste cloudspeler, een orde van grootte (of twee, of drie) kleiner dan welke afzonderlijke Amerikaanse hyperscaler dan ook. Die hyperscalers geven elk in één kwartaal meer uit aan infrastructuur in Europa, dan Europa’s eigen cloudsector in jaren omzet. De ongemakkelijke waarheid: Europa heeft geen hyperscalecloud. Het heeft goede cloudproviders, maar geen hyperscaler. Een SEAL‑4-hyperscalecloud zou dus betekenen dat je tegelijk de hyperscalebasis bouwt én die soeverein maakt. Dat is nogal een onderneming en vereist enorme investeringen, investeringen waarvan je je kunt afvragen of die ooit zullen renderen, aangezien het ook jaren gaat duren om de nodige schaal en bijbehorende processen op te bouwen. Iets waar ik in volgende posts dieper op in zal gaan.

Waarom is hyperscale belangrijk?

Soevereiniteit heeft twee gezichten: juridisch (wie kan toegang rechtmatig afdwingen of blokkeren) en security (wie kan technisch binnendringen, ongeacht de regels). Het framework beoordeelt die afzonderlijk via SOV-2 en SOV-7, maar in architectuur zitten ze elkaar in de weg. Een deel van wat hyperscale hyper maakt, is dat het securitysignaal wereldwijd is en bestaat uit biljoenen dagelijkse signalen die geanalyseerd worden door een gigantisch AI-gedreven systeem op basis van de meest geavanceerde AI-modellen. Een aanval die bij één klant wordt gezien, beschermt minuten later iedereen. Een afgeschermde nationale cloud ziet slechts een fractie van dat signaal en patcht met minder collectieve wijsheid erachter. Daarnaast hebben de hyperscalers duizenden security professionals in dienst om hun cloud zo veilig mogelijk te houden, meer mensen dan het eerder genoemde OVHcloud in z’n geheel in dienst heeft.

Dat betekent dat het verdedigen tegen een juridisch risico je security kan ondermijnen en in de praktijk je daadwerkelijke soevereiniteit. Zet een workload op een klein, relatief licht geïnstrumenteerd eiland om een theoretische buitenlandse wet te vermijden, en je kunt de feitelijke weerbaarheid tegen aanvallen verlagen. Een gehackte ‘soevereine’ cloud is niet soeverein. Die heeft simpelweg een zichtbaar, juridisch en betwistbaar risico ingeruild voor een onzichtbaar, technisch, niet-betwistbaar en vaak groter risico. Voor werkelijk kritieke systemen waarbij juridische dwang de dreiging is, verdient SEAL‑3/4 zijn kosten; voor bijna al het andere is wereldwijde schaal wat de kwaadwillenden buiten houdt.

Is SEAL-4 wel nodig? En voor wie dan?

Ondanks dat ik juist daar dieper op in ga in volgende posts, is de interessante vraag niet “kan het worden gebouwd?” De juiste vraag om te stellen is of SEAL‑4 überhaupt vereist is, voor welke systemen, en onder welke omstandigheden. De oorlog in Oekraïne heeft laten zien dat de regels in oorlogstijd het raam uit gaan. Zelfs als je een SEAL‑4-cloud hebt draaien voor je kroonjuwelen, is een back-up in een SEAL‑0-cloud misschien wel wenselijk, zodat je kunt blijven opereren als je SEAL-4 cloud(je) platgebombardeerd is.

Voor de meeste workloads is zelfs SEAL‑2 overdreven. En voordat we buitenlandse juridische reikwijdte behandelen als het monster onder elk bed: hoe vaak doet dat zich voor? Zelden. Extraterritoriale verzoeken om EU-klantdata zijn uiterst ongebruikelijk en worden juist eindeloos aangehaald omdat ze zeldzaam genoeg zijn om bij naam te noemen. Sancties die een hele organisatie afsluiten zijn geopolitieke uitzonderingen. Reëel voor een kleine groep entiteiten die meestal al weten wie ze zijn. Risico is kans maal impact, en in deze debatten wordt graag een angstaanjagende impact gekoppeld aan het idee dat de kans daarop groot is, terwijl dat niet het geval is. Wie sec een risicoberekening doet, zonder de emotie, merkt dat SEAL‑0- of SEAL‑1-commoditycloud voor de meeste workloads geen compromis is, maar de juiste, verdedigbare keuze.

En dan is er nog de rekening

Die aanbesteding van €180 miljoen betekent gemiddeld ongeveer €7,5 miljoen per aanbieder per jaar, en omdat het om een raamcontract gaat, is zelfs dat een plafond, geen cheque. Ondertussen pompt elke grote Amerikaanse hyperscaler jaarlijks tientallen miljarden in Europese datacenters. De aanbesteding van de Commissie is daarmee een druppel op een gloeiende plaat: een vraagsignaal, geen industriebeleid. Maar een industriesignaal is niet genoeg. Als Europa de kloof echt wil overbruggen, moet er serieus geïnvesteerd worden (denk Chips Act, European Processor Initiative).

Bij gebrek aan die investeringen, is het beter om strategisch te kijken naar waar afhankelijkheden acceptabel zijn en hoe clouds met verschillende SEAL-levels met elkaar verbonden kunnen worden om zo verschillende dreigingen het hoofd te bieden. We moeten daarbij niet vergeten dat de supply chain afhankelijkheden ook de andere kant op werken. Nederland heeft met ASML een enorme troef in handen als het gaat om de gehele supply chain van computerchips.

Waar we voor moeten waken is dat we het Cloud Sovereignty Framework dogmatisch in gaan zetten, want dat doet veel meer kwaad dan goed. Het mooie van het Cloud Sovereignty Framework is dat het inzichtelijk maakt waar de kwetsbaarheden zitten en daarmee is het een uitstekend instrument voor gedegen risicomanagement. Dat is alleen politiek niet erg sexy en niet samen te vatten in een one-liner.

De routekaart

Het zal zo onderhand duidelijk zijn dat een SEAL-4 hyperscale cloud bouwen een enorme onderneming is, waarvan de vraag is of het überhaupt gaat lukken en of het wel de juiste oplossing is. In volgende posts ga ik dieper in op wat er nodig is om een hyperscalecloud te bouwen. We klimmen van onder naar boven, langs zes lagen, en stellen op elke verdieping dezelfde twee vragen: hoe ziet de toeleveringsketen eruit wanneer je het bouwt, en wanneer je het exploiteert?

1. Datacenters: gebouwen, stroom, koeling, glasvezel.
2. Infrastructuur: compute-, storage- en netwerkhardware.
3. Platform: het control plane dat alles automatiseert en beveiligt.
4. Kerndiensten: IaaS: VM’s, containers, storage, networking, identity, keys.
5. Diensten op hoger niveau: PaaS: messaging, databases, IoT, analytics, AI.
6. Ecosysteem: ISV’s, integrators en managed-servicepartners.

Door die vragen te stellen, kunnen we kijken naar waar de gaten zitten, hoe erg dat eigenlijk is en wat we eraan kunnen doen.

The Cloud Sovereignty Framework that DG DIGIT of the European Commission presented in October 2025 is an attempt to answer that question. The framework is not a label, but a procurement tool for measuring how sovereign a service really is. It assesses eight sovereignty objectives, SOV-1 through SOV-8, and assigns each of them a Sovereignty Effectiveness Assurance Level, SEAL, from 0 to 4:

• SEAL-0 No sovereignty.
• SEAL-1 EU law applies in theory; enforcing it comes with challenges.
• SEAL-2 Data sovereignty: EU law is enforceable over your data, without special effort from the customer.
• SEAL-3 Digital resilience: real EU influence, and no one abroad can flip your off switch.
• SEAL-4 Full digital sovereignty: technology and operations fully under EU control, EU law only, no critical dependencies outside the EU. This last point means that the entire supply chain, from chips to software, must be located in the EU.

The weighting reveals what really matters, because supply chain sovereignty , SOV-5, counts for 20%, the heaviest objective. You cannot reason your way to sovereignty through law or certification. The deciding factor is where the silicon is produced and where the code is written. This may also betray an underlying EU objective, namely a way to give the economy a boost by pushing production of these things into the internal market. Since this partly concerns specialist knowledge that is not available in Europe, the question is how promising that is. An attempt by Taiwan based TSMC to build a chip factory in the United States is, to put it mildly, not going smoothly.

The reality check of April 2026

By now the framework is no longer theory. On 17 April 2026, the European Commission awarded a Sovereign Cloud procurement worth €180 million, over a period of six years, to four providers. The admission threshold was SEAL-2; most winners reached SEAL-3; no one reached SEAL-4. Not a single party. That does not mean the bidders failed, but that the framework honestly reports that Europe has dependencies that cannot currently be avoided.

A small elephant in the room: are these actually hyperscale clouds?

It is also worth pausing here to consider the size of the providers that won the procurement, compared with the American hyperscalers. Hyperscale is not about ambition, but about scale: millions of servers, regions on different continents, and investment budgets that read like defense budgets. By that yardstick, even OVHcloud, Europe’s largest cloud player, is one order of magnitude, or two or three, smaller than any individual American hyperscaler. Those hyperscalers each spend more on infrastructure in Europe in a single quarter than Europe’s own cloud sector turns over in years. The uncomfortable truth: Europe does not have a hyperscale cloud. It has good cloud providers, but no hyperscaler. A SEAL-4 hyperscale cloud would therefore mean building the hyperscale base and making it sovereign at the same time. That is quite an undertaking and requires enormous investment, investment whose return you may wonder about, since it will also take years to build the required scale and the processes that come with it. I will explore that in more depth in the next posts.

Why is hyperscale important?

Sovereignty has two faces: legal, meaning who can lawfully compel or block access, and security, meaning who can technically break in regardless of the rules. The framework assesses these separately through SOV-2 and SOV-7, but in architecture they get in each other’s way. Part of what makes hyperscale hyper is that the security signal is global and consists of trillions of daily signals analyzed by a giant AI driven system based on the most advanced AI models. An attack seen at one customer protects everyone else minutes later. A shielded national cloud sees only a fraction of that signal and patches with less collective wisdom behind it. In addition, the hyperscalers employ thousands of security professionals to keep their cloud as secure as possible, more people than the previously mentioned OVHcloud employs in total.

That means defending against a legal risk can undermine your security and, in practice, your actual sovereignty. Put a workload on a small, relatively lightly instrumented island to avoid a theoretical foreign law, and you may reduce its real resilience against attacks. A hacked sovereign cloud is not sovereign. It has simply exchanged a visible, legal and contestable risk for an invisible, technical, uncontestable and often larger risk. For truly critical systems where legal compulsion is the threat, SEAL-3 or 4 earns its cost; for almost everything else, global scale is what keeps malicious actors out.

Is SEAL-4 really necessary? And for whom?

Although I will go into exactly that in more depth in the next posts, the interesting question is not can it be built? The right question to ask is whether SEAL-4 is required at all, for which systems, and under which circumstances. The war in Ukraine has shown that in wartime the rules go out the window. Even if you have a SEAL-4 cloud running for your crown jewels, a backup in a SEAL-0 cloud might be desirable, so you can keep operating if your SEAL-4 cloud is bombed flat.

For most workloads, even SEAL-2 is excessive. And before we treat foreign legal reach as the monster under every bed: how often does it happen? Rarely. Extraterritorial requests for EU customer data are extremely uncommon and are cited endlessly precisely because they are rare enough to be named. Sanctions that cut off an entire organization are geopolitical exceptions. They are real for a small group of entities that usually already know who they are. Risk is probability times impact, and in these debates people like to pair a frightening impact with the idea that the probability is high, while that is not the case. Anyone who makes a dry risk calculation, without the emotion, will see that SEAL-0 or SEAL-1 commodity cloud is not a compromise for most workloads, but the right and defensible choice.

And then there is the bill

That €180 million procurement means an average of about €7.5 million per provider per year, and because it is a framework contract, even that is a ceiling, not a cheque. Meanwhile, every major American hyperscaler pumps tens of billions annually into European data centers. The Commission procurement is therefore a drop in the ocean: a demand signal, not industrial policy. But an industry signal is not enough. If Europe really wants to bridge the gap, it needs serious investment, think Chips Act and European Processor Initiative.

Without those investments, it is better to look strategically at where dependencies are acceptable and how clouds with different SEAL-levels can be connected to address different threats. We should not forget that supply chain dependencies also work the other way around. With ASML, the Netherlands holds a huge trump card when it comes to the entire supply chain for computer chips.

What we must guard against is using the Cloud Sovereignty Framework dogmatically, because that does far more harm than good. The strength of the Cloud Sovereignty Framework is that it makes visible where the vulnerabilities are, and that makes it an excellent instrument for solid risk management. That is just not very politically sexy and cannot be summarized in a one liner.

The roadmap

By now it should be clear that building a SEAL-4 hyperscale cloud is an enormous undertaking, and that the question is whether it can succeed at all and whether it is the right solution. In the next posts, I will go deeper into what it takes to build a hyperscale cloud. We will climb from bottom to top, along six layers, and ask the same two questions on every floor: what does the supply chain look like when you build it, and when you operate it?

1. Data centers: buildings, power, cooling, fiber.
2. Infrastructure: compute, storage and network hardware.
3. Platform: the control plane that automates and secures everything.
4. Core services: IaaS: VMs, containers, storage, networking, identity, keys.
5. Higher level services: PaaS: messaging, databases, IoT, analytics, AI.
6. Ecosystem: ISVs, integrators and managed service partners.

By asking those questions, we can look at where the gaps are, how much those gaps matter, and if needed what we can do about them.

Note: this post has been updated several times to include latest events, but has not been updated to reflect risks associated with sanctions by a government. If I post an article on that, I will link to it here.

First, legal access doesn’t necessarily stop at the border. Under certain conditions, requesting data that is stored in another country is possible. The United Stated CLOUD Act is referenced most in this context, but considering most laws in many countries predate the global digitization, it is safe to assume there are countries with laws that can be interpreted to giving government the authority to gain legal access to data outside the country. Even in my own country this doesn’t seem to be clear cut.

Second, the risk of legal access by a foreign jurisdiction is extremely small, regardless of where data is stored. To get an idea of the risk, you can look at the Government Requests for Customer Data Report that Microsoft publishes. It provides the numbers around government access, grouped by country. While the by country numbers say nothing about whether it was a cross-border request, it is striking that absolute number of requests done by countries in Europe is far higher than the United States. I have no idea why that is, but I hope it is because European law enforcement is better at its job. The cross-border requests by the United States are called out specifically in the report and for as far as these reports go back (which is almost a decade now), the number of cross-border requests is pretty low (around 50 per 6 months) and about 10% lead to disclosure of data (which means 90% are successfully redirected or fought in a court of law). In the grand scheme of things, these are very low numbers and you can bet these have to do with international terrorism, drug trafficking, child pornography or other heavy crimes.

Another risk commonly cited is data access requests from intelligence agencies and these are a bit murkier. Microsoft also reports on this kind of access, specifically for the US Foreign Intelligence Surveillance Act (FISA) and National Security Letters, and these numbers are given in ranges, which is already quite something considering this is considered sensitive information.

However, even if you include access for intelligence purposes, there are several areas that pose significantly higher risk than the jurisdictional risk of data not being resident:

• Cyber-attacks from hackers or nation states trying to access your data or make your data unavailable through DDoS attacks, by wiping your data, or by keeping it ransom. Country borders don’t stop these cyber-attacks.
• Major natural disasters such as an earthquake or flood are a risk in many countries and are much less predictable than jurisdictional risk.
• Some countries are at risk from invasion, in which case data residency becomes a strategic risk in case the invasion force gains control over the infrastructure, which is a risk Ukraine is familiar with.
• Datacenters can be a target in war, as recently shown in the Iran war.

With networking becoming more available in even the remotest places and satellite networking that is even available if hard links are cut, the location of most data and applications doesn’t really matter. Exceptions to this are applications that require (ultra) low latency or potentially highly sensitive data you don’t want to run connected to a public network (e.g. data on spies and missiles).

The truth is that while there is a lot of data out there that probably shouldn’t be public, most of that data is of little interest to foreign jurisdictions or intelligence. The ERP system of your local municipality, the systems of the water management department, or even most healthcare data is not that interesting for legal procedures. Criminals would however love to get their hands on that data or disrupt these systems. And because these systems are usually connected to the internet in some way to provide services to citizens, these systems carry significant cyber security risk. That obviously doesn’t mean we should ignore legal access and intelligence gathering risks, but we need to weigh that risk appropriately.

What this means is that for many applications the traditional CIA (Confidentiality, Integrity, Availability) attributes turn into two attributes: Security and Availability. And for different scenarios, different solutions will have different advantages and disadvantages. From a disaster perspective, the most available compute and storage infrastructure on the planet is the hyperscale cloud. And from a cybersecurity perspectice, hyperscale cloud providers process trillions of security signals every day to keep their customers save. But there are other considerations when it comes to availability, for example supply chain issues, boycott scenarios, and more. Weighing these risks and using the right architecture to mitigate these risks is much more important than whether data is located inside the country or not.

As a citizen, it is my hope that my country’s government organizations will look at their applications and classify them in a rational manner to properly assess and weigh the risk to data, and to not just look at jurisdictional risks. Unfortunately, the current sentiment driven by geopolitical unrest is one that focuses on building government controlled infrastructure. This in itself is not a bad idea, but it should be used as one solution of many, not as THE solution.