There’s a seductive shortcut in the digital sovereignty conversation: if software is open source, it must be sovereign. No vendor lock-in. No proprietary black boxes. Community governed. That reasoning gets you to Ceph — the dominant open source distributed storage platform — pretty quickly.
It’s also mostly wrong.
Sovereignty isn’t a licensing question. It’s a governance question. And when you stress-test Ceph against what digital sovereignty actually demands — auditability, key custody, operational independence, jurisdictional clarity — the gaps become impossible to ignore.
This post isn’t an indictment of Ceph as a storage system. It’s a corrective to the assumption that open source licensing and data sovereignty are interchangeable concepts. They’re not. Conflating them is how organisations end up with infrastructure that feels principled but fails the first serious regulatory challenge.
Sovereignty isn’t a licensing question. It’s a governance question — and Ceph was never designed to answer it.
1. Operational Complexity Is the Enemy of Auditability
Ceph’s distributed architecture — RADOS, OSDs, MONs, MGRs — is genuinely impressive engineering. It is also a sprawling operational surface. In a sovereignty context, demonstrable control isn’t just an aspiration; it’s a compliance requirement. You need to be able to explain every layer of your storage infrastructure to an auditor, a regulator, or legal counsel — in writing, with evidence.
The practical problem: Ceph’s operational overhead routinely pushes organisations toward managed services, specialist third-party operators, or heavily resourced internal platform teams. Each of those introduces a dependency. Each dependency is a potential vector through which the sovereignty claim over your data can be contested.
Operational complexity and auditability pull in opposite directions. The more opaque the infrastructure, the harder the governance story becomes — regardless of what licence the software ships under.
2. No Native KMIP. No Customer Key Custody.
Encryption at rest in Ceph is operator-managed. There is no native KMIP integration, no out-of-the-box hardware security module (HSM) binding, and no customer key custody model built into the platform.
For workloads governed by digital sovereignty frameworks — the EU AI Act, DORA, NIS2, national cloud certification schemes like France’s SecNumCloud or the EU’s EUCS — encryption key custody is the mechanism by which sovereignty is enforced. You need to demonstrate that the infrastructure operator cannot access your data without your explicit, auditable consent.
Ceph requires bolted-on solutions to get close to this. Bolt-ons can work in practice. They rarely survive rigorous certification processes — not because they’re technically wrong, but because they lack end-to-end provenance and the audit trail regulators expect from a certified platform.
3. Performance Pressure Silently Recreates the Cloud Dependency
This one rarely surfaces in architecture reviews, but it’s arguably the most insidious failure mode.
Ceph’s performance degrades non-linearly under sustained high-throughput load. Consistent, low-latency I/O — the kind demanded by AI inference workloads, high-frequency analytics, or large-scale transactional databases — requires significant and ongoing tuning investment that most teams don’t sustain past the first year.
What happens in production: organisations quietly route performance-sensitive workloads to hyperscaler object storage. It’s faster, operationally cheaper, and the performance characteristics are predictable. Nobody makes a formal architectural decision to do this. It just happens, incrementally, under delivery pressure.
The sovereignty boundary dissolves — and nobody formally decided to dissolve it. You end up with a Ceph cluster handling cold data and a hyperscaler handling everything that matters. The principled commitment to sovereign infrastructure survives only in the architecture diagrams.
4. Open Source Doesn’t Mean Jurisdiction-Neutral
Ceph is open source. Ceph is also primarily developed under the influence of IBM, headquartered in the United States, subject to US law including CLOUD Act provisions.
For jurisdictions with explicit software supply chain provenance requirements — the EUCS cloud certification scheme, SecNumCloud, and emerging frameworks across APAC and the Gulf — the licence tells you about redistribution rights. It doesn’t tell you who controls the roadmap, who holds the CVE response process, which legal jurisdiction governs the core maintainers, or what obligations those maintainers carry under the laws of their home country.
Open source is a necessary condition for sovereignty consideration in most frameworks. It is not a sufficient one. The provenance question doesn’t disappear because the source code is public.
5. No Unified Control Plane for Sovereign Hybrid Environments
Sovereignty initiatives rarely exist in isolation. They sit alongside existing cloud footprint, regulated edge deployments, AI pipelines, and legacy infrastructure. The governance requirement is end-to-end: unified policy enforcement, workload portability with custody guarantees, and consistent audit trails across the entire data estate.
Ceph has no native story for any of that. What fills the gap is custom tooling, third-party integrations, and manual policy enforcement — glue, in other words. Glue can work. Glue also fails audits — not because the underlying technology is wrong, but because it lacks the documented provenance, the structured certification trail, and the unified governance model that regulators require.
Sovereignty at scale means governance at scale. A storage platform that requires bespoke integration work at every governance touchpoint is not a sovereign storage platform — it’s a project.
What Sovereign Storage Infrastructure Actually Needs to Answer
Before selecting any storage platform for a sovereignty-driven initiative, these questions need clean answers:
- Who holds the encryption keys — and can you prove the platform operator cannot access data without explicit, auditable consent?
- Can you demonstrate end-to-end auditability across every layer of the stack, in a form regulators will accept?
- Does the platform sustain performance requirements for your most demanding workloads — without creating a silent dependency on public cloud relief valves?
- Is the software supply chain traceable to a jurisdiction-appropriate provenance?
- Can governance policy be enforced uniformly across your entire hybrid data estate from a single control plane?
- Can you certify the infrastructure against the specific frameworks your regulators require — not just broadly compliant frameworks?
Ceph answers none of these cleanly. That doesn’t make it a bad storage system. It makes it the wrong storage system for sovereignty-driven infrastructure decisions.
The organisations that get sovereignty right start with governance requirements and work back to infrastructure — not the ones that start with ‘open source’ and call it done.
The Bottom Line
Ceph is a legitimate, battle-tested distributed storage platform with a vibrant community and a strong track record in cost-driven, scale-out deployments. If your primary requirements are commodity hardware reuse, cost reduction, and object storage at scale — Ceph deserves serious evaluation.
If your requirements are digital sovereignty — regulatory compliance, encryption key custody, jurisdictional assurance, supply chain provenance, and end-to-end governance — you’re asking a platform to do something it was never designed to do.
The licence is not the architecture. And the architecture is not the governance model. All three have to align. Starting with the licence and working forward will get you to the wrong answer every time.
Sovereignty is a governance outcome. The infrastructure has to be built to deliver it.
