The Story

Last week Microsoft confirmed, in response to reporting by TechCrunch and others, that it had handed BitLocker recovery keys for three laptops to the FBI following a valid court order. The underlying case was a fraud investigation in Guam. The laptops were encrypted with BitLocker — the full-disk encryption built into Windows, which many institutions and individuals rely on as their primary protection against unauthorised data access.

The mechanism depends on configuration. Microsoft’s documentation says a recovery key may be saved to a Microsoft account, a work or school account, a USB drive, a file, or a printout. On eligible devices, device encryption can be enabled during setup and the recovery key attached to the account used for setup; managed organisations can instead control escrow through policy. In the reported Guam case Microsoft possessed the relevant keys and produced them after a valid legal order. That does not mean every modern Windows installation uploads a key to Microsoft.

Bruce Schneier’s response was characteristically direct: “The lesson here is that if you have access to keys, eventually law enforcement is going to come.” Jennifer Granick at the ACLU called remote key storage in this configuration “quite dangerous,” particularly given that the same mechanism is available to any government that can issue a Microsoft-compatible legal order — not only the US Department of Justice.

That last point is the one European institutions should be reading carefully.

Why This Is a European Problem

The CLOUD Act amended US law so that a provider served with a qualifying order must disclose data within its possession, custody, or control regardless of where that data is stored. The order, provider, account, and available legal challenges still matter. Foreign server location alone is not a complete jurisdictional shield. If a university’s BitLocker recovery keys are held in a Microsoft-controlled account, the institution has created a route by which a US production order may reach them.

This is a conflict-of-laws and risk-management problem, not a finding that every US-cloud use is unlawful. In Schrems II (2020), the Court of Justice invalidated the EU-US Privacy Shield and required case-specific safeguards for certain transfers. That judgment and the GDPR do not automatically decide the lawfulness of each institutional deployment. They do make data location, provider control, encryption-key custody, transfer mechanism, and access law questions that the institution must assess together.

European universities hold exactly the kinds of data that make this a real rather than a theoretical concern:

  • Research data: medical studies, clinical trials, interviews with human subjects, social science datasets — all subject to strict ethical and legal protections
  • Student records: academic performance, personal circumstances, disciplinary proceedings
  • HR data: employment contracts, salary records, health information, union activity — particularly sensitive under German and EU labour law
  • Correspondence and draft documents: research in progress, grant applications, peer review material

If the disk holding any of this is encrypted with BitLocker and its recovery key is held by a third-party provider, the encryption protects against some threats while leaving a provider-mediated recovery path. Whether a state can obtain the key depends on the applicable legal process and provider control.

The Structural Problem

The BitLocker story is one instance of a larger pattern. It is not that Microsoft behaved unusually or maliciously — it complied with a lawful order in its home jurisdiction, as it is legally required to do. The problem is structural: when an institution depends on a US-headquartered provider for key custody or critical hosted infrastructure, some operational control is shared with an entity whose legal obligations may conflict with the institution’s. Closed source can impede audit and exit, but provider control and jurisdiction—not the licence alone—create the production-order route.

This applies beyond encryption. It applies to email (Exchange Online, Outlook), document storage (SharePoint, OneDrive), communication (Teams), identity management (Azure Active Directory), and any service that runs through a Microsoft account or Azure tenant. For each of these: the data is subject to Microsoft’s terms, and Microsoft is subject to US law.

The same argument applies, with different specifics, to Google Workspace and any other US-headquartered platform. The issue is not that these companies are bad actors. It is that their legal accountability and the legal accountability of European public institutions point in incompatible directions, and the institutions mostly have not noticed.

What Sovereign Software Looks Like

The alternative is not paranoia and air-gapped servers. It is a coherent strategy for institutional digital infrastructure that is based on software the institution controls.

In Germany, this conversation has a name and a project. OpenDesk — developed under the aegis of the federal and state governments — is a stack of open-source tools (Nextcloud, Collabora Online, Matrix/ Element, Jitsi, Keycloak, Open-Xchange) assembled into an integrated workspace alternative to Microsoft 365. The Souveräner Arbeitsplatz (sovereign workspace) concept behind it addresses the control problem that the BitLocker story illustrates. Open source permits audit and self-hosting; it does not by itself guarantee that keys remain local or remove every foreign legal dependency. Deployment, operator, identity provider, support contracts, and key management decide that.

Several German states and federal agencies have been piloting OpenDesk. The city of Munich’s earlier experiment with Linux (LiMux) and its partial rollback to Microsoft products is a cautionary tale, but not a controlled test of open-source fitness. Public accounts attribute the reversal to a mixture of technical, organisational, political, and vendor factors; reducing it to one failed technology or one lobbying campaign outruns the record. The BitLocker story is a reminder of what is at stake in that political negotiation.

The FSFE’s “Public Money? Public Code!” campaign has articulated the principle cleanly: software developed with public funding should be released as open-source software. The argument is not only about freedom as an abstract value. It is about the practical consequence of being locked into a proprietary platform: your institution loses the ability to audit what the software does, to modify it to meet your requirements, to host it where your data protection law applies, and to switch providers without losing access to your own data.

What I Do, and Why

I work at a publicly funded institution. The software I build for institutional contexts — campus infrastructure, workforce management, archival systems, alert systems — is public.

Not because I am ideologically committed to open source as a movement, but because the alternative is incoherent. If I build tooling for a university with public funds and keep it closed, I have produced a private asset with public money, duplicated by every institution that builds the same thing independently, inspectable by nobody, and ultimately dependent on my continued willingness to maintain it or hand it over. None of those outcomes serve the institutions I am building for.

Here is what that looks like in practice:

zammad-ticket-archiver — automated archival of Zammad support tickets as cryptographically signed PDFs, with RFC 3161 timestamps for non-repudiation. Built for institutions that need legally defensible audit trails of their helpdesk operations. The signing infrastructure is self-hosted; no external party holds the keys.

alarm-broker — a silent panic alarm broker for campus facilities. Receives emergency triggers from hardware devices (Yealink keys), distributes notifications via Zammad, SMS, and Signal, with acknowledgment tracking and escalation scheduling. Runs locally, logs to self-hosted PostgreSQL; no external dependency for the alarm path.

campus-app-kit — a React Native / Expo starter for university mobile applications, with a pluggable Node.js backend designed for institutional data sources (room booking, events, schedules). The architecture separates institution-specific connectors (which institutions keep private) from the shared foundation (which is public). Any university can take it and build on it without starting from scratch.

cueq — an integrated workforce management system for German universities under TV-L (the collective agreement for public sector employees in the German states). Handles time recording, shift planning, absence management, payroll export, and GDPR-compliant audit trails. Built around NestJS and Next.js, with a PostgreSQL backend and Honeywell terminal integration. The HR data stays on the institution’s own infrastructure.

These are all boring. They are not research contributions; they are plumbing. But plumbing is what holds institutions together, and the question of who controls the plumbing — and under whose legal jurisdiction — is exactly the question the BitLocker story makes visible.

The Principle

Public money, public code. If an institution funded by public money develops software for its own operations, that software should be released under an open licence, inspectable, forkable, and deployable by any institution with the same needs.

The corollary: institutions funded by public money should prefer software that is itself openly licensed, auditable, and deployable on infrastructure the institution controls. Not as a blanket ban on proprietary tools where they are genuinely the best option, but as a starting presumption that shifts the burden of justification.

The BitLocker story is not a story about Microsoft doing something wrong. It is a story about the logical consequence of a procurement decision that was made without asking “and what happens when a US court sends a subpoena?” That question was available in 2018 when the CLOUD Act passed, in 2020 when Schrems II was decided, and before both. It is still available now, for every institution that has not yet asked it.

Sources

The FSFE “Public Money? Public Code!” campaign is at publiccode.eu. The OpenDesk project is at opendesk.de. The original TechCrunch reporting on the BitLocker handover is at techcrunch.com.

Legal, policy and product documentation checked through 2026-07-11.

Changelog

  • 2026-07-11: Corrected the Windows recovery-key wording: eligible devices can back a key up to a Microsoft account, but the exact behaviour depends on device, account and organisation policy. Added formal-source review for the CLOUD Act, GDPR, Schrems II, OpenDesk and LiMux history.