In Part 1, I described the Cloud Sovereignty Framework and the question of whether SEAL-4 is necessary at all, and for whom. In part 2 I started at the bottom, at the data centers. In part 3 I covered the infrastructure, where the chip supply chain made it painfully clear that Europe is still a spectator there. In this part, I will discuss the platform, the layer that automates and secures the infrastructure. This is the layer where the cloud distinguishes itself from regular hosting. The platform is what turns data centers with servers into a cloud: it distributes capacity, keeps track of what is running where, repairs malfunctions, keeps itself and customer environments safe, isolates customers from each other and determines who is allowed to do what. Because this layer consists of software, you can get started here without first building a factory for billions, which theoretically makes it easier to build this layer yourself. However, it is not the construction but the operation that makes this layer complex, because constant developments take place here.<\/p>\n\n\n\n
As promised, I ask the same two questions here as well: What does it take to build and what does it take to operate?<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
I want to avoid two wrong conclusions.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"