In Part 1, I introduced the Cloud Sovereignty Framework and explored the question of whether SEAL-4 is needed at all, and for whom. In Part 2, I started at the bottom, with the data centres. In Part 3, I moved up to the infrastructure. In Part 4, I covered the platform: the control plane that turns data centres full of servers into a cloud.

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.