European digital sovereignty: why infrastructure jurisdiction matters

European digital sovereignty is no longer a positioning argument. It has become a criterion that is audited. For years, "sovereignty" was mostly an adjective: an infrastructure was presented as sovereign because its servers were on European soil, and nobody asked to see more. That is changing. The European Commission has begun to translate European digital sovereignty into verifiable requirements, and a public administration or regulated company procuring infrastructure can now, and in some cases must, ask for that inventory before signing.
This article does not set out the legal argument in the abstract. It goes straight to the technical inventory that separates a sovereign infrastructure from one that simply hosts its data in Europe: the jurisdiction of each node, where the encryption keys are held and who, in practice, has administrator access.
The four sovereignty levels the European Commission is already working with

The proposed Cloud and AI Development Act, published by the European Commission on 3 June 2026 as part of its technological sovereignty package, is the first attempt to turn "digital sovereignty" into a scale with progressively stricter levels, rather than a binary label:
At the first level, servers must be located within the Union, and third countries must not be able to exploit software vulnerabilities before they are disclosed. This is the starting condition, but on its own it does not demonstrate sovereignty: data may be physically in the EU and still be accessible to a provider subject to foreign jurisdiction.
The second level adds that no external provider may access the hosted data, and it removes the possibility of a remote "kill switch", meaning the ability of a third party to shut down the service from outside the Union.
The third level is where operator jurisdiction itself comes in: the entity operating the infrastructure may not be controlled by a parent company or legal entity from a third country, and origin and vetting criteria apply to staff with access. At this level, an infrastructure with a US parent company falls out of scope by design, regardless of where its data centres are located.
The fourth level requires that the technical components and products used are also free from third country control, with the most demanding European cybersecurity certification available (ENISA's EUCS scheme).
Operator jurisdiction: why it matters who controls the infrastructure, not just where it is
The factor that causes the most confusion is also the most decisive: if the entity operating the infrastructure has a parent company outside the Union, it is exposed to extraterritorial legislation. The reference case is the US CLOUD Act, which can require a company headquartered in the United States to hand over data stored on European servers, without the Member State where that data resides being able to prevent it. The physical location of the data and the jurisdiction of whoever controls it are two separate questions, and only the second one resolves this exposure.
This is precisely what distinguishes an infrastructure that is European by origin (legally, corporately and operationally, not merely national with a European outlook) from one that simply "also" has a presence in Europe. ISBE is a European infrastructure operated by Alastria: the question of which jurisdiction the operator answers to when faced with a request for access to data has a verifiable answer, not a statement of intent.
Key custody: who can decrypt the data, not just who stores it
The second element of the inventory is the custody of encryption keys. Encrypted data says nothing about sovereignty if the operator keeps the key and can decrypt it unilaterally, with or without a court order. The criterion now beginning to appear in contracts is that keys must be held by the customer or by a European entity, so that the infrastructure operator itself cannot access the content without explicit authorisation.
In a permissioned network with identified validators, this becomes a very specific and auditable question: in which HSM (hardware security module) does each key reside, under the control of which entity, and in which country? This is not a marketing answer: it is a fact that must be verifiable node by node.
Staff access: the inventory almost nobody asks for yet
The third element, and the one most often overlooked, is operational access: which people, vetted through which process, have production access to the system, and whether that access is recorded in an auditable log. An infrastructure can meet the two previous criteria (servers in the EU, keys in European hands) and still have technical support or maintenance staff operating from outside the Union with administrative credentials. For the sovereignty inventory to be real, it must also include people.
Why this is no longer an abstract debate: NIS2 and DORA are driving it across the Union

Two ongoing regulatory processes, across the whole Union, are pushing this inventory from optional to necessary. On 8 July 2026 the European Commission decided to refer four Member States (Ireland, Spain, France and the Netherlands) to the Court of Justice of the EU for failing to transpose the NIS2 Directive by the deadline of 17 October 2024. The Commission has asked the Court to impose a lump sum together with daily penalty payments until full transposition is notified in each case. The absence of national legislation in some Member States does not exempt essential and important entities from preparing now: the European obligation is already in force across the Union, and critical infrastructure providers, regardless of the Member State in which they operate, will be among the first to be audited once the rules apply in full.
In parallel, the DORA Regulation requires financial entities to assess and mitigate the concentration risk arising from their outsourcing arrangements, with particular attention to providers established in third countries, and to trace those subcontracting chains until they identify where operational risk actually lies. A financial entity that cannot say who operates its critical infrastructure, under which jurisdiction and with which subcontractors, cannot complete that assessment, however much the provider claims to be "European".
How this fits into the design of ISBE
ISBE, the European blockchain infrastructure operated by Alastria, is built precisely so that this inventory can be delivered, not just declared. Operator jurisdiction, the location and custody of keys in each node's HSM, and governance shared among the entities that operate the network are, by design, verifiable facts rather than a brand argument. Although its initial deployment begins in Spain under the Next Generation EU funds, ISBE is designed as a European infrastructure from its architecture upwards: interoperable with EBSI and ready to operate to the same sovereignty standard in any Member State. That is the difference between saying an infrastructure is sovereign and being able to prove it when an auditor, a supervisor or a regulated client asks.
Frequently asked questions
What exactly does "digital sovereignty" mean in the context of a blockchain infrastructure?
It means being able to verify three things independently: which jurisdiction the operator is legally accountable to, where the encryption keys that protect the data are held and who controls them, and which people have operational access to the system. Having servers located in Europe is not enough.
Why is it not enough for data to be hosted on European servers?
Because the physical location of data does not determine who can access it. If the infrastructure operator has a parent company outside the European Union, it may be subject to extraterritorial legislation, such as the US CLOUD Act, regardless of the country in which the data centres are located.
How does European digital sovereignty relate to NIS2 and DORA?
Both pieces of legislation require, in different ways, that organisations across the Union can document and audit their infrastructure and subcontracting chain. NIS2 imposes cybersecurity obligations on essential and important entities, while DORA requires financial entities to assess concentration risk among their ICT providers, especially those based in third countries. In both cases, being unable to demonstrate the jurisdiction and actual control of the infrastructure is a compliance problem, not just a reputational one.
What is the Cloud and AI Development Act and what stage is it at?
It is a legislative proposal from the European Commission, published on 3 June 2026, that sets out four progressive levels of sovereignty assurance for digital infrastructure in the EU, from the physical location of data to the complete removal of third country control. It is still going through the legislative process and is not yet law.

Redacción ISBE
Redacción @ ISBE