Digital sovereignty has rapidly moved in Europe from an abstract policy concept to a concrete board-level topic. This has little to do with buzzwords and everything to do with geopolitics: dependencies that felt stable for years now look less predictable. Commentators such as Kim Loohuis and Cristina Caffarra have helped sharpen the debate and push it toward uncomfortable but necessary choices. If key parts of your digital value chain sit outside Europe, what does autonomy really mean in practice?
It helps to de-romanticise the discussion. Digital sovereignty is not an ideological project, nor a one-off migration exercise. At its core, it is about business continuity: can you keep delivering when the rules of the game change?
Two undesirable scenarios: the key and the plug
If you strip the many interpretations of “digital sovereignty” down to what matters operationally, two risks dominate for most organisations.
The first is the key—meaning control over who can access (and decrypt) your data. If someone else can get to your keys, they can ultimately get to your data. Unwanted access can happen directly (misuse, supply-chain compromise, vulnerabilities), but also indirectly through legal or contractual pressure on service providers that operate under non-European jurisdictions. From a business perspective, the route often matters less than the outcome: loss of confidentiality and loss of control.
The second is the plug being pulled: a (temporary) suspension or termination of services, triggered by geopolitical escalation, sanctions, policy changes, export restrictions, or simply a commercial decision that hits your organisation at the wrong moment. Regardless of how likely you consider this scenario, the potential impact can be severe—so it belongs in any serious continuity plan.
Realism: fully decoupling from hyperscalers is rarely feasible
The instinctive response—“then we should leave the hyperscalers”—sounds decisive, but it is rarely realistic. Public cloud is deeply embedded in modern IT: collaboration and identity, data platforms, CI/CD, observability, and a fast-growing portfolio of security services. “Leaving” is not just a technical challenge; it involves people, processes, contracts, ecosystems, and time. In practice, many organisations either do nothing, or get stuck in an unachievable “everything must be sovereign” ambition.
A pragmatic approach therefore does not start with vendor selection, but with triage: what is truly critical for your organisation? Which processes must continue? Which data is crown-jewel data? Which capabilities are essential to operate safely?
Organisations that do this well typically end up with a split: a large proportion of workloads can remain in public cloud, provided they are designed correctly, while a smaller subset requires additional safeguards. Digital sovereignty becomes a differentiated strategy rather than a dogma.
You can mitigate the plug. You can design around the key.
The “plug” risk can be reduced, but rarely eliminated. Exit plans, portability, multi-region architectures, redundancy, contractual safeguards, alternative suppliers for critical control planes, and regular scenario exercises all help. They are sensible measures, but not a silver bullet.
The “key” risk is different. Here, you can make a fundamental architectural choice: take cryptographic control back. In other words, ensure confidentiality is not dependent on a cloud provider’s goodwill, policies, or legal exposure, but on your own keys, your own trust model, and your own governance.
That is where PKI comes in.
Managed PKI as a sovereignty lever
A (Managed) PKI solution enables you to operate your own trust anchor: certificates, key material, policies, lifecycle management, issuance, and revocation. The term “managed” is sometimes misunderstood as “outsourced and forgotten”. In a mature implementation, it means professional operations and continuity, while ownership and policy control remain with the organisation.
In practical terms, an own PKI allows you to:
- enforce end-to-end encryption and mutual TLS between applications and services;
- issue and rotate certificates under your own policy;
- bind cryptographic identity to workloads and devices (Zero Trust at scale);
- audit key usage and apply separation of duties.
The core principle is simple: whoever controls the key controls the data. If a provider can create, store, escrow, or release your keys (directly or indirectly), there will always be a scenario in which data can be decrypted without your explicit consent.
The most critical component: key custody and HSM—and it can be European
If you take cryptographic control seriously, you quickly arrive at key custody and Hardware Security Modules (HSMs). Not because it is fashionable, but because this is where the hard boundary sits: keys must be generated, stored, and used securely—ideally in a way that private keys never leave the protected environment.
This is an important and often underappreciated point in the European sovereignty debate: the most critical element of this approach can be anchored in Europe. A vendor such as Thales has long played a central role in HSM technology and key management. That enables organisations to build a trust layer that does not automatically inherit the legal or geopolitical exposure of non-European providers.
The strategic implication is significant: you can still benefit from public cloud for many use cases—scale, speed, innovation—while protecting confidentiality through an independent cryptographic layer. You shift the centre of gravity from trusting the provider to trusting your own keys and policies.
The metaphor: your house key
Imagine securing your home, but letting a third party both cut the keys and store them “for convenience”. Perhaps it works perfectly for years. But the moment pressure emerges—legal, commercial, or operational—you no longer have sole control over who can enter.
Digital sovereignty is similar. If you generate your keys yourself and keep them in your own “key cabinet” (your own PKI, your own key custody, your own HSM policy), ultimate access to your data remains yours. If you let another party manage your keys, you create a structural dependency that becomes extremely difficult to unwind later—especially under time pressure.
A pragmatic path forward
For most organisations, the most workable approach is not “cloud yes or cloud no”, but a set of design decisions grounded in criticality:
- Classify your processes and data: what is mission-critical, what is crown-jewel, what is replaceable?
- Define your crypto boundary: where must keys and trust definitively fall under your governance?
- Implement (Managed) PKI with strict lifecycle management: rotation, revocation, audit, and policy enforcement.
- Anchor key management in HSM with demonstrable separation of duties and robust logging.
- Operationalise it: incident response for key compromise, periodic testing, and repeatable design patterns for engineering teams.
This creates a situation where—even if you cannot fully decouple from hyperscalers—you can still build a sovereign core around the most sensitive component: cryptographic control.
Closing thought
Digital sovereignty in Europe is often discussed in terms of vendors, labels, and data location. For organisations, it is primarily a continuity question. The plug is complex and requires scenarios, mitigations, and realistic exit planning. The key is more tangible: you can take it back today by placing PKI, key custody, and HSM-backed controls under your governance.
The question we increasingly ask is therefore not: “Can you operate without hyperscalers?”
But: “Which doors in your digital house must you be able to lock yourself—regardless of what happens outside?”
Our team is ready for you
Do you want to know more about this topic? Leave a message or your number and we'll call you back. We are looking forward to helping you further.
