Gaia-X in Practice: Federation, Labels, and the Sovereignty Gap

Every few months a European engineering leader forwards the same question: the board has asked whether Gaia-X solves our sovereignty problem — does it? Answering it requires separating three things that European cloud discourse habitually fuses. There is the political project, launched by 22 French and German organisations in 2021. There is the technical specification, which is a genuinely well-designed credential and ontology stack. And there is the marketing halo, where most of the confusion lives. This article is about the second — what Gaia-X specifies, what running it costs you, what its labels legally promise, and precisely where the guarantee stops and your own architecture has to begin.

What Gaia-X is, precisely

Gaia-X AISBL is a Belgian non-profit association, headquartered in Brussels, founded in early 2021 by eleven French and eleven German organisations — among them Bosch, SAP, Siemens, Deutsche Telekom, Orange, EDF, OVHcloud, and Scaleway. It does not operate infrastructure. It does not host workloads. It publishes documents: a Trust Framework, an Architecture Document, a Compliance Document, and an ontology. Third parties then implement them.

The association is alive and shipping. Its Trust Framework reached the "Danube" release in early 2026, presented as the moment Gaia-X moves "from pilot implementations to operational deployment." It is also alive to its critics. Scaleway, a founding member, walked out in November 2021; then-CEO Yann Lechelle's stated reason was that "Gaia-X as a construct is only reinforcing the status quo, which is that dominating players will keep dominating" — a reference to AWS, Microsoft, Google, Huawei, and Alibaba all holding membership in a European sovereignty initiative. CISPE, itself a Gaia-X board member, has been blunt that "a GAIA-X label indicates data portability compliance, not Full EU Isolation."

Both things are true at once. Gaia-X has not delivered a European cloud — European providers still hold roughly 15% of their own local market against about 70% for the three American hyperscalers, per Synergy Research. And it has delivered a specification that solves a real, narrow, unglamorous problem: making a provider's compliance claims cryptographically verifiable by a machine rather than readable as a PDF.

The artifacts you would actually operate

If you are a European provider — or a regulated enterprise publishing internal services into a federated catalogue — Gaia-X compliance is a concrete engineering task. The old "Self-Description" terminology is gone: Self-Descriptions are now Verifiable Presentations bundling Verifiable Credentials, following the W3C Verifiable Credentials Data Model v1.1 with Gaia-X-specific restrictions — JSON-LD serialization, claims as RDF triples, the Gaia-X ontology mandatory in the @context, and a JSON Web Key verification method carrying a compacted JWS-2020 proof.

A minimal Gaia-X Legal Registration Number credential — the one you cannot self-sign, because a clearing house must issue it after checking your VAT identifier against the EU VIES register — looks like this:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/security/suites/jws-2020/v1"
  ],
  "type": ["VerifiableCredential"],
  "id": "https://example.com/.well-known/lrn.json",
  "issuer": "did:web:registration.lab.gaia-x.eu:v1",
  "issuanceDate": "2026-06-25T14:38:38.898Z",
  "credentialSubject": {
    "@context": "https://registry.lab.gaia-x.eu/development/api/trusted-shape-registry/v1/shapes/jsonld/trustframework#",
    "type": "gx:legalRegistrationNumber",
    "id": "https://example.com/.well-known/lrn.json#subject",
    "gx:vatID": "DE123456789",
    "gx:vatID-countryCode": "DE"
  },
  "evidence": [
    { "gx:evidenceURL": "http://ec.europa.eu/taxation_customs/vies/" }
  ]
}

Around that one credential you assemble the rest yourself: a did:web document served from your own .well-known path and anchored to your certificate chain; a self-signed gx:LegalParticipant credential referencing the registration credential's subject; a self-signed gx:GaiaXTermsAndConditions credential pledging adherence to the Policy Rules; and one self-signed gx:ServiceOffering credential per service. A provider with a hundred services issues a hundred service credentials. All of it is bundled into a Verifiable Presentation and POSTed to a Gaia-X Digital Clearing House.

# 1. Notarize your legal identity (only a GXDCH can sign this one)
curl -sS -X POST \
  https://gxdch.example-clearinghouse.eu/v1/registrationNumberVC \
  -H 'Content-Type: application/json' \
  -d '{"@context":["https://www.w3.org/2018/credentials/v1"],
       "type":"gx:legalRegistrationNumber",
       "gx:vatID":"DE123456789"}' \
  -o lrn.vc.json

# 2. Self-sign participant + T&C + one offering per service (JWS-2020)
gx-agent vc create --type LegalParticipant --lrn lrn.vc.json  > participant.vc.json
gx-agent vc create --type GaiaXTermsAndConditions             > tandc.vc.json
gx-agent vc create --type ServiceOffering --service k8s-eu-01 > offering.vc.json

# 3. Bundle into a Verifiable Presentation, submit for compliance
gx-agent vp bundle participant.vc.json tandc.vc.json offering.vc.json > vp.json
curl -sS -X POST \
  https://gxdch.example-clearinghouse.eu/v1/api/credential-offers \
  -H 'Content-Type: application/json' --data @vp.json \
  -o compliance.vc.json

# 4. Publish. The catalogue now holds a signed, revocable claim.

Click to zoom

The clearing house is not run by Gaia-X. The association deliberately delegates operation to commercial third parties: a GXDCH bundles a Compliance Service, the Gaia-X Registry of trust anchors and shapes, Notarization Services, a Credential Event Service, an IPFS node for cross-clearing-house synchronisation, and a logging service. Gaia-X's own listing of operators — last substantively dated to 2024 — names four launched clearing houses (Aruba, T-Systems, Aire Networks, Arsys) alongside its test environment, with OVH, Exaion, Orange, Proximus and KPN announced. No refreshed 2026 count appears to exist, which is itself informative about the operational tempo.

The reference implementations are real open source: the Compliance Service at gitlab.com/gaia-x/lab/compliance/gx-compliance under EPL-2.0, and the federation components once called GXFS, migrated wholesale to the Eclipse Foundation and now shipping as XFSC under Apache-2.0 across roughly 110 repositories. You can clone them today. Whether many people do is a different question, and the honest read of the commit graphs is: a small, committed group.

Reading Label Level 3 literally

Above baseline Standard Compliance, Gaia-X defines three optional label levels, ascending in strictness across transparency, autonomy, data protection, security, interoperability, flexibility, and European Control. Level 3 is the one invoked in sovereignty marketing, and it is where engineers should read the primary text rather than the summary. In the current Compliance Document, criterion P5.1.2 requires that for Level 3 "the Provider shall process and store all Customer Data exclusively in the EU/EEA." That part does what it says. Criterion P5.1.6 is the one that carries the "immunity from non-European access" reputation. Here it is, in full:

That distinction is the whole article in miniature: contractual sovereignty and architectural sovereignty are different goods. The only "Permissible Standard" Gaia-X lists against P5.1.6 is France's SecNumCloud 19.6 — a national qualification with real ownership and jurisdiction tests behind it. Gaia-X's strongest sovereignty claim is a pointer to somebody else's certification scheme. Meanwhile the EU's own attempt to write that requirement into law, the European Cybersecurity Certification Scheme for Cloud Services (EUCS), has been deadlocked since 2021. ENISA's first draft landed in December 2020; the Commission later asked for a clause keeping the highest assurance level out of non-European jurisdiction; a third version in March 2024 removed it and deferred the question to national regulators. Work is now "expected to resume." If you are waiting for a regulatory definition of sovereign cloud before you architect for it, you have been waiting five years.

Three layers of sovereignty; Gaia-X attests one

Decompose sovereignty into layers that fail independently. The attestation layer asks: can a machine verify this claim, and can it be revoked? The control layer asks: who holds the keys, who operates the control plane, who signs the admission policy? The jurisdiction layer asks: who can lawfully compel disclosure? Gaia-X is an excellent answer to the first question. It is silent on the second. It answers the third with a promise to litigate.

Click to zoom

This decomposition is not a rhetorical trick; it is the same structure that shows up whenever European regulation meets infrastructure. It is why NIS2, DORA, and the EU AI Act converge on one architecture constraint rather than three checklists, and why high-risk AI systems end up running inference on-premises regardless of what the vendor contract says about residency. A signed claim is not a key. A key you hold is not a jurisdiction you escape.

The 2026 stress test: sovereign clouds with American parents

The hyperscalers have spent two years building the thing Gaia-X was supposed to make unnecessary. AWS opened its European Sovereign Cloud to general availability on 15 January 2026 — a distinct partition (aws-eusc) with a first region in Brandenburg (eusc-de-east-1), roughly ninety services, dedicated IAM and billing, EU-resident staff, and a €7.8 billion commitment, all under a new German parent company, AWS European Sovereign Cloud GmbH. Oracle has run an EU Sovereign Cloud since 2023 with 1,500-plus EU-based staff. Microsoft's Sovereign Public Cloud adds controls and an EU Data Boundary on top of standard Azure infrastructure, with no separate legal entity at all. Google's answer is structurally different: S3NS, a joint venture in which Thales holds the majority, whose PREMI3NS tier runs on infrastructure operated exclusively by S3NS and which passed SecNumCloud 3.2 qualification on 17 December 2025.

Only one of those four is not ultimately controlled by an American parent. That distinction became concrete on 10 June 2025, when Anton Carniaux, Microsoft France's director of public and legal affairs, testified under oath before a French Senate inquiry into digital sovereignty in public procurement. Asked whether he could guarantee that French citizens' data would never be transmitted to US authorities without French authorisation, he answered: "No, I cannot guarantee it." Asked whether a properly framed US request would oblige Microsoft to transmit the data, he said: "Absolutely, by respecting this process." He added, accurately, that no European public-sector customer had ever been affected.

Note what that testimony is and is not. It is not evidence of misconduct. It is evidence of structure. The US CLOUD Act reaches any provider with a legal presence in the United States, and courts can compel a US parent to produce data held by a foreign subsidiary — which is exactly the shape of AWS European Sovereign Cloud GmbH. Corporate separation is a real cost and a real signal of intent; it is not a jurisdictional firewall. The June 2026 US Supreme Court decision in Trump v. Slaughter, on presidential removal power over Federal Trade Commission commissioners, has now put pressure on the institutional-independence assumptions underpinning the EU-US Data Privacy Framework adequacy decision; noyb has announced a CJEU challenge, and Gaia-X published a position paper on 3 July 2026 arguing that auditable, participant-controlled rules reduce dependence on "the continued stability of external political assurances." On that point Gaia-X is right — adequacy decisions are political weather, and you should not build a load-bearing wall out of weather.

Where Gaia-X earns its keep: data spaces

Strip away the sovereign-cloud framing and one domain remains where the Gaia-X stack is unambiguously working: multi-party data exchange between organisations that do not trust each other and cannot centralise. This is the problem verifiable credentials were designed for, and it is where the code is alive.

Eclipse Dataspace Components — the connector framework powered by both the Gaia-X Trust Framework and the IDSA Dataspace Protocol — is the most active artifact in the ecosystem: 283 stars and 377 forks on the main connector repository, over two thousand commits from three dozen contributors in the trailing year. Catena-X, the automotive data space built on it, is in production, not pilot: BMW had established over a hundred digital supplier connections by the end of 2024, Catena-X registration has been integral to BMW procurement since April 2025, and eight of the ten largest automotive suppliers in the world exchange data through it. Germany has funded Manufacturing-X to €140 million; the Mobility Data Space runs with roughly 165 member organisations.

What you still have to build yourself

Everything in the control layer. Gaia-X attests that you claim to run a compliant service; it does not run it. The properties that deliver sovereignty are properties of your own stack, and each has a mature open-source answer no clearing house mediates.

• Control-plane custody. An immutable, API-driven node OS with no shell and no SSH — the security case for Talos Linux is precisely that the control plane's attack surface becomes enumerable rather than emergent.
• Key custody. Your own PKI and your own key store. A provider that holds your keys can be compelled to use them; a provider that holds ciphertext cannot decrypt it for anyone.
• Workload identity. SPIFFE/SPIRE issues short-lived, attested identities to workloads without a vendor in the trust path — the same verifiable-credential idea as Gaia-X, applied where it changes an authorisation decision.
• Supply-chain attestation. Sigstore signatures, SLSA provenance, and SBOMs let you produce the evidence yourself, continuously, in CI — not annually, for an auditor.
• Data-in-use protection. Where the threat model includes the operator, hardware TEEs with remote attestation are the only mechanism that makes "the host cannot read your memory" a technical statement rather than a contractual one.
• Identity you control. Federation is worthless if the identity provider is a foreign SaaS; self-hosted Keycloak, Authentik, or Zitadel keeps authentication inside the perimeter you are certifying.

The last four are the same primitives Gaia-X uses — signatures, attestations, verifiable claims — pointed at your own infrastructure instead of a catalogue entry. You do not need a clearing house to prove the image running in production is the image your CI built:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-sovereign-provenance
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-slsa-provenance
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences: ["registry.internal.example.eu/*"]
          attestors:
            - entries:
                - keyless:
                    subject: "https://forgejo.internal.example.eu/platform/*"
                    issuer: "https://forgejo.internal.example.eu"
          attestations:
            - type: https://slsa.dev/provenance/v1
              conditions:
                - all:
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://woodpecker.internal.example.eu"

That policy runs on infrastructure you own, signs with an identity you control, and produces a verifiable record every time a pod is admitted. It is, in the strictest sense, more sovereign than any label — because nothing outside your perimeter has to be trusted, or asked, or subpoenaed, for the guarantee to hold. The same reasoning generalises: policy-as-code with Kyverno converts governance from a document into an admission decision.

The exit ramp: what Gaia-X is actually good for

The pragmatic recommendation is not "ignore Gaia-X." Use it as an optionality instrument. The most valuable thing the Trust Framework produces is a structured, machine-readable, comparable description of a service offering — the raw material of a migration plan. A gx:ServiceOffering credential enumerating data location, subprocessors, termination terms, and portability guarantees is exactly the artifact engineering discovers is missing on the day it wants to leave.

So: demand Gaia-X credentials from European vendors, because they make the claims checkable and revocable, and because a vendor unwilling to sign a machine-readable claim has told you something. Then architect as though the credential does not exist. Keep the control plane portable, keep object storage on an S3-compatible layer you can move between MinIO successors, keep the CI system replaceable, and rehearse the exit rather than documenting it. The organisations that have executed a real repatriation from hyperscaler to owned infrastructure uniformly report that the exit was constrained by architectural coupling, never by paperwork. No label removes coupling.

The long game

Europe has committed real money — €1.2 billion of approved public aid across seven member states under IPCEI-CIS, drawing an estimated €1.4 billion of private investment; €11 billion from the Schwarz Group into StackIt; €250 million into a federal sovereign AI cloud whose winning consortium contains no American provider. That capital will build something. Whether Gaia-X is the standard it converges on, or a well-designed specification that a later effort quietly absorbs, is genuinely unresolved five years in.

What is not unresolved is the engineering posture. Frameworks are decade-scale bets with political failure modes; a Kubernetes control plane you operate, on hardware you own, with keys you hold, is a decade-scale bet with engineering failure modes. Engineering failure modes are the kind you can fix on a Tuesday. Adopt the credential standard because interoperability compounds and open specifications are how a practice earns leverage over time. Do not outsource the trust boundary to it. When a European Commission working group deadlocks for the sixth year, or an adequacy decision falls to a court, the teams that will not notice are the ones whose sovereignty was never a claim about jurisdiction in the first place — it was a claim about who holds the private key.