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

European boards keep asking whether Gaia-X solves the sovereignty problem. 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, a 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, what its labels promise, and where the guarantee stops and your 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 said "Gaia-X as a construct is only reinforcing the status quo, which is that dominating players will keep dominating" — naming AWS, Microsoft, Google, Huawei, and Alibaba as members of 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 v2.0 with Gaia-X-specific restrictions — JSON-LD claims using the Gaia-X ontology, credentials encoded as VC-JWTs (enveloping proofs), and the signing key's X.509 chain carried via the verification method's publicKeyJwk x5c or x5u.

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/ns/credentials/v2",
    "https://w3id.org/gaia-x/development#"
  ],
  "type": ["VerifiableCredential"],
  "id": "https://example.com/.well-known/lrn.json",
  "issuer": "did:web:registration.lab.gaia-x.eu",
  "validFrom": "2026-06-25T14:38:38.898Z",
  "credentialSubject": {
    "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: a did:web document from your .well-known path and certificate chain; a self-signed gx:LegalParticipant credential referencing the registration credential's subject; a self-signed gx:GaiaXTermsAndConditions credential pledging Policy Rules adherence; and one self-signed gx:ServiceOffering per service. A hundred services means a hundred offerings. All of it is bundled into a Verifiable Presentation and POSTed to a Gaia-X Digital Clearing House.

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

# 2. Self-issue participant, T&C, and each ServiceOffering as VC-JWTs
#    (validFrom; did:web + x5c/x5u). Sign with your own tooling → files e.g.
#    participant.vc.jwt  tandc.vc.jwt  offering.vc.jwt

# 3. Bundle EnvelopedVerifiableCredentials into a VP-JWT; POST to Compliance.
#    Success returns a gx:ComplianceCredential VC-JWT.
curl -sS -X POST \
  'https://gxdch.example-clearinghouse.eu/v2/api/credential-offers/standard-compliance?vcid=https%3A%2F%2Fexample.com%2F.well-known%2Fcompliance.jwt' \
  -H 'Content-Type: application/vp+jwt' \
  -H 'Accept: application/vc+jwt' \
  --data-binary @vp.jwt \
  -o compliance.vc.jwt

# 4. Publish. The catalogue 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 to the Eclipse Foundation as XFSC under Apache-2.0 across roughly 110 repositories. You can clone them today; the commit graphs show 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. Gaia-X lists no Permissible Standard against P5.1.6 at all — only an Example Standard, clause 19.6 of France's SecNumCloud 3.2.a (8 March 2022). (The Permissible Standard "SecNumCloud: 19.6" is attached to P5.1.4, the head-office criterion.) 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 substrate those production data spaces run on. 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/*"]
          attestations:
            - type: https://slsa.dev/provenance/v1
              attestors:
                - entries:
                    - keyless:
                        subject: "https://forgejo.internal.example.eu/platform/*"
                        issuer: "https://forgejo.internal.example.eu"
                        roots: |
                          -----BEGIN CERTIFICATE-----
                          ...
                          -----END CERTIFICATE-----
                        rekor:
                          url: https://rekor.internal.example.eu
                          pubkey: |
                            -----BEGIN PUBLIC KEY-----
                            ...
                            -----END PUBLIC KEY-----
                        ctlog:
                          ignoreSCT: true
              conditions:
                - all:
                    - key: "{{ runDetails.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. Private Fulcio roots and a private Rekor (URL and pubkey) keep public Sigstore trust material out of the decision; ctlog.ignoreSCT only skips SCT checks because this private Fulcio has no CT log. 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.