Encryption Key Management: The Cloud Migration Bottleneck

Cloud migration projects stall for plenty of reasons, legacy dependencies, network latency, data residency rules. But one blocker that doesn't get enough attention is encryption key management. More specifically, the question of who controls the keys once data moves off-premises. For security teams, that question can hold up a migration for months.

The problem is structural. Most cloud providers encrypt data at rest by default, but they also hold the keys. For organisations in regulated sectors, financial services, healthcare, legal, handing over that control isn't just uncomfortable, it may not be permitted. That's where models like BYOK and HSM-backed key storage become relevant, and where the architecture decisions get complicated.

BYOK: What It Actually Means in Practice

Bring Your Own Key (BYOK) sounds simple in principle: you generate your own encryption keys and supply them to the cloud provider. In practice, the degree of control this gives you varies significantly depending on the provider's implementation.

In some BYOK setups, you generate a key locally and then wrap it using a Key Exchange Key provided by the cloud service before uploading it. Once imported, the provider unwraps it within their HSM, meaning their infrastructure handles the key material during cryptographic operations. If the provider controls the root of the key hierarchy, they can technically access your data if compelled to.

HSM-Backed Keys and Where They Fit

A Hardware Security Module (HSM) is a dedicated physical device that generates, stores, and processes cryptographic keys in tamper-resistant hardware. The key point is that private keys created inside an HSM typically cannot be extracted from it, operations happen within the module, not in software memory where they'd be exposed.

Cloud providers offer HSM-backed key management services, and some allow you to bring your own HSM or use a cloud HSM that you provision and control exclusively. AWS CloudHSM and Azure Cloud HSM (the successor to the now-retiring Azure Dedicated HSM) are examples of this pattern. The tradeoff is cost and operational overhead, these aren't set-and-forget services. But for high-assurance workloads, the added rigidity is the point.

Client-Side Encryption and the Zero-Knowledge Model

Both BYOK and HSM-backed keys still involve the provider handling encrypted data on infrastructure they operate. Client-side encryption takes a different position: data is encrypted on the client before it ever reaches the provider's infrastructure. The provider stores ciphertext and nothing else.

This is the model being evaluated in categories like enterprise cloud storage, where end-to-end client-side encryption means the storage provider has no technical means to access file contents.

For organisations where the threat model includes the provider itself, or a legal request served to the provider, this architecture removes that attack surface entirely. It also simplifies certain compliance arguments, since you're no longer relying on contractual assurances about what a provider will or won't do with your keys.

What Client-Side Encryption Changes for Your Security Model

The practical consequence of client-side encryption is that key management moves entirely to your side. There's no provider fallback if you lose access to your keys, and there's no admin portal you can call to recover data.

That raises the stakes for key rotation policies, access controls, and backup procedures. If those aren't mature, client-side encryption can create new risks while solving old ones.

What to Audit Before You Choose a Key Management Model

Before committing to an architecture, it's worth working through a few key questions:

• Does the provider control any part of your key hierarchy, including root or wrapping keys?
• Can you revoke keys immediately, and what happens to existing data when you do?
• Are keys generated and stored in FIPS 140-3 validated hardware? (Note that FIPS 140-2 certificates will be retired in September 2026, so new deployments should target FIPS 140-3 compliance.)
• Does the architecture survive a provider breach, insider threat, or government request?
• What are the operational requirements for key rotation, and who owns that process?

The answers will point you towards the right model. BYOK with a provider-managed root may be sufficient for lower-sensitivity workloads. Full client-side encryption with HSM-backed key storage is a stronger position for anything where the provider must be treated as untrusted.

Final Thoughts

Encryption key management is where cloud security architecture gets specific fast. Vague commitments to encryption at rest don't tell you who holds the keys or under what conditions they could be used. That detail matters, and it's worth getting it resolved before migration rather than after.

For most organisations, the right model will sit somewhere between full provider-managed keys and a zero-knowledge architecture. Getting there means understanding the trust assumptions baked into each option, and being honest about which ones your threat model can actually tolerate.