CloudCondom / Phantom
EU data sovereignty on US cloud infrastructure. Cryptographic proof that your cloud provider cannot access your data.
The Problem
Every EU company running workloads on US cloud infrastructure faces an unresolved legal and technical conflict:
Schrems III is expected — Max Schrems' appeal to CJEU could invalidate the current Data Privacy Framework, repeating the Privacy Shield collapse. The Trump administration has already removed PCLOB quorum, weakening the legal basis for EU-US data transfers.
DORA enforced January 2025 — EU financial sector must demonstrate ICT risk management for cloud dependencies. NIS2 transposition underway — broadens cybersecurity requirements to 18 sectors.
The Solution
Phantom is a Kubernetes operator that injects a sidecar via mutating webhook, which fetches secrets from an EU-hosted OpenBao/Vault instance directly into process memory — secrets never touch etcd, never enter Kubernetes Secrets, and the cloud provider never holds the keys.
How It Works
Mutating admission webhook adds a sidecar to each pod. The sidecar fetches secrets from EU-hosted OpenBao using hardware attestation (AMD SEV-SNP / Intel TDX). Secrets live only in process memory — never on disk, never in etcd.
Key Differentiator
Even if the webhook is deleted, secrets are never exposed — because they were never stored in Kubernetes. The trust model is: "Webhook = UX, crypto = security boundary."
The unique positioning: Stay on AWS/GCP/Azure. Change nothing in your application code. Get cryptographic proof that the cloud provider cannot access your secrets. No existing product combines all of: K8s-native + secrets-never-in-etcd + no code changes + hardware attestation + EU sovereignty focus.
The EU Cloud Reality
The obvious question: "Why not just move to an EU cloud provider?" Because in 2026, that’s not a realistic option for most enterprises:
Limited Service Parity
OVHcloud, Scaleway, T-Systems, and other EU providers offer a fraction of the services available on AWS, GCP, or Azure. No equivalents for managed ML pipelines, global CDNs, hundreds of managed databases, or the deep ecosystem integrations enterprises depend on.
Immature at Enterprise Scale
EU clouds lack the reliability track record, global presence, and battle-tested infrastructure that enterprises require. Multi-region HA, auto-scaling at scale, and enterprise SLAs are still catching up.
Migration Cost & Risk
Re-architecting applications built on AWS/GCP/Azure services is a multi-year, multi-million euro project. The technical dependencies run deep — IAM, networking, storage APIs, managed services. Migration risk is enormous.
Talent & Ecosystem Gap
Engineers know AWS/GCP/Azure. Tooling, documentation, community support, and third-party integrations are built around the hyperscalers. Switching means retraining teams and rebuilding operational expertise.
The CloudCondom Approach
Don’t migrate — insulate. Keep using the most stable, mature, feature-rich cloud infrastructure in the world. Add a cryptographic layer that makes US jurisdiction irrelevant to your data security. When a CLOUD Act subpoena arrives, the provider can only hand over ciphertext and encrypted memory — useless without keys held in EU-hosted OpenBao.
EU sovereign clouds will mature eventually. But your compliance obligations are today. CloudCondom bridges the gap — giving you sovereignty guarantees now, on infrastructure that actually works at scale, while EU alternatives continue to develop.
“But We Already Have HYOK / Cloud EKM”
Every major cloud provider offers Hold Your Own Key (HYOK) and External Key Manager (EKM) — you control the encryption key, the provider encrypts your data with it. This sounds like it solves the problem. It doesn’t.
Keys Are Loaded Into Provider Memory
When GCP/AWS calls your external KMS to decrypt a disk or Secret, the plaintext key enters the provider’s RAM. A CLOUD Act order can compel them to extract it from memory or intercept it during use. HYOK protects data at rest, not in use.
Provider Controls the Compute Layer
Even with EKM, the cloud provider runs the hypervisor, control plane, etcd, and kubelet. They can snapshot VM memory, patch the hypervisor, or intercept API calls. Your key “held outside” is still used inside their infrastructure.
K8s Secrets Are Plaintext Regardless
When a pod reads a K8s Secret, the API server decrypts it and serves it in plaintext over the API. EKM encrypts etcd’s storage layer, but any cluster-admin (or the provider itself) can kubectl get secret -o yaml and see everything.
Revocation Is a Kill Switch, Not Protection
Revoking your external key stops your entire workload. It’s a nuclear option, not an operational security control. You can’t selectively protect secrets — it’s all or nothing.
| Property | HYOK / Cloud EKM | Phantom |
|---|---|---|
| Protection at rest | Yes | Yes (secrets not stored at all) |
| Protection in use | No — key in provider RAM during use | Yes — secrets in pod memory only |
| Provider can access plaintext | Yes — during decryption operations | No — secrets never enter provider infra |
| Survives CLOUD Act subpoena | No — provider compelled to intercept key in use | Yes — nothing to intercept, keys in EU |
| K8s Secrets in etcd | Yes — encrypted but decrypted on read | No — secrets bypass etcd entirely |
| Granular revocation | All-or-nothing (kills workload) | Per-secret, per-namespace |
| Code changes | None | None |
The Key Difference
HYOK/EKM encrypts your data with your key but still processes it inside the provider’s infrastructure. The provider handles decryption, holds plaintext in memory, and can be legally compelled to intercept it. Phantom ensures sensitive data never enters that infrastructure at all — secrets travel directly from EU-hosted OpenBao to your pod’s process memory, bypassing Kubernetes entirely.
Competitive Positioning
No existing product combines all of CloudCondom’s capabilities:
| Capability | CloudCondom | Thales CipherTrust | Fortanix | Anjuna | ESO | Sealed Secrets |
|---|---|---|---|---|---|---|
| K8s-native (operator/webhook) | Yes | No | No | Partial | Yes | Yes |
| Secrets never in etcd | Yes | N/A | N/A | N/A | No (syncs to etcd) | No (in etcd) |
| No code changes required | Yes | No | No (enclave rewrite) | Partial | Yes | Yes |
| Customer-controlled keys (external) | Yes | Yes | Yes | Yes | Depends | No (in-cluster) |
| Cross-provider K8s | Yes | Yes | Yes | No | Yes | Yes |
| Hardware attestation | Yes (SEV-SNP/TDX) | No | Yes | Yes | No | No |
| EU sovereignty focus | Primary | Secondary | No | No | No | No |
Market Signals
Why Now?
- DORA enforced January 2025 — EU financial sector must demonstrate ICT risk management
- NIS2 transposition underway — broadens cybersecurity requirements to 18 sectors
- DPF governance undermined — Trump administration removed PCLOB quorum
- Schrems III expected — could invalidate DPF, repeating Privacy Shield collapse
- AWS European Sovereign Cloud launched Jan 2026 — validates market but doesn’t solve jurisdictional problem
- GDPR fines accelerating — Uber €290M, TikTok €530M, Meta €1.2B
- Denmark ditching Microsoft for sovereignty reasons
Success Factors & Risks
What Would Make This Succeed
Ruthless Scoping
Phantom-only, GKE-only, direct Helm install. Nothing else for v1.
Managed OpenBao Offering
Eliminates the #1 operational risk and rarest skill requirement.
Independent Security Audit
NCC Group or Trail of Bits before enterprise sales. Non-negotiable for a security product.
2–3 Design Partners
EU financial services companies as early adopters. Their compliance teams validate the approach, their logos build trust.
Certifications
BSI C5 + SOC 2 Type II — required for enterprise sales in EU. Start at month 3.
Transparent Limitations
Especially EKS confidential computing gaps and TEE vulnerabilities. Honesty builds more trust than marketing.
What Would Kill This
Scope Creep
Trying to build all 5 solutions simultaneously instead of shipping Phantom alone.
Multi-Provider from Day 1
Trying to support AWS, GCP, and Azure before proving PMF on a single provider.
Skipping the Audit
No enterprise will trust an unaudited security product from an unknown startup.
Major TEE Vulnerability
An unmitigable hardware vulnerability in SEV-SNP/TDX (unlikely but possible).
Durable EU-US Legal Agreement
Eliminates the sovereignty concern entirely (unlikely given political trends).
Hyperscaler Builds It Natively
Possible, but they have jurisdictional conflicts of interest that make this hard.
B2C Expansion: Consumer Data Protection
OpenClaw-Style Open Deployment for End Users
Beyond enterprise B2B, CloudCondom’s core technology enables an open-source, consumer-facing deployment model — similar to how OpenClaw democratizes legal tools — that puts data sovereignty directly in the hands of individual users and small organizations.
The Consumer Problem
Consumers today have zero visibility into how cloud-hosted services handle their personal information. When a SaaS app stores your data on AWS or Azure, you have no way to know if that data is accessible to foreign governments, sold to data brokers, or sitting unencrypted in an etcd cluster. GDPR gives EU citizens rights on paper — but no technical enforcement mechanism.
How CloudCondom Enables B2C Protection
Use Cases
- Self-hosted SaaS users — Deploy Phantom alongside Nextcloud, Vaultwarden, or Matrix to ensure your personal cloud data stays encrypted with your keys, even on a Hetzner/OVH VPS.
- Small businesses & freelancers — Run client data on GKE/EKS with cryptographic guarantees, satisfying GDPR without enterprise budgets or legal teams.
- Healthcare & legal professionals — Patient records and legal documents protected by hardware attestation, with alerts if the data protection posture changes.
- Developers building privacy-first apps — Embed Phantom as a dependency, offering end users verifiable proof that their data is sovereign-protected.
- Digital nomads & cross-border workers — Personal data automatically protected regardless of which jurisdiction your cloud provider operates in.
The OpenClaw Parallel
Just as OpenClaw makes legal tools accessible to everyone — not just those who can afford lawyers — CloudCondom’s B2C model makes data sovereignty accessible to individuals and small teams, not just enterprises with six-figure security budgets. The same cryptographic engine that protects a bank’s Kubernetes cluster can protect a freelancer’s self-hosted CRM. Data sovereignty should not be a privilege of scale.
Revenue Model
The B2C layer follows an open-core model: the protection agent and alerting engine are open-source and free; the managed key hosting (EU-based OpenBao), advanced alerting integrations, compliance reporting, and multi-cluster management are premium tiers. This creates a community-driven adoption funnel that feeds the enterprise pipeline — developers who use Phantom personally become advocates inside their companies.
Revenue Timeline
Webhook + sidecar + OpenBao secrets injection (no attestation)
Circuit breaker, caching tiers, pre-flight checks, Prometheus metrics
AMD SEV-SNP attestation on GKE — MVP ready for design partners
Helm chart, docs, first design partner deployments
First paying customer
$1M ARR
$5M ARR
Ideal Customer Profile
EU enterprises (500–10,000 employees) running regulated workloads on managed Kubernetes (GKE/EKS/AKS) who cannot move to sovereign EU clouds, face regulatory pressure, and need demonstrable supplementary measures per Schrems II.
| Industry | Pain Level | Willingness to Pay | Priority |
|---|---|---|---|
| Financial services | Very High | Very High | 1 |
| Healthcare / pharma | High | High | 2 |
| Government / public sector | Very High | Medium (procurement) | 3 |
| SaaS serving EU customers | High | Medium-High | 4 |
| Manufacturing / automotive | Medium-High | Medium | 5 |
Security & Regulatory Alignment
Phantom provides real cryptographic guarantees against documented threats — not security theater:
- CLOUD Act subpoena: Provider has no keys, no plaintext. Only ciphertext and encrypted memory.
- FISA 702 bulk collection: Intercepted data is encrypted with keys the provider doesn’t hold.
- Compromised cluster-admin: Can delete webhook but cannot extract secrets from running pods (in-memory only) or from OpenBao (requires attestation).
| Regulation | Alignment | Notes |
|---|---|---|
| GDPR Art. 32 | Strong | Encryption with customer-controlled keys |
| GDPR Art. 44–49 | Strong | Supplementary technical measures per EDPB guidelines |
| Schrems II | Strong | Designed specifically for this |
| NIS2 | Good | Supply chain security, incident reporting |
| DORA | Good | ICT risk management, third-party oversight |
| BSI C5 / EUCS | Planned | Certification on the roadmap |
Final Assessment
CloudCondom/Phantom addresses a real, urgent, and growing problem with a technically sound and differentiated approach. The market timing is excellent. The core idea — secrets never in etcd, customer-controlled keys, hardware attestation — is the right architecture.
The main risk is not the idea itself but execution discipline: shipping Phantom alone on one provider, building trust through audits and certifications, and resisting the urge to build the full 5-product suite before the first product finds paying customers.
Recommendation: Build it. Start with Phantom on GKE. Get 3 design partners in EU financial services. Get an independent security audit. Everything else is Phase 2.