Sovereignty on Microsoft’s servers:
the launch that should have been impossible
You filed a bug yesterday. A margin issue in the document renderer, fifteen lines of context, two screenshots. You signed it with your real name. Your GitHub profile shows it; the project, a European sovereignty initiative, struck you as exactly the kind of work that deserves a signature.
This morning your credit card stops working.
That sequence is not, today, documented. It is the shape of a sequence the last eighteen months have made progressively plausible. On 5 May 2025, the Microsoft 365 account of Karim Khan, Chief Prosecutor of the International Criminal Court, stopped working after the Trump administration designated him personally under Executive Order 14203. In May 2026, Microsoft handed the personal data and communications of Dutch civil servants — regulators enforcing the EU Digital Services Act — to a US Congressional subpoena. In both cases the affected people had chosen a US-headquartered service provider years earlier, on the basis of reasonable institutional procurement. The political consequence was a property of the supply chain they had not audited.
Today an alliance of European companies launches a Microsoft 365 alternative. The press release calls it a milestone for European digital sovereignty. The source code is hosted by Microsoft. The build pipeline runs on Microsoft’s servers. The container images are distributed through Microsoft’s container registry. Every contribution toward European sovereignty is logged in Microsoft’s database the moment it is made — under your real name.
This is not a leak, a scandal, or an oversight. The Euro-Office repositories at github.com/euro-office are openly observable. The alliance behind the launch — IONOS, Nextcloud, EuroStack, Open-Xchange, XWiki, OpenProject and six other respected European OSS organisations — chose this hosting deliberately, and continues to consider it appropriate. The trade-press coverage of today’s launch does not mention it. The launch communications do not mention it. The European Commission’s Tech Sovereignty Package, drafted in parallel, does not address it.
It is worth saying plainly: this is absurd. Not in the colloquial sense of surprising — it is, on a quiet reading of the public documentation, exactly what one would expect — but in the sense that every standard definition of digital sovereignty the European discourse has produced over the last four years is inconsistent with what just happened. Either Euro-Office is not a sovereignty product, or the sovereignty definitions in circulation are not coherent. The launch forces a choice.
The useful version of this article is not the indignation, which writes itself. It is the audit, the reframe, and the procurement question that follow from accepting that the current sovereignty discourse has a load-bearing mistake at its centre — and that the bug report you filed yesterday is, on a long enough timeline, part of the audit trail.
What launches
Euro-Office publishes v1.0 on Tuesday, 9 June 2026. The alliance behind it is technically coherent: IONOS hosts the managed-cloud variant from Karlsruhe, Nextcloud integrates the suite into Hub 26 as the replacement default for Collabora, Open-Xchange brings the groupware heritage, and XWiki, OpenProject, Soverin, Abilian, BTactic and Office.eu contribute adjacent collaboration and hosting layers.
The four primary repositories at github.com/euro-office — eurooffice-nextcloud (PHP, AGPL-3.0), server (JavaScript, AGPL-3.0), sdkjs-forms (JavaScript, AGPL-3.0) and document-templates (Apache-2.0) — adopt the defensive licensing posture appropriate for software that gets hosted as a service: any commercial provider offering a hosted Euro-Office must publish their modifications. The Apache-2.0 on the templates is the correct choice for content. This is the strongest licensing combination in the European OSS office-suite market, materially stronger than the MPL-2.0 of Collabora Online or the single-vendor AGPL of OnlyOffice.
File-format compatibility with Office Open XML holds on the workloads that have historically broken European OSS office migrations: multi-sheet Excel workbooks with Pivot tables, Word documents with tracked changes and comments, PowerPoint with embedded animations. The available deployment options span managed cloud, hybrid and self-hosted Docker or Kubernetes, on the customer’s own Proxmox or VMware. The runtime sovereignty story is real: data in German data centres, licensing protected from closed-source fork, format independence from Microsoft’s release cadence.
There is no asterisk on this part. The product is good. The procurement decision as a product decision is defensible.
The audit
The procurement decision as a sovereignty decision is where the architecture stops cooperating.
Every commit to every Euro-Office repository, every issue, every pull request, every CI/CD pipeline run, every container image build and every release artefact flows through github.com. GitHub has been a wholly-owned subsidiary of Microsoft since June 2018. The launch communications do not address this. The trade-press coverage of the launch does not address this. The alliance has not committed to a Codeberg or Forgejo mirror, and has not announced an intent to operate a non-US build pipeline.
This is not a contractual problem — the AGPL licence preserves the right to mirror, fork and rebuild — it is an operational problem. The right to mirror is worthless until the mirror exists.
The enforcement precedent is documented and specific. In July 2019, GitHub restricted private-repository access and paid organisational accounts for developers in Iran, Syria and Crimea, in compliance with OFAC sanctions. Private projects vanished overnight. Public repositories remained accessible in read-only form, but the working infrastructure — issue tracker, pull requests, GitHub Actions, container images, package distribution — was unavailable for affected accounts until GitHub obtained an OFAC licence to restore service to Iranian developers in January 2021. In March and April 2022, the same mechanism applied to entities in Russia and to occupied parts of Ukraine under OFAC designation. Accounts associated with sanctioned entities lost access; paid organisational accounts in Crimea, Donetsk and Luhansk have remained restricted. GitHub’s Acceptable Use Policies still cite US export-control compliance as the governing rule.
The probability that this enforcement mechanism applies to a German Stadtwerke or a French établissement public in any given quarter is low. The probability over a five-year procurement horizon, against a Euro-Office stack with several hundred upstream OSS dependencies maintained globally, is materially higher than zero. The relevant base rate is not the headline cases — Iran, Russia, Crimea — but the long tail: any one critical dependency, hosted by any one developer in any one jurisdiction that becomes OFAC-relevant for any one of dozens of plausible reasons over five years. Most of those events will not affect Euro-Office adopters. Some will.
There is a second category of supply-chain exposure that is operationally more probable than sanctions enforcement: political pressure on the platform operator that produces voluntary compliance. The 2025–2026 Microsoft compliance pattern — the ICC prosecutor email suspension of May 2025 after US sanctions, the voluntary handover of Dutch regulator names to the US Congress in May 2026 — sits in this column. When a US-headquartered service provider faces US political pressure, the response is compliance, not resistance. GitHub is the same architecture. A future US administration that decided European sovereignty projects deserved attention would not need OFAC. GitHub’s Acceptable Use Policies are sufficient grounds for restriction, at the platform’s own discretion.
The audit conclusion is straightforward and unflattering: a Euro-Office adoption with no SBOM, no mirror infrastructure and no continuity plan is not architecturally more sovereign than the M365 deployment it replaces. It is contractually more sovereign — the data is in Karlsruhe, the licence is AGPL — but the supply chain ends at the same Microsoft-owned repository platform as M365’s source distribution would, if M365’s source were available at all, which it is not.
The people inside the audit
The architectural argument so far has treated risk institutionally — what happens to a Stadtwerke, what happens to a procurement decision. The same argument lands differently when it starts with people whose names are documented.
Take Khan first. The ICC is a permanent international institution, headquartered in The Hague, outside US jurisdiction. Its Chief Prosecutor’s communications were on Microsoft 365 because the ICC had made the same procurement decision every other large public-sector buyer in Europe was making at the same time, on the same reasonable-at-the-time grounds. When the Trump administration designated Khan under Executive Order 14203 in February 2025, neither the Prosecutor nor the court had a meaningful operational option: Microsoft is a US-headquartered company, the OFAC obligation is binding, the suspension followed. The procurement decision had been made years earlier; the consequence arrived in May, named and personal.
The ACM/AP case differs from Khan’s in one important way. There was no Executive Order. The subpoena came from Jim Jordan’s House Judiciary Weaponization Subcommittee, whose stated remit is to scrutinise what it calls “foreign censorship of American speech” — language that, by its own framing, includes the EU Digital Services Act and the work of the civil servants at the Authority for Consumers and Markets (ACM) and the Autoriteit Persoonsgegevens (AP) whose names Microsoft handed over. The Dutch state secretary for digital sovereignty, Willemijn Aerdts, summoned the US ambassador on the Friday the disclosure became public. The data was already on its way. Microsoft’s compliance was voluntary in the legal sense — the company was responding to a subpoena, not an OFAC order — and operationally inevitable in the way any US-headquartered service provider’s compliance would be, under the same political pressure.
Neither Khan nor the ACM and AP staff chose to be on the surface of US political pressure. They chose Microsoft as their service provider, years earlier, on the basis of entirely reasonable institutional procurement. The political surface was a property of the supply chain they did not audit.
This is the layer the Euro-Office contributors and adopters are now on.
Every developer who opens a pull request against github.com/euro-office creates a record in Microsoft’s database that links their personal identity — legal name on most accounts, real email address, IP address per session, contribution timing patterns — to active participation in a European digital sovereignty project that elements of the US Congress have publicly framed as adversarial to US commercial interests. The contributor’s day job, employer, country of residence and political affiliation are inferable from public commit history. Today the framing is rhetorical. The Khan case and the ACM/AP case demonstrate that the gap between rhetorical framing and personal consequence is, at most, one Executive Order wide.
Every public administration that adopts Euro-Office inherits, transitively, the same logging chain. Every IT lead who comments on an upstream issue has their professional position publicly linked to the project. Every Stadtwerke developer who files a bug report has their identity logged in the Microsoft audit trail. The municipal CISO who emails the alliance for a security clarification, the data-protection officer who asks about an export-compliance edge case — each interaction is recorded under a real name, on infrastructure owned by the company the project is meant to migrate away from.
None of this is malicious by Microsoft. It is the basic mechanic of running a code-hosting service. It is also the basic mechanic of a future subpoena. The Khan case shows what happens when a US Executive Order names an individual. The ACM/AP case shows what happens when a US Congressional subpoena names a category. In both cases, the affected people learned about it after Microsoft had already complied.
The strategic implication is unsentimental. Anyone — individually or institutionally — who participates in the European sovereignty project at the contributor or adopter level while it is hosted on Microsoft infrastructure is creating an audit trail under their own name, on the platform of the party the project is meant to reduce dependence on. The trail is being created today, in real time, on every commit and every issue comment. The party who has access to the trail does not need to act on it for the trail to be load-bearing — it just needs to exist.
Orwell would have appreciated the architecture. A movement organises itself to reduce its dependency on an entity. To do so, every participant signs their contribution, under their real name, on a platform owned by the entity. The entity preserves the signatures indefinitely, searchable, exportable on legal demand. Whether the entity ever acts on them is, in the medium term, secondary; whether the architecture permits the entity to act on them is, in the medium term, decided. It is decided now, with every issue ticket, by everyone who clicks submit.
Sovereignty is not what you buy
This is the reframe the launch makes hard to avoid.
The procurement industry has trained the question into a vendor-selection problem. The DSGVO, the CLOUD Act, the Tech Sovereignty Package, the §58 VgV amendment, the ES³ maturity model — all of these instruments accept the assumption that sovereignty is a property the buyer acquires by choosing the right supplier. ES³ certifies suppliers. CADA classifies suppliers. §58 VgV lets buyers prefer certain suppliers. The instruments are coherent within the assumption.
The Euro-Office launch is the cleanest case where the assumption visibly fails. The product is the best available answer to the vendor question. Adopting it without architectural work changes the vendor on the procurement line and leaves the actual dependency unchanged. The vendor on the line is now European; the supply chain that the vendor depends on is not. The buyer has acquired the appearance of sovereignty without the substance, and the substance — supply-chain continuity — was never on offer in the procurement contract.
Sovereignty, in the sense that matters for the question public-sector and regulated-private buyers are trying to answer, is not a property of vendors. It is a property of architectures. An organisation is digitally sovereign to the extent that it can continue to operate when any single piece of its software supply chain becomes unavailable. That property is built, not bought. The vendor decision is upstream of it; the work of becoming sovereign is downstream. Skipping the downstream work and calling the upstream decision a sovereignty answer is the mistake the Euro-Office launch makes impossible to ignore.
The practical consequence: the Microsoft 365 stack and the Euro-Office stack are not structurally different on the supply-chain dimension. They differ on the runtime dimension (data location, jurisdiction of operator) and they differ on the option to build supply-chain independence. M365 forecloses the option; Euro-Office preserves it. But preserving an option is not the same as exercising it. The exercise is the work.
The procurement question that actually matters
If the sovereignty question is properly architectural, the procurement question follows. It is no longer which vendor do we buy from? It becomes: what is our architecture of independence, and where does it sit on our P&L?
Three workstreams answer the reframed question. They are not optional, they are not “nice to have”, and any sovereignty procurement that omits them is a procurement performance, not a procurement decision.
One: inventory. A Software Bill of Materials audit of current production OSS components, scoped to every system with runtime exposure to internet or customer data. Per-component output: primary distribution endpoint, license, dependency-tree depth, maintainer jurisdiction. For a mid-sized organisation running 50–80 distinct OSS components in production, the audit takes 6–10 weeks and costs €25,000–€55,000 to an external specialist. The deliverable is a list, not a plan; the plan derives from the list. Most organisations discover that 80% of their supply-chain exposure concentrates in 15% of their components, and that the concentration is not where they expected.
Two: mirror infrastructure. A self-hosted Forgejo instance, bidirectionally synced to GitHub for the critical components identified in workstream one. Hosted in existing infrastructure (Proxmox, VMware, or a Hetzner VM), two VMs, separate from production. Cash cost is negligible; the work is 8–15 person-days of architect time over twelve weeks, depending on the number of repositories. The mirror does not replace GitHub for daily development; it survives GitHub for continuity. Codeberg can substitute where Forgejo self-hosting is not justified.
Three: pilot. A scoped Euro-Office pilot on a workflow with no public-facing exposure — finance, internal HR, controlled groupware — running 6–12 months with explicit go/no-go criteria tied to the mirror infrastructure reaching production-grade reliability. Cost: €8,000–€20,000 in setup support from a Nextcloud partner plus internal time. The pilot validates the product; workstreams one and two validate the sovereignty.
A buyer who runs all three has bought Euro-Office and built sovereignty. A buyer who runs workstream three alone has bought a different vendor. The procurement decision is the same in both cases. The architecture decision is not.
The strategic positioning question for the next twelve months is not whether Euro-Office is the right product. It is whether your organisation is prepared to treat sovereignty as architecture rather than as procurement — and whether your board, your auditors and your regulator will accept the architecture answer as the sovereignty answer. They will, increasingly. The Tech Sovereignty Package proposes CADA-level classification by 2027. ES³ already certifies methodology rather than products. The signals from the regulatory layer are converging on architecture, not on vendor logo. The vendor logo is the lagging indicator; the architecture is the leading one.
What this article is not
It is not a claim that Euro-Office is the wrong choice. The product is the strongest open-source M365 alternative on the European market. It is not a claim that GitHub will block EU developers. It is a claim that sovereignty as a procurement category is the wrong frame, the Euro-Office launch is the cleanest available example of why, and the work the frame has been hiding is the actual answer to the question public-sector and regulated-private buyers are trying to ask.
Sources
- Nextcloud: Sovereign office suite Euro-Office to release June 9
- Nextcloud: Euro-Office general availability set for June 9
- GitHub: Euro-Office organisation repositories
- TechCrunch: GitHub confirms it has blocked developers in Iran, Syria and Crimea (July 2019)
- GitHub blog: GitHub is fully available in Iran (January 2021)
- GitHub blog: Our response to the war in Ukraine (sanctions response, March–April 2022)
- GitHub: Acceptable Use Policies — export controls clause
- Codeberg: European Git hosting cooperative
- Forgejo: free software fork of Gitea
- FSF: GNU Affero General Public License v3
- SPDX SBOM specification
- Microsoft hands over Dutch names to US Congress
Topic overview: Digital Sovereignty in Europe Related articles: EU Tech Sovereignty Package, Microsoft hands over Dutch names