The Story

Last week Microsoft confirmed, in response to reporting by Forbes 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.

Matthew Green, the Johns Hopkins cryptographer, told Forbes what the lesson is: “if you have access to keys, eventually law enforcement is going to come.” Jennifer Granick at the ACLU called remote key storage “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 (Entra ID, formerly 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 by ZenDiS, a company the federal government set up in 2022 — 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:

chronikwerk (since renamed from zammad-ticket-archiver) — archival of Zammad support tickets as PDFs with adjacent JSON audit records, triggered by authenticated webhooks. It can optionally apply a PAdES signature and an RFC 3161 timestamp. It is a self-hosted service with filesystem storage and an alpha-candidate release status; the operator supplies any signing material.

escalane (since renamed from alarm-broker) — a self-hosted alarm service that turns device triggers (currently Yealink-compatible HTTP) into an operator worklist and acknowledgement links for responders. It records each alarm’s history in PostgreSQL and uses background workers to send notifications through Zammad, SendXMS (SMS) and a Signal REST bridge, and to escalate unanswered alarms. It is a public alpha and has not been validated for emergency response.

concourse (since renamed from campus-app-kit) — a TypeScript workspace for presenting public university information: a Node.js API reads an institution pack, normalises public campus web pages and ICS feeds, and serves validated JSON to an Expo client for native and web. It covers events, rooms defined in the pack, and schedules. It deliberately includes no protected connectors, credentials, SSO or user accounts.

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, monthly closing, exports, and audit records. Built around NestJS and Next.js, with a PostgreSQL backend and Honeywell terminal integration, and designed so that HR data stays on the institution’s own infrastructure. It is pre-release source for evaluation with synthetic data, not yet a production system for real employee records.

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.
  • 2026-10-03: Corrected the attribution of the “if you have access to keys, eventually law enforcement is going to come” quote from Bruce Schneier to Matthew Green (Forbes, 2026-01-22; Schneier’s post only quoted Forbes on subpoenas), and credited Forbes, which first reported Microsoft’s confirmation. Replaced “Azure Active Directory” with its current name, Entra ID. Described OpenDesk’s developer as ZenDiS, founded by the federal government, rather than the federal and state governments jointly. Fixed the cueq repository link, which returned 404 (the repository is cueq). Refreshed the project descriptions against the current repositories: zammad-ticket-archiver is now chronikwerk, alarm-broker is now escalane and campus-app-kit is now concourse, with feature descriptions corrected (for example, concourse has no room booking or private connectors, and the unverified self-hosted-keys and no-external-dependency claims were removed). Changed the summary’s “this week” to “last week” to match the body. Aligned the cueq description with its repository: pre-release source for evaluation with synthetic data; “payroll export” and “GDPR-compliant audit trails” replaced by the documented exports and audit records.