The Cloud Native Computing Foundation’s 2025 survey reported that 94% of organizations use at least one public cloud provider. The same survey found that 68% describe themselves as “locked in” to their primary provider. What the survey did not ask — and what almost no industry analysis addresses — is what lock-in means for privacy.
The conventional lock-in discussion centers on cost and operational friction. Rewriting applications to use different APIs. Retraining operations teams. Paying egress fees to extract data. These are real costs, and they receive extensive coverage. But the privacy dimension of lock-in is more insidious and less reversible: when your encryption keys, access policies, audit logs, and identity systems are entangled with a single provider’s proprietary infrastructure, your privacy posture is not yours. It belongs to whoever controls that infrastructure.
This is not a theoretical risk. It is a structural dependency that compounds over time and becomes prohibitively expensive to unwind — not in dollars, but in privacy guarantees.
The Anatomy of Privacy Lock-In
Cloud lock-in is not a binary state. It is a gradient with identifiable layers, each adding friction to exit and privacy dependency to the provider.
Layer 1: Compute and Networking
The most superficial layer. Virtual machines, containers, and network configuration are largely portable across providers. A Docker container runs the same on AWS ECS, Azure Container Instances, and Google Cloud Run. Kubernetes provides a common orchestration layer. At this level, lock-in is operational, not privacy-related.
Layer 2: Managed Services
DynamoDB, Cosmos DB, Cloud Spanner. BigQuery, Redshift, Synapse. Lambda, Azure Functions, Cloud Functions. Each of these managed services has a proprietary API, proprietary data format, and proprietary operational model. Migration requires rewriting application logic, not just redeploying containers.
The privacy implication: data stored in proprietary managed services is stored in proprietary formats with provider-controlled encryption. A DynamoDB table encrypted with AWS-managed keys cannot be read without AWS KMS. The data is yours. The ability to decrypt it is not.
Layer 3: Identity and Access Management
AWS IAM, Azure Active Directory (now Entra ID), Google Cloud IAM. Each implements a different authorization model with different policy languages, role hierarchies, and permission boundaries. Your access control logic — who can see what data under what conditions — is encoded in a provider-specific format.
This is deep privacy lock-in. Your access policies define the privacy boundaries of your system. If those policies are expressed in a proprietary language that only works on one provider’s infrastructure, migrating to another provider means reconstructing your entire privacy boundary from scratch.
Layer 4: Encryption and Key Management
The deepest layer. AWS KMS, Azure Key Vault, Google Cloud KMS. Each manages encryption keys with a different API, different key hierarchy, and different integration model. Data encrypted with a KMS-managed key is opaque without that KMS. The key metadata — rotation history, access policies, usage logs — lives exclusively within the provider’s infrastructure.
According to Thales’s 2025 Cloud Security Report, 62% of organizations store more than half of their sensitive cloud data encrypted with provider-managed keys. For these organizations, lock-in is not merely inconvenient — it is a cryptographic dependency. They cannot access their own data without the provider’s infrastructure.
The Compounding Effect
Privacy lock-in compounds. Each year of operation adds more data encrypted with provider-managed keys, more access policies in proprietary formats, more audit logs in proprietary stores, and more compliance workflows tied to provider-specific tools.
Consider a hypothetical organization five years into an AWS deployment:
- 5 petabytes of data encrypted with AWS KMS-managed keys
- 12,000 IAM policies defining access boundaries
- 7 years of CloudTrail audit logs (for compliance retention)
- 400+ Lambda functions with embedded AWS SDK calls
- Custom integrations with AWS Macie for PII detection, GuardDuty for threat detection, and Inspector for vulnerability scanning
This organization’s privacy infrastructure is AWS. Not “hosted on AWS.” Not “deployed to AWS.” The privacy logic — who can access what, how data is encrypted, how breaches are detected, how compliance is demonstrated — is implemented in AWS-specific primitives. Migration is not a lift-and-shift operation. It is a privacy architecture redesign.
The Flexera 2025 State of the Cloud report found that the average enterprise spends $4.2 million annually on cloud services it would need to re-architect to exit a primary provider. What Flexera did not quantify — and what is far more costly — is the privacy regression during migration: the period where audit continuity breaks, encryption key chains are re-established, and access policies are reconstructed in a new system while the old system is still operational.
Proprietary Encryption: The Deepest Trap
The encryption layer deserves extended analysis because it is where privacy lock-in becomes irreversible without deliberate architectural intervention.
How Provider-Managed Encryption Creates Dependency
When you encrypt data with AWS KMS using an AWS-managed key (the default for most services), the following dependency chain is created:
- AWS generates the data encryption key (DEK).
- AWS encrypts the DEK with a customer master key (CMK) that AWS manages.
- The encrypted DEK is stored alongside your data.
- To decrypt, your application calls KMS, which decrypts the DEK and returns it.
- KMS logs the decryption event in CloudTrail.
At no point in this chain does the customer possess the raw cryptographic key material. AWS holds it. AWS controls access to it. AWS can (under legal compulsion) provide access to it. The customer owns the data; the provider owns the ability to read it.
The BYOK Illusion
Bring Your Own Key (BYOK) is marketed as the solution to encryption lock-in. The customer generates a key, imports it to the cloud provider’s KMS, and uses it for encryption. The customer “owns” the key.
In practice, BYOK provides weaker guarantees than the marketing suggests. Once a key is imported into AWS KMS, Azure Key Vault, or Google Cloud KMS, the provider has a copy of the key material in their HSMs. The customer can delete the provider’s copy, but:
- Deletion is asynchronous and unverifiable. You cannot confirm that the key material has been purged from all HSM replicas, backup systems, and caches.
- Key material was in the provider’s infrastructure. For the period the key existed in KMS, it was accessible to the provider’s systems and subject to the provider’s legal jurisdiction.
- Audit logs remain. Every encryption and decryption operation is logged by the provider. Even after key deletion, the provider retains metadata about what data was encrypted with what key and who accessed it.
External key management (EKM) — where the cloud provider never possesses the key material — is a meaningful improvement. But EKM adoption is below 8% of encrypted cloud workloads, according to the 2025 Key Management Interoperability Protocol (KMIP) industry survey. The default path leads to dependency.
Data Portability: The Missing Standard
The European Union’s Data Act, effective September 2025, mandates that cloud providers enable data portability and prohibit contractual lock-in clauses. The regulation is a step forward, but it addresses data portability at the format and API level — ensuring that customers can extract their data. It does not address privacy portability: the ability to move not just data but the encryption context, access policies, and audit history that define the data’s privacy posture.
What Portable Privacy Requires
True privacy portability demands:
- Encryption key portability. Keys must be extractable and importable across providers without loss of key metadata, rotation history, or access policies.
- Policy portability. Access control policies must be expressible in a provider-neutral format and enforceable across different IAM systems.
- Audit continuity. Audit logs must span provider boundaries, providing a continuous chain of evidence for who accessed what data, regardless of where the data was hosted at the time.
- Compliance state transfer. Compliance certifications and assessment artifacts must transfer across providers without requiring a full re-assessment.
No current standard addresses all four requirements. KMIP handles key interoperability. XACML and Cedar (AWS’s open-source policy language) address policy portability. But no unified framework exists for portable privacy.
The Open Web Application Security Project (OWASP) published a draft Cloud Privacy Portability Framework in late 2025, proposing a JSON-based format for expressing encryption contexts, access policies, and audit references in a provider-neutral structure. It has not yet been adopted by any major provider.
The Incentive Misalignment
Cloud providers are not neutral on lock-in. Their business models depend on it. AWS’s annual revenue exceeded $107 billion in 2025. That revenue is secured not by the quality of individual services (which competitors can replicate) but by the switching costs that accumulate as customers build deeper into the proprietary stack.
This incentive misalignment extends to privacy features:
- AWS Macie detects PII in S3 buckets. It does not detect PII in Azure Blob Storage. If you use Macie for PII detection, your compliance workflow is AWS-specific.
- Azure Purview provides data governance and classification. It works best with Azure services, tolerates AWS and GCP data sources, and provides degraded functionality for on-premises data. Your classification taxonomy becomes Azure-dependent.
- Google Cloud DLP scans for sensitive data across Google services. Cross-cloud scanning is possible but requires additional configuration and incurs additional cost.
Each of these tools solves a real privacy need. Each also deepens the dependency that makes exit more complex and more privacy-destructive.
Case Study: The Migration Privacy Gap
In 2024, a European financial services firm migrated from AWS to a European sovereign cloud provider to achieve GDPR data residency compliance. The migration took 14 months and cost approximately EUR 8 million. The privacy gaps during migration were more significant than anticipated:
Encryption re-keying. All data encrypted with AWS KMS keys had to be decrypted and re-encrypted with the sovereign provider’s key management system. During the re-encryption window — which lasted three weeks for 2.3 petabytes of data — cleartext data existed on migration servers. This was a privacy regression that required legal review and DPA notification.
Audit log discontinuity. CloudTrail logs could not be imported into the sovereign provider’s audit system in a queryable format. The firm maintained a parallel CloudTrail archive for regulatory retention, creating a split audit trail that complicated compliance reviews.
IAM policy reconstruction. 3,800 IAM policies had to be manually translated from AWS IAM JSON to the sovereign provider’s RBAC model. The translation took four months and introduced 12 policy errors that granted broader access than intended — each a potential privacy violation.
PII detection gap. AWS Macie rules and custom patterns did not transfer. The sovereign provider used a different PII detection engine with different entity types and confidence scoring. During the four-month gap while PII detection was being rebuilt, the firm operated without automated sensitive data detection.
This case illustrates that cloud migration is a privacy event, not just an operational one. The migration itself introduces privacy risks that did not exist in the stable pre-migration state.
Architectural Countermeasures
Avoiding privacy lock-in requires deliberate architecture from day one. Retroactive mitigation is expensive and incomplete.
Strategy 1: Client-Side Encryption with External Keys
The single most effective countermeasure. If data is encrypted before it reaches the cloud provider, using keys managed outside the provider’s infrastructure, the encryption layer is portable by definition. The provider stores ciphertext. Moving ciphertext from one object store to another is a data transfer operation, not a cryptographic migration.
Cloud-native encryption with external key management eliminates the deepest layer of privacy lock-in. The data moves freely because it is opaque everywhere except in the client environment where the key resides.
Strategy 2: Policy as Code in Provider-Neutral Formats
Express access policies in a provider-neutral language — Cedar, Open Policy Agent Rego, or XACML — and use provider-specific adapters to translate them into native IAM formats. The canonical policy definition is portable. The provider-specific implementation is generated.
This requires discipline. It is faster and easier to write native AWS IAM policies directly. The portability tax is paid in additional abstraction layers and translation overhead. But the alternative — 12,000 AWS IAM policies that must be manually rewritten — is far more costly.
Strategy 3: Portable Audit Infrastructure
Run audit collection outside the cloud provider’s native tools. Observability platforms like OpenTelemetry provide a vendor-neutral telemetry collection framework. Audit events are captured in OpenTelemetry format, stored in a provider-neutral data store (or a customer-controlled store), and queryable without provider-specific tooling.
CloudTrail, Azure Monitor, and Google Cloud Audit Logs should feed into this portable audit layer as data sources, not serve as the primary audit store.
Strategy 4: PII Detection Decoupling
Run PII detection as a separate, provider-neutral layer rather than using provider-specific services. Open-source NER models (such as Microsoft Presidio or Stanford NER) can run in containers on any infrastructure. Your PII detection rules, entity types, and confidence thresholds are yours — not encoded in a provider’s proprietary service configuration.
The Stealth Cloud Perspective
Lock-in is not a bug in cloud computing. It is the business model. Every proprietary service, every managed database, every provider-specific encryption scheme is a deliberate design choice that increases switching costs and deepens dependency. This is rational behavior for cloud providers. It is not in the interest of users who value privacy autonomy.
Stealth Cloud is architected to be structurally resistant to provider lock-in. The privacy layer — PII stripping, client-side encryption, zero-persistence operation — runs in the client environment, outside any cloud provider’s boundary. The cloud infrastructure is a commodity transport layer for ciphertext. Switching from one provider to another changes where encrypted bytes are temporarily stored, not who can read them.
This is the key architectural insight: when the cloud provider never has cleartext access, lock-in becomes an operational concern rather than a privacy concern. You may still face egress costs, API migrations, and operational disruption when changing providers. But your privacy posture — the encryption, the access control, the audit trail — remains intact because it was never delegated to the provider in the first place.
The alternative — building privacy infrastructure on proprietary cloud primitives — is building on rented land. The architecture works until the landlord’s interests diverge from yours. When they do, you discover that your privacy is not a feature of your system. It is a feature of your contract. And contracts, unlike cryptography, can be reinterpreted.