Who Has the Kill Switch to Your Infrastructure?

“We want to make sure no one has a kill switch.” Henna Virkkunen, Executive Vice President of the EU Commission for Technology Sovereignty, Security and Democracy, put it plainly. The meaning: no foreign government should be able to simply switch off or read out the infrastructure on which Europe runs. This is not a warning about a distant future.

It is a description of the present.

 

The Moment it Became Real

In 2025, the chief prosecutor of the International Criminal Court temporarily lost access to his Microsoft e-mail account in the context of US sanctions. A single external provider, a foreign legal jurisdiction, and an international institution was operationally impaired.

This is not an isolated case. The digital sovereignty barometer for public IT by Next:Public (December 2025, available in German only) shows that 65% of the administrations surveyed perceive a strong or very strong dependency on non-European IT providers. Amongst municipalities, this figure stands at 70%. Two thirds rate their switching options as inflexible or very inflexible. The kill switch exists. It simply out of their hands.

 

Europe is Drawing Consequences

The patterns that have emerged in recent months can no longer be deemed coincidental, they point to something more deliberate. Microsoft acknowledged  under oath before the French Senate that access to data by US authorities cannot be ruled out, even when that data is physically located in Europe. France has begun removing 2.5 million workplaces from US software. The European Parliament voted in favour accordingly, 471 to 68. And now the Commission is drafting the accompanying rules.

The Tech Sovereignty Package defines, for the first time, four levels of cloud sovereignty. At the highest levels, a provider must be controlled from within the EU, with full control over the supply chain and no access from third countries. Those who do not meet these requirements are to be excluded from the most sensitive public contracts: health data, financial data, judicial data.

 

What Digital Sovereignty Really Means

The BMDS describes digital sovereignty in public administration as “the capabilities and possibilities of individuals and institutions to exercise their role(s) in the digital world independently, self-determinedly and securely”. The aim is to safeguard the state’s capacity to act.

In practice, digital sovereignty tends to get reduced to a single question: where is the data stored? That’s an understandable starting point, but it doesn’t go far enough.

Data sovereignty is important. But storing data in Europe doesn’t automatically make a solution sovereign in any meaningful sense. If the administration, support, key management, operations, proprietary interfaces, or provider dependencies haven’t been carefully examined, significant vulnerabilities can remain – regardless of where the data physically sits.

Here’s an example: “Hosted in Europe” sounds convincing. But the location alone does not indicate who can legally or technically access the data and systems. Particularly with providers subject to non-European legal jurisdictions, it must be examined whether the public institution genuinely retains control over data, systems, metadata, keys, and operational processes.

 

Why Digital Sovereignty Cannot Be Achieved Through a Single Product

For many public institutions, the process starts with choosing a technology. That’s often exactly where things go wrong.

The more important question to ask first is: what are the actual requirements – for the institution itself, for the specific use case, and for the data involved?

For public institutions, the level of protection required is a central starting point. The BSI’s IT-Grundschutz methodology asks what damage can occur if the confidentiality, integrity, or availability of information, applications, or IT systems is compromised.

For this purpose, the BSI outlines three protection categories: normal, high, and very high.

• At the normal level, any damage that occurs is limited in scope and generally manageable.
• At the high level, the potential impact becomes considerably more serious.
• At the very high level, it can reach a scale that is existentially threatening or catastrophic.

The critical point is the level of protection determines the architecture, not the other way around.

Not every application needs to be locked down to the highest standard. At the same time, particularly sensitive communications, critical data, or core administrative functions must not be handled with an off-the-shelf approach.

Digital sovereignty, then, isn’t a single decision – it emerges from how architecture, integration, and implementation work together. Voice, video, messaging, unified communications (UC) platforms, networks, security, identity management, and existing systems all need to be considered as a whole. No individual tool can solve this on its own.

 

What Role Does Infrastructure Play?

On-premises infrastructure isn’t automatically more sovereign than every cloud solution. That said, it can be the decisive factor when particularly sensitive data, communication channels, or operational processes are involved.

For public institutions, local or dedicated infrastructure may be worth considering  when:

• Communication data and metadata must stay within defined environments
• Systems must remain available even if external connectivity is disrupted or limited
• Administration and operations need to be clearly separated
• There are specific requirements around classified information, availability, or auditability

The choice of operating model, then, needs to be a deliberate one. A genuinely sovereign architecture can draw on a combination of on-premises, hybrid, private cloud, and public cloud – there’s no single right answer.

What matters isn’t the label attached to a solution, but whether data flows, access rights, operational processes, interfaces, and exit options are all transparently and explicitly governed.

 

Why Are European Technologies and Open Source Important?

European technologies can help reduce legal and operational dependencies – but they’re not an end in themselves. A solution isn’t automatically sovereign simply because it comes from Europe.

What matters is whether the technology is genuinely fit for purpose, whether it can be securely integrated into existing environments, and whether it can be sustained and developed in the long term.

Open-source software is a central building block in this context- not for ideological reasons, but practical ones:

• Open-source code enables transparency and makes independent auditing possible.
• Open standards improve interoperability across systems.
• Modular approaches reduce reliance on any single vendor.
• Solutions become easier to adapt and reuse.
• Switching to an alternative remains a realistic option.

That said, open source is an important lever, not a ready-made sovereignty strategy. It only becomes meaningful when applications are securely integrated, properly documented, reliably operated, and genuinely embedded in existing workflows.

For public institutions, the question isn’t a binary choice between open source and proprietary solutions. What’s needed is an architecture that brings together transparency, interoperability, security, and the practical freedom to change providers when necessary.

 

Why Is Technology Alone Not Enough?

One point that often gets overlooked is deceptively simple: who is actually allowed access to these systems?

In security-sensitive projects, the conversation can’t stop at software, hardware, or cloud models. It also has to include  who is granted access – to systems, data, operational processes, and administrative functions.

Where a project’s requirements demand it, personnel who have been vetted under the Security Vetting Act (SÜG) can be deployed. In sensitive environments, this isn’t a footnote – it’s a core part of any serious implementation concept.

Technology, architecture, and people need to work  together. Without that alignment,  sovereignty stays exactly where it’s easiest to leave it: on paper.

 

How Should Public Institutions Approach Digital Sovereignty in Practice?

The first step is not a product decision, but a clear assessment of requirements.

In particular, public institutions should clarify:

1. Which data and communication processes are critical? Not every piece of information requires the same protection and operating model.
2. Which systems are already in place? Existing voice, collaboration, video, network, and security solutions must be considered.
3. What dependencies exist today? This includes providers, platforms, interfaces, data formats, support processes, and licensing models.
4. Which operating models are permissible and sensible? On-premises, hybrid, private cloud, public cloud, or air-gap architectures must be derived from the requirements.
5. Which technologies are genuinely suitable? Vendor neutrality is important here. Otherwise, the architecture is determined too early by a single product.
6. How can switching options and the capacity to act be preserved? Open standards, documented interfaces, and realistic migration scenarios must be part of the planning from the outset.

This approach avoids two common mistakes: treating sovereignty purely as a compliance topic or attempting to resolve it through the purchase of a single platform. In practice, both are needed: a clear assessment of requirements and the ability to build a viable communications and network infrastructure on that basis. This is precisely where Damovo comes in.

 

How Does Damovo Support the Implementation of Digital Sovereignty?

Damovo is a vendor-neutral consulting and integration partner for communication and network infrastructures in the public sector.

Our role is not to sell a single technology as “sovereign”. We assess requirements, recommend appropriate technologies, and integrate these into a secure, usable, and long-term governable overall architecture.

Specifically, we support public institutions with:

• the assessment of regulatory, organisational, and technical requirements
• the classification of protection requirements, communication needs, and operating models
• the selection of appropriate European technologies, open-source applications, and partner solutions
• the integration of voice, video, UC, messaging, network, and security
• the implementation of on-premises, hybrid, private cloud, and, where required, air-gap architectures
• the deployment of security-vetted staff under the SÜG where requirements so dictate
• the reduction of dependencies through open-source software and switching options.

The goal isn’t maximum isolation. It’s the ability to act.

 

Digital Sovereignty Is Not Optional Anymore

Digital sovereignty doesn’t come from a single product, a particular cloud location, or any one technology decision made in isolation.  It emerges when public institutions have a clear understanding of their own requirements, consciously work to reduce dependencies, and build their communications and network infrastructure in a way that remains secure, open, interoperable, and governable over the long term.

In the end, it’s not about individual building blocks. It’s about staying capable of action. Digital sovereignty is therefore not optional. It’s the foundation everything else rests on.