The core services from the previous part are, if you don’t count the operation, hardware rental. Functionally, you still have to arrange everything yourself. That changes in this layer and this is where customers really benefit from cloud. In this layer, you don’t get components but outcomes: a database that manages itself, a messaging platform that is always running, a complete application for HR, finance or collaboration. Here, the lock-in also increases quickly. Virtual machines, containers, and storage can be moved somewhere else with some effort. With PaaS and SaaS services, that depends on choices you make (or have made in the past).

I ask the same two questions again: what do you need to build it, and what do you need to operate it? On top of this layer, a third question is added: what does it cost to leave?

From components to outcomes

PaaS and SaaS are on the same spectrum and both shift responsibility from the customer to the supplier. With IaaS, you manage the operating system, the middleware, the application and the data yourself. With PaaS, the vendor takes over the operating system and middleware: you get a database, an integration platform, an analytics environment, or an AI service as an API. With SaaS, the supplier also takes over the application. You only provide your users, your configuration and your data.

Every step on that spectrum delivers efficiency. Security, scalability, and continuity are no longer your problem. Each step also gives up control. You’re exchanging operational burden for dependency, and for most organizations and most applications, that’s an excellent trade-off. That’s what this series is all about: for most applications, high sovereignty requirements are not necessary. But for the applications where they are needed, you have to know what you are giving up.

Something also happens in this layer with the stacking from the previous parts. A PaaS or SaaS service consists of dozens of core services with a good layer of their own logic above them. All the dependencies from parts 2 to 5 are still included, and the supplier of the service adds its own layer: its own code, its own operation, its own jurisdiction. The sovereignty level of a service is at most as high as the weakest link in that pile. If it is possible to get a SaaS service from a non-European supplier on a European/sovereign cloud, this service itself is not sovereign. Conversely, a European SaaS application on a non-European hyperscaler is not either, although measures can be taken to guard against data requests.

Three forms of lock-in

Lockin is often treated as one thing, but on this layer it comes in three forms. Each form requires a different answer.

The first form is the interface. Do you use a service via an open standard, such as a PostgreSQL protocol, a Kafka API, S3 or the Kubernetes API from part 5, or via the supplier’s own API? With an open standard, a second provider or running it yourself is a realistic way out. With your own API, leaving means rewriting. That’s not necessarily a bad thing, because your own services can be technically better. It just has to be a conscious choice.

The second form is the data. Data has “gravity” because services that need the data often have to be close by to keep latency low. This is even more true for AI than for more traditional applications. As a result, the more data there is somewhere, the more it will revolve around and the more difficult it becomes to move the whole. Data (distribution) design is therefore becoming increasingly important and indispensable in a multi-cloud strategy. Open formats help with this in part. It does not immediately reduce gravity, but data is easier to move because there is a cut between the storage and what uses that data. For example, this is increasingly the norm for analytics platforms. Data is increasingly stored in open file and table formats in object storage, and the analyses that rely on it are interchangeable. Storage and computing power are therefore not only technically but also contractually separated.

The third form is the most difficult and is most often underestimated: the meaning. I mean everything you’ve put into a shift over the years in addition to the data itself. Configuration, workflows, authorization models, reports, integrations, and most importantly, the way people started doing their jobs. With SaaS, this is the main form of lock-in. A full data export from a SaaS application gives you the data back, but not the processes. Leaving a SaaS vendor is therefore rarely an IT project. It is a change program in the organization.

For the framework, this mainly affects SOV3 and SOV6. It is less about whether someone can access your data, and more about whether you can continue without this service.

PaaS: Open Core, Closed Edges

With PaaS, the good news is that there is a mature open alternative for almost every category. For databases, messaging, analytics, integration and more and more AI tooling, there are open-source projects that can compete with commercial services. A managed service based on such a project has a built-in way out.

Largely, because the pattern from part 5 of Kubernetes also applies here. The core is portable, the edges are not. What makes a PaaS service valuable are precisely the edges: the link with identity, key management, backups and point-in-time restore, monitoring, automatic failover, extensions that only exist with that one supplier. The application moves fine, the operating model around it does not. Portability is not a trait you get, but a trait you test.

In addition, there is a less visible dependency. Behind many open-source projects are commercial parties that do most of the development work, often non-European. A number of them have changed their license in recent years to prevent cloud providers from offering their software as a service. So “open source” does not automatically mean “free to use as a service forever”. For SOV5 and SOV6, it’s not just whether the code is open that counts, but also who controls the project. Projects under a neutral foundation are substantially more robust than projects that depend on one company.

SaaS: the supplier is the operation

With SaaS, the question of sovereignty shifts even further. You no longer manage anything yourself. The vendor writes the code, runs the operation, determines the release calendar, and decides which functionality will come and which will go. In the framework of SaaS, you don’t just look at where the data is, but especially at who does the operation (SOV4) and under what jurisdiction those people work (SOV2).

Interestingly, Europe is doing relatively well on this layer. Where Europe is mainly a spectator in hardware, there are major European players in business software, such as Amadeus, SAP and TomTom. There is also a vibrant ecosystem of smaller SaaS vendors and open-source alternatives for collaboration and document management, for example. For a large part of the functionality that organizations need, there is a European alternative. This makes this, just like HSMs in part 5, one of the places where Europe plays a role. There is a caveat to this, because those SaaS services can only be called sovereign if they run on their own infrastructure, with their own operation. However, many SaaS services run on one of the hyperscalers, because of the cost efficiency and the focus on their own functionality.

The question of sovereignty goes directly against that efficiency. SaaS is cheap and good because it’s multi-tenant: one codebase, one operation, thousands or millions of customers. Every improvement and every security update reaches everyone immediately. Offering that service on multiple clouds, or even in a sovereign private cloud, requires at least an expansion of the operations team and often even a separate operations team, possibly with nationality requirements for people who have been screened. That breaks the efficiency and in fact the business model of SaaS. And that’s not the only problem. This is also where the limited security signal discussed in the earlier parts comes into play. In addition, a separate instance is behind with updates, which makes the vulnerability even greater. You get more control, but a less good product at a higher price. Sometimes that is the right exchange, often not.

With SaaS, it is also difficult to separate what you can control yourself. With PaaS, you can still arrange a lot with architectural choices: open standards, open formats, your own keys. With SaaS, the contract remains for the most part, with its own identity via federation and its own keys where the supplier supports it. And the tension from part 5 is at its sharpest here: a SaaS application that has to do something meaningful with your data, such as searching, analyzing or applying AI to it, must be able to read that data. Full control over keys and full functionality do not go well together.

AI: where everything comes together

AI should be mentioned separately here, because that’s where everything from this series comes together. AI services are available as IaaS (hardware to develop and run models yourself), PaaS (models and inference as API) and SaaS (assistants and agents in applications) at the same time. These services require specific hardware, which was already shown in part 3 to be almost entirely non-European. Due to the amount of energy they use and the heat that is generated, they also need the most modern data center innovations. Innovations that are mainly driven by the hyperscale cloud providers, as discussed in part 2. The associated speed of innovation is what Europe is struggling with. The most powerful models are largely non-European and cannot be run yourself. And the tooling around it is developing at a pace that no other service can achieve.

At the same time, AI is also a good example of how you can create space with architecture. An open-weight model in your own environment cannot be turned off, cannot be adjusted unnoticed and cannot be withdrawn. For many applications, such a model is more than sufficient. So the trade-off is the same as everywhere else on this layer: the best there is, or what you can control. And you can make that choice differently for each application.

Build

For those who want to offer a hyperscale cloud, the number of services and their richness is a particular challenge. The hyperscalers offer hundreds of PaaS services with an extensive feature set, whereas European cloud providers often limit themselves to the core services from the previous part and a limited number of PaaS services. That set of services is growing, but relatively slowly because each of those services requires manpower to build, certify and operate. Even if the service uses open source, this is not easy, because you can’t just assume that everything is good. So the build is much more than installing it on a few servers.

A sovereign cloud therefore has to make choices and can therefore only focus on those must-have services. A sovereign cloud with ten well-managed services is better than one with a hundred that only do half of it, but it does have the disadvantage that it is more difficult for a third party to build a SaaS service on it. Most SaaS services do not build their own cloud, but build on top of an existing cloud, because it removes a lot of complexity. Few SaaS services are available on different clouds, as each additional version requires additional expertise and manpower, which comes at the expense of efficiency.

The good news is that the greenfield advantage from part 5 also applies here. Those who start today can incorporate portability, open formats, and crypto-agility into the design from day one, rather than having to bake them in later.

Operate

The operation again contains the real bill, and at this layer it will be even higher. Each department partly conducts its own operation with its own experts. A team that manages a database service at scale is not the same team that keeps an integration platform or an AI service running. The certification burden can build on the shared basis from parts 4 and 5, but ultimately each service must be certified separately. This means that this process must also be industrialized in order to keep the effort as low as possible.

All this requires a lot of (specialist) knowledge. The people who can build and operate these types of services at scale are scarce and in demand worldwide. A sovereign provider competes for those people with the largest employers in the tech sector. And because SEAL4 requires the operation to take place entirely within the EU and under EU law, the pond in which to fish is even smaller.

Of course, customers also have requirements. They expect stability from core services. They expect innovation from PaaS and especially SaaS: new features, better integrations and now new AI applications. There is a business risk in this, which is a vicious circle: a sovereign provider that cannot innovate loses customers while customers are needed for the required scale to invest in the necessary stability and innovation.

And then there is the security aspect. More services means a larger attack surface and at the same time we see that AI is able to exploit vulnerabilities faster and faster. This manifests itself in pressure on the operation to be able to patch quickly and often (daily if necessary). Another aspect is that the data breaches you read about the most are often caused by software misconfigurations, especially PaaS and SaaS services. Anyone who sees and can fix configuration errors with thousands of customers at the same time has an advantage that a small environment does not have. Scale is therefore of vital importance here.

Exit: the question that weighs most heavily here

In part 5, I called portability the most underestimated instrument of sovereignty. It weighs most heavily on this layer, because this is where the choices fall that determine whether an exit is possible at all. In practical terms, it comes down to a handful of questions you should ask with any PaaS or SaaS service:

• Is the interface an open standard or a proprietary API?
• Is the data in an open format, and can you export it completely?
• Can you also include your configuration, workflows and authorizations, or just the data?
• Is there a second provider, or can you run it yourself?
• Have you ever tested the exit?

The latter question is sometimes overlooked. An exit plan that has never been implemented is an assumption. With SaaS, you also have to add an organizational question: how long does it take your organization to switch to another application? That is not in the technology and the contract, but it does determine how sovereign you really are.

What does this mean for SEAL4?

On this layer, hope and disillusionment are close together. For PaaS on open standards and for part of the SaaS offering, SEAL4 is not unrealistic at the software level. The software is there, European suppliers are there, and the market is moving from regulation to open formats, features and contract terms that facilitate an exit, on its own and under pressure. What is missing are scale, operational maturity and a clear choice of which services you do and do not offer. In addition, the accumulation will continue to apply. No matter how sovereign a service is built, it runs on the layers from parts 2 to 5, and for many services this is by the hyperscalers themselves or by parties that have built their services on top of them.

De kerndiensten uit het vorige deel zijn, als je de operatie niet meetelt, huur van hardware. Functioneel moet je alles zelf nog regelen. Dat verandert in deze laag en dit is waar klanten echt voordeel halen uit cloud. In deze laag krijg je namelijk geen componenten maar uitkomsten: een database die zichzelf beheert, een berichtenplatform dat altijd draait, een complete applicatie voor HR, financiën of samenwerking. Hier wordt de lock-in ook snel groter. Virtuele machines, containers, en opslag kun je met wat moeite nog ergens anders naartoe verhuizen. Met PaaS- en SaaS-diensten hangt dat af van keuzes die je maakt (of in het verleden gemaakt hebt).

Ik stel weer dezelfde twee vragen: wat heb je nodig om het te bouwen, en wat heb je nodig om het te opereren? Op deze laag komt er een derde vraag bij: wat kost het om weg te gaan?

Van componenten naar uitkomsten

PaaS en SaaS liggen op hetzelfde spectrum en schuiven allebei verantwoordelijkheid van de klant naar de leverancier. Bij IaaS beheer je zelf het besturingssysteem, de middleware, de applicatie en de data. Bij PaaS neemt de leverancier het besturingssysteem en de middleware over: je krijgt een database, een integratieplatform, een analyseomgeving of een AI-dienst als API. Bij SaaS neemt de leverancier ook de applicatie over. Je levert alleen nog je gebruikers, je configuratie en je data aan.

Elke stap op dat spectrum levert efficiëntie op. Beveiliging, schaalbaarheid, en continuïteit zijn niet meer jouw probleem. Elke stap levert ook controle in. Je wisselt operationele last in voor afhankelijkheid, en voor de meeste organisaties en de meeste toepassingen is dat een uitstekende ruil. Daar gaat deze serie steeds over: voor de meeste toepassingen zijn hoge soevereiniteitseisen niet nodig. Maar voor de toepassingen waar ze wel nodig zijn, moet je weten wat je inlevert.

Er gebeurt in deze laag ook iets met de stapeling uit de vorige delen. Een PaaS- of SaaS-dienst bestaat uit tientallen kerndiensten met een flinke laag eigen logica erboven. Alle afhankelijkheden uit deel 2 tot en met 5 zitten er nog onder, en de leverancier van de dienst voegt er een eigen laag aan toe: eigen code, eigen operatie, eigen jurisdictie. Het soevereiniteitsniveau van een dienst is hooguit zo hoog als de zwakste schakel in die stapel. Als het al mogelijk is om een SaaS-dienst van een niet-Europese leverancier op een Europese/soevereine cloud te krijgen, is deze dienst zelf niet soeverein. Andersom is een Europese SaaS-applicatie op een niet-Europese hyperscaler dat ook niet, al zijn er wel maatregelen te treffen om te wapenen tegen dataverzoeken.

Drie vormen van lock‑in

Lock‑in wordt vaak als één ding behandeld, maar op deze laag komt hij in drie vormen voor. Elke vorm vraagt om een ander antwoord.

De eerste vorm is de interface. Gebruik je een dienst via een open standaard, zoals een PostgreSQL-protocol, een Kafka-API, S3 of de Kubernetes-API uit deel 5, of via een eigen API van de leverancier? Bij een open standaard is een tweede aanbieder of zelf draaien een realistische uitweg. Bij een eigen API betekent vertrekken herschrijven. Dat is niet per se slecht, want eigen diensten kunnen technisch beter zijn. Het moet alleen wel een bewuste keuze zijn.

De tweede vorm is de data. Data heeft “zwaartekracht” omdat diensten die de data nodig hebben vaak dichtbij moeten staan om de latency laag te houden. Voor AI geldt dit nog sterker dan voor meer traditionele toepassingen. Hierdoor is het zo dat hoe meer data er ergens staat, hoe meer er omheen gaat draaien en hoe lastiger het wordt om het geheel te verplaatsen. Data (distributie) ontwerp wordt daardoor steeds belangrijker en bij een multi-cloud strategie onmisbaar. Open formaten helpen hier deels bij. De zwaartekracht wordt er niet direct minder door, maar data is makkelijker te verplaatsen omdat er een knip ligt tussen de opslag en dat wat die data gebruikt. Bij bijvoorbeeld analytics platformen is dit steeds meer de norm. Data staat steeds vaker in open bestands- en tabelformaten in objectopslag, en de analyses die erop rekenen zijn verwisselbaar. Opslag en rekenkracht zijn daarmee niet alleen technisch maar ook contractueel van elkaar losgemaakt.

De derde vorm is de lastigste en wordt het vaakst onderschat: de betekenis. Ik bedoel alles wat je in de loop der jaren in een dienst hebt gestopt naast de data zelf. Configuratie, workflows, autorisatiemodellen, rapportages, integraties, en vooral de manier waarop mensen hun werk zijn gaan doen. Bij SaaS is dit de belangrijkste vorm van lock‑in. Een volledige data-export uit een SaaS-applicatie geeft je de gegevens terug, maar niet de processen. Vertrekken bij een SaaS-leverancier is daarom zelden een IT-project. Het is een veranderprogramma in de organisatie.

Voor het framework raakt dit vooral SOV‑3 en SOV‑6. Het gaat dan minder om de vraag of iemand bij je data kan, en meer om de vraag of je zonder deze dienst verder kunt.

PaaS: open kern, gesloten randen

Bij PaaS is het goede nieuws dat er voor bijna elke categorie een volwassen open alternatief bestaat. Voor databases, messaging, analytics, integratie en steeds meer AI-tooling zijn er open-sourceprojecten die zich met commerciële diensten kunnen meten. Een beheerde dienst die op zo’n project is gebaseerd, heeft een ingebouwde uitweg.

Grotendeels, want het patroon uit deel 5 bij Kubernetes geldt hier ook. De kern is portabel, de randen niet. Wat een PaaS-dienst waardevol maakt, zijn juist de randen: de koppeling met identiteit, het sleutelbeheer, de back-ups en point-in-time restore, de monitoring, de automatische failover, extensies die alleen bij die ene leverancier bestaan. De applicatie verhuist prima, het operationele model eromheen niet. Portabiliteit is ook hier geen eigenschap die je krijgt, maar een eigenschap die je test.

Daar komt een minder zichtbare afhankelijkheid bij. Achter veel open-sourceprojecten zitten commerciële partijen die het meeste ontwikkelwerk doen, vaak niet-Europese. Een aantal van hen heeft de afgelopen jaren de licentie aangepast om te voorkomen dat cloudproviders hun software als dienst aanbieden. “Open source” betekent dus niet automatisch “voor altijd vrij te gebruiken als dienst”. Voor SOV‑5 en SOV‑6 telt niet alleen of de code open is, maar ook wie het project bestuurt. Projecten onder een neutrale stichting zijn wezenlijk robuuster dan projecten die van één bedrijf afhangen.

SaaS: de leverancier is de operatie

Bij SaaS verschuift de soevereiniteitsvraag nog verder. Je beheert niets meer zelf. De leverancier schrijft de code, draait de operatie, bepaalt de releasekalender en beslist welke functionaliteit er komt en welke verdwijnt. In het framework kijk je bij SaaS dus niet alleen naar waar de data staat, maar vooral naar wie de operatie doet (SOV‑4) en onder welke jurisdictie die mensen werken (SOV‑2).

Interessant is dat Europa op deze laag relatief goed meedoet. Waar Europa in hardware vooral toeschouwer is, zijn er in bedrijfssoftware grote Europese spelers, zoals Amadeus, SAP en TomTom. Verder is er een levendig ecosysteem van kleinere SaaS-leveranciers en open-sourcealternatieven voor bijvoorbeeld samenwerking en documentbeheer. Voor een groot deel van de functionaliteit die organisaties nodig hebben, bestaat een Europees alternatief. Daarmee is dit, net als HSM’s in deel 5, een van de plekken waar Europa meespeelt. Daar zit wel een kanttekening aan, want die SaaS-diensten zijn alleen soeverein te noemen als ze draaien op eigen infrastructuur, met eigen operatie. Veel SaaS-diensten draaien echter op een van de hyperscalers, vanwege de kosten efficiency en de focus op de eigen functionaliteit.

De soevereiniteitsvraag gaat regelrecht tegen die efficiency in. SaaS is goedkoop en goed omdat het multi-tenant is: één codebase, één operatie, duizenden of miljoenen klanten. Elke verbetering en elke beveiligingsupdate komt meteen bij iedereen terecht. Die dienst op meerdere clouds aanbieden, of zelfs in een soevereine private cloud vereist op z’n minst een uitbreiding van het operationele team en vaak zelfs een apart operationeel team, eventueel met nationaliteitseisen mensen die gescreend zijn. Dat breekt de efficiency en in feite het bedrijfsmodel van SaaS. En dat is niet het enige probleem. Hier komt ook weer het beperkte security signaal besproken in de eerdere delen om de hoek kijken. Bovendien loopt een aparte instantie achter met updates, wat de kwetsbaarheid nog groter maakt. Je krijgt dan wel meer controle, maar een minder goed product tegen een hogere prijs. Soms is dat de juiste ruil, vaak niet.

Bij SaaS is ook nauwelijks te scheiden wat je zelf in de hand hebt. Bij PaaS kun je met architectuurkeuzes nog veel regelen: open standaarden, open formaten, eigen sleutels. Bij SaaS blijft daar grotendeels het contract van over, met eigen identiteit via federatie en eigen sleutels waar de leverancier dat ondersteunt. En de spanning uit deel 5 is hier op z’n scherpst: een SaaS-applicatie die iets zinnigs met je data moet doen, zoals zoeken, analyseren of AI erop loslaten, moet die data kunnen lezen. Volledige controle over sleutels en volledige functionaliteit gaan slecht samen.

AI: waar alles samenkomt

AI moet hier apart genoemd worden, omdat daar alles uit deze serie samenkomt. AI-diensten zijn er als IaaS (hardware om zelf modellen op te ontwikkelen en uit te voeren, PaaS (modellen en inference als API) en SaaS (assistenten en agents in applicaties) tegelijk. Deze diensten vereisen specifieke hardware, waarvan uit deel 3 al bleek dat die vrijwel volledig niet-Europees is. Door de hoeveelheid energie die ze gebruiken en warmte die daarbij gegenereerd wordt, hebben ze ook de modernste datacenter innovaties nodig. Innovaties die vooral gedreven worden door de hyperscale cloud providers, zoals behandeld in deel 2. De daarmee gepaarde innovatiesnelheid is waar Europa moeite mee heeft. De krachtigste modellen zijn grotendeels niet-Europees en niet zelf te draaien. En de tooling eromheen ontwikkelt zich in een tempo dat geen enkele andere dienst haalt.

Tegelijk is AI ook een goed voorbeeld van hoe je met architectuur ruimte kunt maken. Een open-weight model in je eigen omgeving kan niet worden uitgezet, niet ongemerkt worden aangepast en niet worden ingetrokken. Voor veel toepassingen is zo’n model ruim voldoende. De afweging is dus dezelfde als overal op deze laag: het beste wat er is, of wat je in de hand hebt. En die keuze kun je per toepassing anders maken.

De bouw

Voor wie een hyperscale cloud wil bieden is met name het aantal diensten en de rijkheid daarvan een uitdaging. De hyperscalers bieden honderden PaaS-diensten met een uitgebreide feature set, daar waar Europese cloud providers zich veelal beperken tot de kerndiensten uit het vorige deel en een beperkt aantal PaaS-diensten. Die set aan diensten groeit wel, maar relatief langzaam omdat voor elk van die diensten mankracht nodig is om deze te bouwen, te certificeren en te opereren. Zelfs als de dienst gebruik maakt van open source is dit niet eenvoudig, omdat je er niet zomaar vanuit kunt gaan dat alles goed is. De bouw is dus veel meer dan het installeren op een paar servers.

Een soevereine cloud moet dus keuzes maken en kan zich daardoor alleen richten op die must-have diensten. Een soevereine cloud met tien goed beheerde diensten is beter dan een met honderd die het maar half doen, maar heeft wel het nadeel dat het moeilijker voor een derde partij om daar een SaaS-dienst op te bouwen. De meeste SaaS-diensten bouwen namelijk niet een eigen cloud, maar bouwen bovenop een bestaande cloud, omdat die een heleboel complexiteit wegneemt. Er zijn maar weinig SaaS-diensten die op verschillende clouds beschikbaar zijn, aangezien elke extra versie extra expertise en mankracht vereist, wat ten koste gaat van efficiency.

Het goede nieuws is wel dat het greenfield-voordeel uit deel 5 hier ook geldt. Wie vandaag begint, kan portabiliteit, open formaten en crypto-agility vanaf dag één in het ontwerp opnemen, in plaats van ze er later in te moeten bakken.

De operatie

Bij de operatie zit opnieuw de echte rekening, en op deze laag wordt die nog hoger. Elke dienst voert deels een eigen operatie met eigen experts. Een team dat een databasedienst op schaal beheert, is niet hetzelfde team dat een integratieplatform of een AI-dienst draaiende houdt. De certificeringslast kan wel bouwen op de gedeelde basis uit deel 4 en 5, maar uiteindelijk moet elke dienst afzonderlijk gecertificeerd worden. Dit betekent dat ook dit proces geïndustrialiseerd moet worden om de inspanning zo laag mogelijk te houden.

Dit alles vereist veel (specialistische) kennis. De mensen die dit soort diensten op schaal kunnen bouwen en bedienen, zijn schaars en wereldwijd gewild. Een soevereine aanbieder concurreert om die mensen met de grootste werkgevers in de techsector. En omdat SEAL‑4 vereist dat de operatie volledig binnen de EU en onder EU-recht plaatsvindt, is de vijver waarin gevist kan worden nog kleiner.

Klanten hebben natuurlijk ook eisen. Van kerndiensten verwachten ze stabiliteit. Van PaaS en vooral SaaS verwachten ze vernieuwing: nieuwe functies, betere integraties en nu nieuwe AI-toepassingen. Hier zit een bedrijfsrisico in wat een vicieuze cirkel is:  een soevereine aanbieder die niet kan innoveren verliest klanten terwijl klanten juist nodig zijn voor de vereiste schaal om te investeren in de benodigde stabiliteit en vernieuwing.

En dan is er nog het security aspect. Meer diensten betekent een groter aanvalsoppervlak en tegelijk zien we dat AI steeds sneller lekken weet te exploiteren. Dit manifesteert zich in druk op de operatie om snel en vaak (zo nodig dagelijks) te kunnen patchen. Een ander aspect is dat de datalekken waar je het meest over leest vaak veroorzaakt worden door verkeerde configuraties van software, en dat gaat dan met name over PaaS- en SaaS-diensten. Wie configuratiefouten bij duizenden klanten tegelijk ziet en kan verhelpen, heeft een voorsprong die een kleine omgeving niet heeft. Schaal is hier dus van levensbelang.

Exit: de vraag die hier het zwaarst weegt

In deel 5 noemde ik portabiliteit het meest onderschatte soevereiniteitsinstrument. Op deze laag weegt het het zwaarst, omdat hier de keuzes vallen die bepalen of een exit überhaupt kan. Praktisch komt het neer op een handvol vragen die je bij elke PaaS- of SaaS-dienst zou moeten stellen:

• Is de interface een open standaard of een eigen API?
• Staat de data in een open formaat, en kun je die volledig exporteren?
• Kun je je configuratie, workflows en autorisaties ook meenemen, of alleen de data?
• Bestaat er een tweede aanbieder, of kun je het zelf draaien?
• Heb je de exit ooit getest?

Die laatste vraag wordt nog wel eens over het hoofd gezien. Een exitplan dat nooit is uitgevoerd, is een aanname. Bij SaaS moet je er bovendien een organisatievraag aan toevoegen: hoe lang heeft je organisatie nodig om op een andere applicatie over te stappen? Dat zit niet in de techniek en het contract, maar het bepaalt wel hoe soeverein je werkelijk bent.

Wat betekent dit voor SEAL‑4?

Op deze laag liggen hoop en ontnuchtering dicht bij elkaar. Voor PaaS op open standaarden en voor een deel van het SaaS-aanbod is SEAL‑4 op softwareniveau niet onrealistisch. De software is er, Europese leveranciers zijn er, en de markt beweegt uit zichzelf en onder druk van regelgeving naar open formaten, functies en contractvoorwaarden die een exit vergemakkelijken. Wat ontbreekt zijn schaal, operationele volwassenheid en een scherpe keuze welke diensten je wel en niet aanbiedt. Daarnaast blijft de stapeling gelden. Hoe soeverein een dienst ook is gebouwd, hij draait op de lagen uit deel 2 tot en met 5, en voor veel diensten is dit door de hyperscalers zelf of door partijen die hun diensten daar bovenop gebouwd hebben.

In this part, we move up another layer, to the core services. This is the first layer the customer actually sees. Everything below it is invisible, provided it works. From this point onwards, you are actually interacting with the cloud. Compute, containers, storage, networking, identity and key management: the things virtually every application relies on, however simple or complex it may be.

And because this layer is also fundamentally software, the instinct is once again: “We can build this ourselves.” That is partly true. But just as with the previous layer, the complexity is not primarily in building the software. It is in the operational discipline surrounding it.

So once again, we look at the same two questions: what do you need to build it, and what do you need to operate it?

What are core services?

Core services are the services required by virtually all PaaS and SaaS services and customer applications. We are talking about virtual machines, containers, storage, networking, identity, encryption and key management.

That sounds like a fairly limited set and therefore relatively straightforward. What makes it complex is that a service is more than just a capability. Starting a virtual machine is a capability, and anyone with a hypervisor can arrange that. A full-fledged compute service is the promise that, months or years from now, you will still be able to start thousands of them per minute across multiple regions, while the underlying hardware generations are being replaced without the customer noticing.

Storage is the clearest example. From the outside, object storage looks like a bucket into which you throw files. On the inside, it is a distributed system that breaks every object into pieces and spreads them across racks and zones using erasure coding, continuously performs background checks for bit rot, replaces failed disks without anyone having to intervene, and simultaneously supports three or more consistency models.

Hyperscalers offer an absurdly high durability SLA for this. That SLA is not marketing. It is an engineering objective backed by years of engineering work and enormous amounts of operational data. It is also exactly the sort of property you cannot reproduce simply by copying the source code, because it is the operational processes that make the SLA possible.

Networking is the same story in a different form. Software-defined networking means that every customer has their own address space, their own routing and their own firewall rules, while tens of thousands of customers simultaneously share the same physical cables without ever seeing one another’s traffic.

Identity: the real perimeter

If the control plane represents power, as I argued in Part 4, then identity is the key to that power. Identity is the one core service where an outage or compromise immediately affects everything: without identity, you cannot log in, you cannot authorise, and therefore you cannot do anything.

That makes identity the service with the sharpest sovereignty question in this entire layer. Not “where is my data?” but “who decides who I am?” An organisation that has carefully placed its data under its own control but does not control its identity provider still has a sovereignty risk. Conversely, setting up your own identity service is technically quite feasible. Keycloak and similar technologies are mature. But keeping that service running 24×7, at a level where the rest of your organisation can depend on it, is an entirely different discipline.

Identity is the service where doing it yourself is most attractive from a sovereignty perspective and where the consequences are worst if you underestimate it. Because once your identity service is compromised, you are anything but sovereign.

Within the framework, this primarily relates to SOV-2 and SOV-3: who can lawfully compel access, and who can close the door. And unlike at the hardware layer, this is a question you can actually address architecturally: federation, your own identity provider, multiple trust anchors. This is one of the few places where a sovereignty requirement translates into a concrete and actionable design choice rather than a checkbox in a procurement exercise.

Keys: where sovereignty becomes mathematics

Key management is the core service where the sovereignty debate comes closest to a real answer, and at the same time where things most frequently go wrong.

The reasoning from Parts 3 and 4 applies here without qualification: you do not have to trust the supplier if mathematics takes over. If the encryption key for your data resides in an HSM that you control, the question “can a foreign government access my data?” is no longer primarily a legal question but a technical one. Without the key, the data is noise, regardless of how lawful the request may be.

There is some good news for Europe here: Europe is well positioned when it comes to HSMs. Thales in France and Utimaco in Germany are genuine players in a market where the rest of the technology chain is overwhelmingly non-European. This is one of the few places on the map from Part 3 where Europe is not merely a spectator but an active participant.

But as always, there is a catch. Keeping keys entirely outside the cloud sounds like maximum sovereignty, but it has two serious disadvantages.

First, many services need the key simply to function. A search service cannot search data if that data remains encrypted. The same is true for indexing, analytics, backups and, increasingly importantly, AI. For data to be useful, it must be possible to decrypt it in the cloud, which means the cloud must have access to the key store. Confidential Computing can play a role here, but it is not yet at the point where we can easily apply it to everything.

Second, your own key-management environment becomes the single point of failure.If you lose your keys, you lose your data. That is not a theoretical risk but one of the most common ways organisations permanently lose access to data. Managing key management entirely yourself can therefore be exactly the right decision, but it should be a conscious risk trade-off rather than a reflex.

Kubernetes

Although Kubernetes is, strictly speaking, not a core service because it runs on top of the other core services, it still deserves a place here. Containers, and therefore container orchestration, play an increasingly important role as a core service because more and more applications are being modernised to run in containers. Cloud providers themselves are also running more and more of their PaaS and SaaS services in containers.

From a sovereignty perspective, Kubernetes is simultaneously the best and the most misleading argument in this entire layer.

It is the best because it is one of the few genuinely open standards the industry has. The API is the same at every provider and in your own data centre. This is not a de facto standard like S3, but an actual jointly governed project under a neutral foundation, with conformance tests that determine whether a particular distribution really behaves like Kubernetes. If you build your applications on it, you have an exit route that does not depend on your supplier’s goodwill. That is SOV-3 in practice rather than on paper.

And it is immediately also the most misleading argument, because “it runs on Kubernetes, so it is portable” is rarely entirely true. As soon as your cluster uses your provider’s load balancer, storage classes, identity integration, secrets store and monitoring, there is still a series of provider-specific hooks beneath that neutral API. The application may move perfectly well. The surrounding platform does not automatically move with it. Portability is not a property you receive. It is a property you test. If you have never tried to rebuild your cluster somewhere else, you simply do not know whether you can leave. CNCF projects such as Radius and Dapr are intended to reduce these dependencies further and make applications genuinely portable, but they are still used relatively little.

Quantum-safe: the renovation you need to organise now

And then there is something that receives remarkably little attention in the sovereignty debate, even though it affects the foundation underlying all of the arguments above. All those “you trust the mathematics” arguments from Part 3, Part 4 and this post rely on asymmetric cryptography that can be broken by a sufficiently large quantum computer.

This affects RSA and elliptic-curve cryptography, which underpin TLS, code signing, attestation, the hardware root of trust, and virtually every key exchange throughout the stack. Nobody knows when such a quantum computer will exist. Nevertheless, the fact that this is a risk you need to start managing now is not speculation, for two reasons that are independent of any prediction.

The first is harvest now, decrypt later. Encrypted traffic intercepted and stored today could be decrypted in the future. For the vast majority of data, this will not matter. But for state secrets, medical records, judicial information and anything else that must remain confidential for decades, the attack is effectively already under way. And that is precisely the category of information the SEAL-4 discussion is about. If you require SEAL-4 because of long-term confidentiality but do not have a quantum-safe migration plan, you are defending the front door against a legal risk while leaving the back door cryptographically open.

The second reason is the duration of the migration itself. Cryptography does not live in one place. It is everywhere: in protocols, firmware, long-lived certificates, HSMs, chips that remain in service for ten years, and applications nobody dares touch anymore. You do not replace that in a patch cycle. The standards now exist, including ML-KEM, ML-DSA and SLH-DSA, so the discussion is no longer primarily about which mathematics to use. It is about inventory and sequencing. The EU recommendation and associated roadmap also attach concrete dates to this process, prioritising the most critical use cases.

In practical terms, this means three things, in this order. First, know where your cryptography is. Most organisations do not have a complete picture, and creating that picture is the real work. Second, make your systems crypto-agile, meaning that an algorithm can be replaced without having to break open the application. That is an architectural principle, not a product. Third, deploy hybrid approaches in which classical and post-quantum key exchange operate alongside one another, so that you lose nothing if either approach proves problematic.

For this layer, the implications are concrete. Your key-management service must support post-quantum algorithms, your HSMs must be capable of handling them, and your certificate chain must be replaceable.

The fact that European HSM vendors have a role to play here is more than a nice bonus. It is one of the few places where “European” and “future-proof” coincide without requiring a compromise.

And then the sober caveat, because that belongs here too. Hyperscalers have been working on this for years and are rolling out post-quantum key exchange across their fleets largely without customers noticing. That is another example of the advantage of scale. A migration that represents a multi-year programme for an individual organisation becomes, for a hyperscaler, a rollout through a pipeline like the one described in Part 4. A small sovereign cloud must perform that same renovation itself, with its own people, for a fraction of the number of customers. That is exactly the kind of hidden cost that is often overlooked.

The supply chain when building it

Good news and bad news.

The good news is that the building blocks are sitting in plain sight. OpenStack, Kubernetes, Ceph, Keycloak, and a mature ecosystem of open cryptography in which post-quantum algorithms are now simply part of the landscape. A European organisation seeking to build core services does not need to solve any fundamental problem from scratch. As with OCP in Part 3, the designs are available. And as with OCP, that is only half the story.

The bad news is that the difference between open-source software and a service is exactly the part you cannot download. Quota management, capacity planning, throttling that remains fair under pressure, predictable degradation behaviour when a zone fails, billing that is accurate to the second, and a failure model customers can understand. These are the things that have been refined over years using operational data you only acquire when running at scale. You do not simply build a core service. You grind and polish it into your organisation.

Kubernetes is immediately the clearest illustration. The software is free and belongs to everyone. But wrapping a managed service around it means guaranteeing, across thousands of clusters simultaneously, that an upgrade does not bring them down, that a failed node is replaced within minutes, and that a vulnerability in the container runtime is patched everywhere within days. That is not a product you build. It is an operation you create.

Anyone starting from scratch today does have one advantage that established providers do not: you can design crypto-agility into the environment from day one instead of having to retrofit it through twenty years of legacy. That is one of the few genuine greenfield advantages at this layer, and it should rank highly on the requirements list of anyone considering such a build.

The supply chain underneath it remains. Every VM and every node you provide runs on the hardware from Part 3. Every sovereign core service is therefore a European software layer on top of a non-European foundation. That does not make the software layer worthless, but SOV-5 cannot be fixed here.

The supply chain when operating it

This is where the real bill arrives, and it is the same one we encountered in Part 4: not the build, but the operation.

Customers do not use cloud solely for its functionality. They also use it for reliability. That is not only about ensuring that operations prevent frequent service interruptions. It is also about the stability of the way customers consume services. An important consideration is how long services remain available and how long their interfaces remain unchanged. For core services, this matters even more than for more experimental services or services in fields where development moves at an extraordinary pace, as AI currently does.

Kubernetes introduces a complication that the other services do not have: you do not control your own release calendar. The upstream project sets the pace, and you have to follow. That is the price of an open standard, and it is a price you can only afford if you have a team that participates structurally in the project rather than simply consuming its output. The fact that AI is now finding vulnerabilities in existing software with increasing regularity and speed makes this even more complex, because you may encounter zero-day vulnerabilities more frequently.

In addition, this layer carries the certification burden described in Part 4 outwards. ISO 27001, SOC, PCI-DSS and the rest apply per service, not per company. Every new core service has to go through that process and must then be reassessed periodically. That is not a side issue. It is a substantial recurring cost that requires scale to remain affordable.

And then there is portability, which in my view is the most underestimated sovereignty instrument in this entire layer. A demonstrable exit within a reasonable period does more for genuine sovereignty than most origin requirements. It turns “who can switch off my services?” from a question driven by fear into one with an answer. Fortunately, tested exit strategies are increasingly becoming part of procurement requirements, and in my view this is a more important question than origin. Because in a war scenario, you might actually want to move applications to another continent. There are several initiatives aimed at creating standards for core services, but with the exception of Kubernetes, these are not yet ready, let alone generally accepted.

What does this mean for SEAL-4?

This is the first layer in this series where SEAL-4 is not inherently unattainable. Software can be written in Europe. We know how to manage cryptography. Europe has genuine home-grown players in HSMs. And with Kubernetes, there is an open standard that no individual supplier owns. Anyone setting a SEAL-4 ambition at this layer is not asking for the impossible. Much of the challenge lies in the supply chain underneath it, because that supply chain remains largely non-European. As a result, SOV-5 cannot be fully checked off here. The other challenge is not in the design but in operations, scale and pace. And those are precisely the things that require serious investment and years of work rather than a decision.

Which brings us back to the same advice as in the previous parts: do not use the framework dogmatically. Look at where a particular SEAL level is genuinely necessary. On one side, that means determining which applications require which level. On the other, it means looking at which parts of an application, including adjacent functions such as security services, actually require that level. An application may need to run in an environment with a high SEAL level while still being perfectly capable of using replaceable surrounding services, such as DDoS protection, with a different sovereignty profile.

In the next part, we will move up another layer, to the higher-level services: databases, messaging, analytics and AI. That is the layer where customers derive their real advantage from the cloud, but also where lock-in truly begins.

In dit deel klimmen we weer een laag omhoog, naar de kerndiensten. Dit is de eerste laag die de klant daadwerkelijk ziet. Alles daaronder is onzichtbaar mits het werkt; vanaf hier praat je met de cloud. Compute, containers, opslag, netwerk, identiteit en sleutelbeheer: de dingen waar vrijwel elke applicatie op leunt, hoe simpel of hoe complex die ook is.

En omdat het ook hier om software gaat, is de reflex opnieuw: “dít kunnen we zelf.” Dat is deels waar, maar net als in de vorige laag zit de complexititeit niet in het bouwen van de software, maar om de operationele discipline er omheen. Daarom kijken we wederom naar dezelfde twee vragen: wat heb je nodig voor de bouw, en wat heb je nodig voor de operatie?

Wat zijn kerndiensten?

Kerndiensten zijn die diensten die nodig zijn vrijwel voor alle PaaS en SaaS diensten en klantapplicaties. We hebben het dan over virtuele machines, containers, opslag, network, identiteit, encryptie en sleutelbeheer. Dat klinkt beperkt en daarmee relatief eenvoudig. Wat dit complex maakt is dat een dienst meer is dan alleen dan de capability. Een virtuele machine starten is een capability en dat kan iedereen met een hypervisor wel organiseren. Een volwaardige compute-dienst is de toezegging dat je er over een aantal maanden of jaren nog duizenden per minuut kunt starten, in meerdere regio’s, en dat terwijl de onderliggende hardwaregeneraties vervangen worden zonder dat de klant het merkt.

Opslag is het duidelijkste voorbeeld. Objectopslag lijkt aan de buitenkant een emmer waar je bestanden in gooit. Aan de binnenkant is het een gedistribueerd systeem dat elk object opknipt en met erasure coding over racks en zones verspreidt, continu achtergrondcontroles doet op bitrot, kapotte schijven vervangt zonder dat er iemand naar kijkt, en dat tegelijk drie of meer consistentiemodellen moet bedienen. Hyperscalers geven hier een absurd hoge duurzaamheids SLA op. Die SLA is geen marketing, het is een ontwerpdoel waar jaren engineering en heel veel operationele data achter zit. Het is ook precies het soort eigenschap dat je niet kunt kopiëren door de broncode over te nemen, want het zijn de operationele processen die de SLA mogelijk maken.

Netwerk is hetzelfde verhaal in een ander jasje. Software-defined networking betekent dat elke klant zijn eigen adresruimte heeft, zijn eigen routering, zijn eigen firewallregels, en dat die van tienduizenden klanten tegelijk op dezelfde fysieke kabels liggen zonder ooit in elkaars verkeer te kijken.

Identiteit: de echte perimeter

Als het control plane de macht is, zoals ik in deel 4 betoogde, dan is identiteit de sleutel tot die macht. Identity is de enige kerndienst waar een storing of een compromittering meteen alles raakt: zonder identiteit kun je niet inloggen, niet autoriseren, en dus niets.

Dat maakt identiteit de dienst met de scherpste soevereiniteitsvraag van deze hele laag. Niet “waar staat mijn data”, maar “wie bepaalt wie ik ben”. Een organisatie die haar data netjes onder eigen controle heeft maar haar identiteitsprovider niet, heeft alsnog een soevereiniteitsrisico. Omgekeerd is een eigen identiteitsdienst optuigen technisch goed te doen (Keycloak en verwanten zijn volwassen), maar deze 24×7 overeind houden op het niveau waarop de rest van je organisatie ervan afhankelijk is, is een compleet andere discipline. Identity is de dienst waar zelf doen het aantrekkelijkst is vanuit een soevereiniteitsgedachte en het slechtst uitpakt als je het onderschat. Want wordt de identiteitsdienst gecompromiteerd, dan ben je alles behalve soeverein.

Voor het framework zit dit vooral bij SOV‑2 en SOV‑3: wie kan rechtmatig toegang afdwingen, en wie kan de deur dichtgooien. En anders dan bij de hardwarelaag is dit een vraag waar je architectonisch iets aan kunt doen: federatie, eigen identity provider, meerdere vertrouwensankers. Dit is een van de weinige plekken waar een soevereiniteitseis zich vertaalt in een concrete, uitvoerbare ontwerpkeuze in plaats van in een vinkje in een aanbesteding.

Sleutels: waar soevereiniteit wiskunde wordt

Sleutelbeheer is de kerndienst waar het soevereiniteitsdebat het dichtst bij een echt antwoord komt, en waar het tegelijk het vaakst misgaat. De redenering uit deel 3 en 4 geldt hier onverkort: je hoeft de leverancier niet te vertrouwen als de wiskunde het overneemt. Als de versleutelingssleutel van jouw data in een HSM zit die jij beheert, is de vraag “kan een buitenlandse overheid bij mijn data” niet langer juridisch maar technisch. Zonder sleutel is de data ruis, hoe rechtmatig het verzoek ook is.

Hier zit bovendien het vrolijkste nieuws voor Europa: in HSM’s staat Europa er goed voor. Thales (Frans) en Utimaco (Duits) zijn echte spelers in een markt waar de rest van de keten overweldigend niet-Europees is. Dit is een van de weinige plaatsen op de kaart uit deel 3 waar Europa geen toeschouwer is maar meespeelt.

En dan de nuance, want die is er altijd. Sleutels volledig buiten de cloud houden klinkt als maximale soevereiniteit, maar er zitten twee serieuze nadelen aan. Ten eerste hebben een heleboel diensten de sleutel nodig om überhaupt te kunnen functioneren. Een zoekfunctie kan niets zoeken als de data die het doorzoekt versleuteld is. Hetzelfde geldt voor indexeren, analyseren, backups maken, en tegenwoordig heel belangrijk AI. Om bruikbaar te zijn moet data in de cloud ontsleuteld kunnen worden en moet de cloud dus toegang hebben tot de sleutelopslag. Confidential Computing kan hier een rol spelen, maar is nog niet zover dat we dit eenvoudig voor alles kunnen gebruiken. Ten tweede wordt de eigen sleutelbeheer omgeving de enige single point of failure. Wie zijn sleutels kwijtraakt, raakt zijn data kwijt, en dat is geen theoretisch risico maar een van de meest voorkomende manieren waarop organisaties permanent data verliezen. Sleutelbeheer geheel zelf doen kan precies de juiste keuze zijn, maar dan wel als bewuste risicoafweging en niet als reflex.

Kubernetes

Hoewel Kubernetes strikt genomen geen kerndienst is, het draait immers boven de andere kerndiensten, verdient het hier toch een plekje. Containers en daarmee containerorchestratie speelt een steeds belangrijkere rol als kerndienst, omdat steeds meer applicaties gemoderniseerd worden naar containers. Ook cloud provider zelf draaien steeds meer van hun PaaS en SaaS diensten containers.

Voor soevereiniteit is Kubernetes tegelijk het beste en het meest misleidende argument van deze hele laag. Het beste, omdat het een van de weinige echte open standaarden is die de industrie heeft: de API is dezelfde bij elke provider en bij jezelf op kantoor. Dat is geen de‑facto standaard zoals S3, maar een daadwerkelijk gezamenlijk beheerd project onder een neutrale stichting, met conformance-tests die meten of een specifieke distributie zich ook echt als Kubernetes gedraagt. Wie zijn applicaties hierop bouwt, heeft een uitgang die niet van de goede wil van zijn leverancier afhangt. Dat is SOV‑3 in de praktijk in plaats van op papier.

En meteen het meest misleidende, want “het draait op Kubernetes, dus het is portabel” is zelden helemaal waar. Zodra je cluster gebruikmaakt van de load balancer, de opslagklassen, de identiteitskoppeling, de secrets-store en de monitoring van je provider, hangt er onder die neutrale API alsnog een serie leverancierspecifieke haken. De applicatie verhuist prima; het platform eromheen verhuist niet vanzelf mee. Portabiliteit is geen eigenschap die je krijgt, het is er een die je test. Wie nooit geprobeerd heeft zijn cluster ergens anders op te bouwen, weet simpelweg niet of hij kan vertrekken. CNCF projecten als Radius en Dapr zijn gericht op deze afhankelijkheid nog verder te beperken en applicaties echt portabel te maken, maar die worden nog weinig gebruikt.

Quantum-safe: de verbouwing die je nu moet organiseren

En dan is er iets wat in het hele soevereiniteitsdebat opvallend weinig aandacht krijgt, terwijl het de fundering onder alle bovenstaande redeneringen raakt. Al die “je vertrouwt de wiskunde”-argumenten uit deel 3, deel 4 en deze post leunen op asymmetrische cryptografie die door een voldoende grote quantumcomputer gebroken wordt. Dit raakt RSA en elliptische krommen die de basis vormen van TLS, code-signing, attestatie, en de hardware root of trust, van vrijwel elke sleuteluitwisseling in de stack.

Wanneer die quantum machine er staat, weet niemand. Dat het een risico is dat je nu moet organiseren, is desondanks geen speculatie, en wel om twee redenen die los staan van elke voorspelling.

De eerste is harvest now, decrypt later. Versleuteld verkeer dat vandaag wordt afgetapt en opgeslagen, kan in de toekomst alsnog ontsleuteld worden. Voor het overgrote deel van de data maakt dat niets uit, maar voor staatsgeheimen, medische dossiers, justitiële informatie en alles wat decennialang vertrouwelijk moet blijven, is de aanval feitelijk al aan de gang. Dit is precies de categorie waar het SEAL‑4-gesprek over gaat. Wie SEAL‑4 eist vanwege langdurige vertrouwelijkheid en ondertussen geen quantum-safe migratieplan heeft, verdedigt de voordeur tegen een juridisch risico terwijl de achterdeur cryptografisch openstaat.

De tweede reden is de looptijd van de verbouwing zelf. Cryptografie zit niet op één plek; het zit overal. In protocollen, in firmware, in certificaten met lange geldigheidsduur, in HSM’s, in chips die er tien jaar staan, in applicaties die niemand meer durft aan te raken. Je vervangt dat niet met een patchronde. De standaarden zijn er inmiddels wel (o.a. ML‑KEM, ML‑DSA en SLH‑DSA) dus de discussie gaat niet meer over welke wiskunde, maar over de inventarisatie en de volgorde. De EU-aanbeveling en de bijbehorende routekaart zetten daar ook concrete jaartallen op, met de zwaarste use cases voorop.

Praktisch betekent dat drie dingen, in deze volgorde. Weten wáár je cryptografie zit, want de meeste organisaties hebben geen volledig beeld en dat is het echte werk. Zorgen dat je systemen crypto-agile zijn, dus dat een algoritme vervangen kan worden zonder de applicatie open te breken. Dat is een architectuurprincipe, geen product. En hybride uitrollen, waarbij klassieke en post-quantum sleuteluitwisseling naast elkaar draaien, zodat je niets verliest als een van beide tegenvalt.

Voor deze laag is dat concreet. Je sleutelbeheerdienst moet post-quantum algoritmen ondersteunen, je HSM’s moeten ze aankunnen, en je certificaatketen moet vervangbaar zijn. Dat het Europese HSM-aanbod hier meespeelt, is meer dan een leuke bijkomstigheid: het is een van de weinige plekken waar “Europees” en “toekomstbestendig” samenvallen zonder dat je iets inlevert.

En dan de nuchtere kanttekening, want die hoort erbij. Hyperscalers zijn hier al jaren mee bezig en rollen post-quantum sleuteluitwisseling grotendeels ongemerkt uit over hun hele vloot. Dat is opnieuw schaalvoordeel: een migratie die voor een individuele organisatie een meerjarig programma is, is voor hen een uitrol over een pijplijn zoals beschreven in deel 4. Een kleine soevereine cloud moet diezelfde verbouwing zelf doen, met eigen mensen, voor een fractie van het aantal klanten. Dat is precies het soort verborgen kostenpost wat vaak over het hoofd wordt gezien.

De toeleveringsketen bij het bouwen

Goed nieuws en slecht nieuws.

Het goede nieuws: de bouwstenen liggen open op tafel. OpenStack, Kubernetes, Ceph, Keycloak, een volwassen ecosysteem van open cryptografie waarin de post-quantum algoritmen inmiddels gewoon meekomen. Een Europese partij die kerndiensten wil bouwen, hoeft geen enkel fundamenteel probleem opnieuw op te lossen. Net als bij OCP in deel 3 zijn de ontwerpen er; en net als bij OCP is dat maar de helft van het verhaal.

Het slechte nieuws is dat het verschil tussen open source en een dienst precies datgene is wat je niet kunt downloaden. Quotabeheer, capaciteitsplanning, throttling die eerlijk is onder druk, degradatiegedrag dat voorspelbaar is als een zone wegvalt, facturering die tot op de seconde klopt, en een foutmodel dat klanten begrijpen. Dat zijn de dingen waar jarenlang aan geschaafd is met data die je alleen krijgt als je op schaal draait. Je bouwt geen kerndienst, die slijp je in je organisatie.

Kubernetes is daar meteen de scherpste illustratie van. De software is gratis en van iedereen, maar een beheerde dienst eromheen betekent dat je voor duizenden klusters tegelijk garandeert dat een upgrade niet omvalt, dat een kapotte node binnen minuten vervangen is, en dat een beveiligingslek in de container-runtime binnen dagen overal gedicht is. Dat is geen product dat je bouwt, dat is een operatie die je opzet.

Wie vandaag begint te bouwen heeft overigens één voordeel dat de gevestigde partijen niet hebben: je kunt crypto-agility er vanaf dag één in ontwerpen in plaats van er twintig jaar aan legacy doorheen te moeten trekken. Dat is een van de weinige echte greenfield-voordelen op deze laag, en het zou hoog op de eisenlijst moeten staan van iedereen die zo’n bouw overweegt.

En de keten eronder blijft staan. Elke VM en elke node die je uitdeelt, draait op de hardware uit deel 3. Elke soevereine kerndienst is een Europese software‑laag op een niet‑Europees fundament. Dat maakt de software‑laag niet waardeloos maar SOV‑5 laat zich hier niet repareren.

De toeleveringsketen bij het exploiteren

Hier zit de echte rekening, en het is dezelfde als in deel 4: niet de bouw maar de operatie.

Klanten gebruiken de cloud niet alleen voor de functionaliteit, maar ook voor de betrouwbaarheid. Dat gaat niet alleen over dat de operatie ervoor zorgt dat er zelden onderbrekingen zijn in de dienstverlening, maar ook over de stabiliteit van hoe klanten diensten afnemen. Belangrijk daarbij is van belang hoelang diensten beschikbaar blijven en interfaces daarvan onveranderd blijven. Voor kerndiensten speelt dit nog meer dan voor meer experimentele diensten of diensten gericht op een veld waar de ontwikkelingen zich in een enorm tempo opvolgen (zoals momenteel AI).

Voor Kubernetes komt er een bijzonderheid bij die de andere diensten niet hebben: je bent niet de baas over je eigen releasekalender. Het upstream-project bepaalt het tempo, en jij mag volgen. Dat is de prijs van een open standaard, en het is een prijs die je alleen kunt betalen met een team dat structureel meedraait in dat project in plaats van er alleen uit consumeert. Doordat AI nu met grote regelmaat en snelheid gaten vindt in bestaande software maakt dit nog complexer, omdat je vaker met een zero-day lek geconfronteerd kan worden.

Daarnaast draagt deze laag de certificeringslast uit deel 4 door naar buiten. ISO 27001, SOC, PCI‑DSS en de rest gelden per dienst, niet per bedrijf. Elke nieuwe kerndienst moet die molen door en daarna periodiek opnieuw. Dat is geen bijkomstigheid maar een vaste, aanzienlijke kostenpost die schaal nodig heeft om betaalbaar te blijven.

En dan is er portabiliteit, in mijn ogen het meest onderschatte soevereiniteitsinstrument van deze hele laag. Een aantoonbare exit binnen redelijke tijd doet voor werkelijke soevereiniteit meer dan de meeste herkomstvereisten: het maakt van “wie kan mijn diensten uitzetten” een vraag met een antwoord in plaats van een angst. Gelukkig wordt een geteste exit steeds vaker een onderdeel van aanbestedingen en dit is mijns inziens een belangrijker vraag dan die van herkomst. Want in een oorlogsscenario zou je applicaties misschien wel willen verplaatsen naar een ander continent. Er zijn een aantal initiatieven om een standaard te maken voor kerndiensten, maar behoudens Kubernetes zijn deze nog niet klaar, laat staan algemeen geaccepteerd.

Wat betekent dit voor SEAL‑4?

Dit is de eerste laag in deze serie waar SEAL‑4 niet bij voorbaat onhaalbaar is. Software kun je in Europa schrijven, cryptografie beheersen we, in HSM’s hebben we echte thuisspelers, en met Kubernetes ligt er een open standaard waar geen enkele leverancier eigenaar van is. Wie hier een SEAL‑4‑ambitie neerlegt, vraagt niet het onmogelijke. De keten eronder is waar een groot deel van de uitdaging ligt, want die is grotendeels niet‑Europees en dus is SOV‑5 hier niet volledig af te vinken. De andere uitdaging zit niet in het ontwerp maar in de operatie, de schaal en het tempo, en dat zijn precies de dingen die serieuze investeringen en jaren van arbeid kosten in plaats van een besluit.

En dat brengt ons weer bij hetzelfde advies uit de vorige delen: gebruik het framework niet dogmatisch. Kijk waar een bepaald SEAL niveau echt nodig is, hetgeen aan de ene kant gaat over welke applicaties welk niveau nodig hebben en aan de andere kant over welke delen van de applicatie (inclusief aanpalende functies zoals beveiligingsdiensten) welk niveau nodig hebben. Een applicatie kan vereisen om in omgeving met een hoog SEAL niveau te draaien, maar die kan vaak best gebruik maken van (vervangbare) diensten er omheen zoals een DDoS beveiliging.

In het volgende deel klimmen we opnieuw een laag omhoog, naar de diensten op hoger niveau: databases, messaging, analytics en AI. Dat is de laag waar klanten hun daadwerkelijke voordeel halen, maar ook waar lock‑in echt begint.

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.

We beginnen onderaan, bij de laag die in het soevereiniteitsdebat meestal alleen gesproken wordt over eigenaarschap: het datacenter. Gebouwen, stroom, koeling en glasvezel. Geen software, geen chips, maar beton, koper en water. Dit is de laag waar Europese soevereiniteit het best haalbaar is. Er zijn echter wel fysieke en financiële obstakels zijn. Het voordeel van een datacenter an sich is dat deze genationaliseerd kan worden en daarmee onttrokken kan worden aan eventuele overheidsinmenging vanuit het buitenland. Zoals de casus met Nexperia in 2025 laat zien is dit wel diplomatiek complex.

De anatomie van een hyperscale regio

Voor een hyperscale cloud is een datacenter wel een bouwblok, maar vanuit de organisatie denkt een hyperscale cloud niet in datacenters, maar in regio’s. Een regio is niet een enkel datacenter, maar een cluster van datacenters, doorgaans opgedeeld in drie zogenaamde availability zones. Elke zone is een op zichzelf staande verzameling datacenters met eigen stroom, eigen koeling en eigen netwerk. Een storing in de één mag de ander niet raken. De zones liggen ver genoeg uit elkaar om niet door dezelfde overstroming, brand of stroomstoring te worden geveld (meestal enkele kilometers tot maximaal zo’n 100 kilometer), maar dichtbij genoeg om via glasvezel met minder dan zo’n 2 milliseconden heen en weer te praten. Die 2 milliseconden zijn geen willekeurig getal: het is de grens waaronder je synchroon kunt repliceren, dus waaronder een database in zone 1 en zijn kopie in zone 2 zich als één systeem gedragen.

Waarom drie, en niet twee? Omdat je met drie een meerderheid, een quorum, kunt vormen. Valt één zone weg, dan houden de andere twee samen de waarheid vast en draait de dienst door. Twee zones geven je redundantie, maar geen meerderheid: bij een netwerksplitsing weet geen van beide of hij nog de baas is. Drie is het minimum voor een systeem dat zichzelf overeind houdt zonder menselijk ingrijpen. Dat is meteen de kern van waarom een hyperscale regio duurder is dan “een datacenter”: je bouwt de capaciteit feitelijk anderhalf tot drie keer.

Verbinding met andere regio’s

Eén regio, hoe robuust ook, is nog beperkt tot een bepaalde locatie. Om te beschermen tegen rampen die een hele regio kunnen raken, zoals een langdurige regionale stroomcrisis, een overstroming, of een menselijke fout die zich door de hele regio verspreidt, heb je meerdere regio’s nodig. Anders dan tussen zones is die verbinding niet synchroon: over honderden kilometers is de lichtsnelheid simpelweg te traag voor die 2 milliseconden, dus repliceer je asynchroon. Je accepteert dat de kopie in de andere regio(‘s) een fractie achterloopt, in ruil voor de zekerheid dat je data op meerdere plekken staat.

En hier raakt de fysieke laag ineens de soevereiniteit. Hyperscalers bieden mogelijkheden om te repliceren met andere regio’s binnen dezelfde jurisdictie. Voor data‑residency is dat precies wat je wilt: je uitwijk valt onder hetzelfde recht als je primaire regio. Op deze laag is “data blijft in de EU” dus geen belofte maar een architectuurkeuze die je op de kaart kunt aanwijzen. De verbindingen zelf, met name de  glasvezel‑backbone en de zeekabels liggen voor Europa in Europa en kunnen dus, als ze al niet van een Europese partij zijn, Europees gemaakt worden.

Soevereiniteit gaat echter ook over resilience, het beschikbaar houden van systemen onder extreme omstandigheden. Oekraïne heeft daarom juist veel van hun systemen buiten het land, en dus hun expliciete jurisdictie, geplaatst. Om Johan Cruijff aan te halen: “elk nadeel heb z’n voordeel”.

Beveiliging

Data is het nieuwe goud en dat is wel te zien aan de beveiliging van datacenters. Dat begint met fysieke beveiligingsmaatregelen die niet misstaan op een legerbasis, zoals hekwerk wat een vrachtwagen tegen kan houden, videobewaking en mensen. Een datacenter inkomen gaat ook niet zomaar en soms zijn verschillende delen van een datacenter ook nog gescheiden en vereisen doorgang door een toegangspoort die meerdere vormen van authenticatie vereisen. Ook wordt alle toegang gelogd en kan dus altijd nagegaan worden wie op welk moment binnen was. En ook het verlaten van het gebouw (of een deel daarvan) gaat via een poort of sluis, waardoor het ook niet mogelijk is om zomaar spullen mee te nemen. Binnenin een datacenter is er ook videobewaking en kunnen er nog andere beveiliging op de infrastructuur zitten (maar dat is iets voor het volgende deel). Er is derhalve zeer veel controle over wie waar in een datacenter kan komen, hetgeen zowel vanuit het oogpunt van beveiliging als soevereiniteit van belang is.

Energie: de echte bottleneck

Nu de rekening. Eén hyperscale datacenter trekt al gauw tientallen megawatt, genoeg om honderdduizenden huishoudens van stroom te voorzien. Een regio met drie zones en meerdere gebouwen per zone zit dus al snel op enkele honderden megawatts, en de nieuwste AI‑regio’s koersen richting een gigawatt of meer. Ter vergelijking: dat is de orde van grootte van een middelgrote elektriciteitscentrale, permanent, dag en nacht, voor één regio.

Voor Nederland is dit moment het grootste knelpunt. Ons hoogspanningsnet zit in grote delen van het land tegen of over zijn grens. De netcongestie waar TenneT al jaren voor waarschuwde is een feit. Nieuwe grootverbruikers staan in de wachtrij, en die wachtrij is geen weken maar jaren. In sommige markten loopt de aansluittermijn voor een grote afnemer op tot wel acht jaar. Je kunt de snelste chips ter wereld bestellen, maar zonder aansluiting op het net kan een datacenter niets. Energie is daarmee niet de duurste regel op de begroting, het is de regel die bepaalt of het project er überhaupt komt, en wanneer. Het verklaart ook waarom energie zo centraal staat in het Nederlandse beleid. Een hyperscaler concurreert om exact dezelfde schaarse duurzame energie als de energietransitie van huishoudens en industrie. Tegelijkertijd zijn het juist hyperscalers die de investeringen in (hernieuwbare) energie aanjagen en er zijn plaatsen waar ze een rol spelen bij het in balans houden van het stroomnet door stroom terug te leveren.

Wat hyperscalers doen om energie te besparen

De hyperscalers zijn zich pijnlijk bewust van die rekening, al is het maar omdat elektriciteit hun grootste operationele kostenpost is. Efficiëntie meet je met PUE (Power Usage Effectiveness): de verhouding tussen de totale stroom en de stroom die daadwerkelijk naar de servers gaat. Een gemiddeld bedrijfsdatacenter zit rond 1,5 à 2,0. De hyperscalers hebben in de laatste twee decennia allerlei ontwikkelingen gedaan om dit terug te brengen naar 1,1 tot 1,2. Dat verschil, de “overhead” die niet naar rekenen maar naar koelen en verliezen gaat, is precies waar de winst zit, en waar een kleine speler het aflegt tegen schaal. Kleine “soevereine” datacenters bouwen kan daarmee direct ingaan tegen het belang om energie te besparen.

Hyperscalers gebruiken allerlei methoden om energie te besparen, zoals koelen met buitenlucht (free cooling) wanneer het klimaat het toelaat (een reden waarom Nederland een interessante plaats is voor een datacenter), hardware die hogere temperaturen aan kan zodat er minder gekoeld hoeft te worden, en AI die de koeling realtime optimaliseert. Hier speelt schaal opnieuw in hun voordeel. Een verbetering van 0,01 op de PUE levert op de schaal van honderden megawatts enorm veel besparing op.

Water en koeling

Koeling is de tweelingzus van energie, en vereist vooral water. Klassieke datacenterkoeling verdampt water om warmte af te voeren. Dat is gunstig voor de stroomrekening, maar het verbruikt miljoenen liters per jaar per locatie, vaak gewoon drinkwater. Gezien er steeds meer waterkrapte is, is dit een steeds groter (maatschappelijk) probleem en daarom verschuift de industrie in rap tempo. Microsoft is bijvoorbeeld medio 2024 begonnen met het uitrollen van een gesloten koelsysteem op chipniveau dat verdampingswater volledig overbodig maakt. Het wordt één keer gevuld bij de bouw en circuleert daarna rond, wat miljoenen liters per locatie per jaar bespaart. Andere sporen zijn luchtkoeling, koelen met niet‑drinkbaar, regen- of gerecycled water.

En dan is er nog de restwarmte. Afgevoerde warmte hoeft niet zomaar de lucht in te verdwijnen. Zo kan restwarmte bijvoorbeeld gebruikt worden voor kassen of woningen verwarmen via aansluiting op een warmtenet. Voor dat laatste moet een datacenter dan wel dicht bij de stad staan, waar de ruimtelijke druk en daarmee de grondkosten het hoogst is. Ook hier moeten voor- en nadelen tegen elkaar afgewogen worden.

De toeleveringsketen van een datacenter

Terug naar de twee vragen uit de routekaart: hoe ziet de keten eruit bij het bouwen, en bij het exploiteren?

Bij het bouwen heb je een verrassend lange lijst zware, kritieke componenten nodig: transformatoren en middenspanningsschakelaars om het netvermogen om te zetten en te verdelen, noodstroomaggregaten (meestal diesel) voor als het net wegvalt, batterijen om de seconden te overbruggen tot die aggregaten draaien, en koelinstallaties, leidingwerk. En uiteraard ook gewoon beton, staal, koper en glasvezel.

En hier zit het lichtpuntje voor het soevereiniteitsverhaal. Anders dan bij chips of geavanceerde software is dit een keten die Europa grotendeels zelf beheerst. Transformatoren en schakelmateriaal komen van Europese spelers als Siemens Energy, Hitachi Energy, Schneider Electric en ABB. Noodstroomaggregaten komen van het voornamelijk Duitse MTU en ook koeltechniek komt van overwegend Europese partijen als STULZ, Munters en Schneider. Beton en staal zijn in principe lokaal. De grote uitzondering zijn de batterijen. De lithium‑ioncellen die nodig zijn komen overwegend uit Azië (CATL, LG, Samsung SDI, Panasonic). Er bestaan wat alternatieven en er is een opkomende Europese productie, maar dit blijft het zwakke Europese punt in een verder goed te dekken keten.

Die zal verder opgeschaald moeten worden, om leveringsproblemen te verminderen. Een onderzoek van AFCOM geeft aan dat 94% van de datacenteroperators tegen leveringsproblemen aanloopt, met aggregaten, transformatoren en schakelmateriaal als grootste knelpunten. Levertijden voor grote noodstroomaggregaten zijn opgelopen tot tussen de 72 en 104 weken. Hier valt dus veel te winnen.

Bij het exploiteren verschuift de afhankelijkheid van spullen naar stromen: elektriciteit, dieselbrandstof voor de aggregaten, water, reserveonderdelen en de monteurs die het draaiend houden. Geen van die stromen zijn een direct soevereiniteitsprobleem, hoewel delen van die keten (momenteel) buiten Europa (kunnen) vallen.

Vergunningen en de fysieke werkelijkheid

Naast de technische werkelijkheid, is er ook nog een proces dat doorlopen moet worden om de nodige vergunningen te krijgen. En daar zit ook nog een politieke component aan.

In februari 2022 nam de Nederlandse overheid een voorbereidingsbesluit dat de vestiging van hyperscale datacenters landelijk aan banden legde. De motivering was expliciet en verraadt precies het spanningsveld uit de energieparagraaf: hyperscale datacenters leggen “een onevenredig groot beslag op de beschikbare duurzame energie in verhouding tot de maatschappelijke en/of economische meerwaarde”. De rijksoverheid trok de regie naar zich toe en stelde toelatingscriteria bij de vergunningverlening. De bekendste casus, de geplande megavestiging bij Zeewolde, werd een nationale splijtzwam en liep vast. Geen technisch probleem, maar een maatschappelijk en bestuurlijk probleem.

Bovenop dat besluit stapelen zich de bekende Nederlandse dossiers: de stikstofcrisis die vrijwel elke grote bouwvergunning vertraagt, de netcongestie die een aansluiting jaren kan uitstellen, de ruimtelijke druk in een vol land, en de wateronttrekking die lokaal op verzet stuit. Elk van die dossiers kan een project op zichzelf stilleggen. Samen vormen ze een vergunningentraject dat langer duurt en onzekerder is dan het bestellen van welke lange‑levertijd‑component dan ook. Voor een daadwerkelijk Europese hyperscaler hoeft dit een veel kleiner probleem te zijn. Er zijn immers meer landen waar datacenters kunnen staan. Dan komen we echter weer uit op een van de eerdere onderdelen: de netwerkverbinding. Datacenters bouwen op plekken waar geen digitale snelweg ligt heeft weinig nut en tientallen kilometers aan kabel leggen, over meerdere routes vanwege redundantie, vergt ook vergunningen en mogelijk toestemming van landeigenaren. En dan moeten de kabels ook nog gelegd worden.

Moeten we datacenters dan zelf bouwen?

Terug naar de hoofdvraag: is een SEAL‑4‑datacenterlaag te bouwen? Op de soevereiniteits‑as luidt het antwoord positief. Het gebouw, de stroominfrastructuur, de koeling en de glasvezel kunnen grotendeels binnen de EU worden ontworpen, geleverd en geëxploiteerd. De enige echte niet‑EU‑afhankelijkheid van betekenis is de batterijcel, en zelfs die is geen showstopper.

Dat er niet heel veel soevereine hyperscale datacenters gebouwd worden heeft dus eigenlijk weinig te maken met de datacenterlaag an sich. Het is de wisselwerking met de andere lagen plus de politieke en financiële barrières. Niemand wil miljarden investeren als er geen voorspelbaar rendement uitkomt. De Amerikaanse hyperscalers daarentegen hebben het geld zelf en doordat ze alle lagen beheren is het rendement voorspelbaar. Dat neemt niet weg dat er allerlei partijen zijn die datacenters bouwen, onder andere om deze te verhuren aan hyperscalers. En als deze bedrijven niet Europees zijn, zouden ze in een crisis Europees gemaakt kunnen worden. Aangezien de datacenterprovider over het algemeen ook geen toegang heeft tot de servers zelf, is het ook minder van belang wie de eigenaar is van het gebouw.