When organizations move sensitive workloads to the cloud, encryption is usually treated as the hard problem. In reality, encryption is the easy part as every major cloud provider encrypts data at rest and in transit by default, and the algorithms involved are strong and well understood. The genuinely difficult question, the one that determines whether your data is actually under your control, is much simpler to state and much harder to answer: who controls the keys?
At the centre of the answer to “who controls the keys” sit two technologies: Hardware Security Modules (HSMs) and Key Management Services (KMS). Understanding what each one does, how they differ, and how they work together is the foundation of both cloud data security. This blog explains both technologies, the key custody models built on top of them, and why they have become the deciding factors in whether an organization truly controls its data in the cloud.
Who Controls the Keys?
Encryption transforms readable data into ciphertext that is meaningless without the corresponding key. This means that in any encrypted system, the data is only as protected as the key that unlocks it. Whoever controls the key controls the data. If an attacker obtains the key, the encryption provides no protection. If a third party such as a cloud provider or a government with legal authority over that provider can compel access to the key, then that third party can access the data, no matter how strong the encryption algorithm is or where the encrypted data physically resides.
The security of your data in the cloud is not primarily a question of how strong the encryption is. It is a question of who holds and controls the keys, and under what circumstances those keys can be used or compelled.
Cloud providers have always offered encryption. What has changed is the recognition that provider-managed encryption, where the provider generates, stores, and controls the keys, means the provider, and anyone with legal authority over the provider, can technically access the data. For many workloads this is an acceptable risk. But it is increasingly not for regulated data, sensitive intellectual property, government information, or anything subject to cross-border legal complexity.
HSMs and KMS are the two technologies that let organizations answer the key control question on their own terms rather than the provider’s. They are related, often used together, and frequently confused. The distinction between them matters enormously for security architecture and for sovereignty.
Comparing HSM and KMS Architecture
To understand how key control actually works in the cloud, you need a clear picture of both technologies, what each one does, and how they relate to each other.
Hardware Security Module (HSM)
A Hardware Security Module is specialized, tamper-resistant hardware designed to do one thing exceptionally well: generate, store, and use cryptographic keys inside a physically and logically protected boundary, so that the private key material never exists in plaintext outside that boundary.
When a cryptographic operation is performed using an HSM, such as signing data or decrypting a value, the operation happens inside the HSM. The data or its hash is sent in, the HSM performs the operation internally using the key that lives inside it, and only the result comes back out. This is the core value of an HSM: even if every surrounding system is compromised, the key remains protected inside the module.
The tradeoff for these guarantees is operational complexity and cost. Dedicated cloud HSM clusters can exceed $1,000 per month per HSM, and managing HSM infrastructure, including redundancy, backup, and the risk that a lost administrative quorum can cause a permanent lockout, requires specialized expertise.
Key Management Service (KMS)
A Key Management Service is a software-driven service that handles the full lifecycle of cryptographic keys: generation, storage, rotation, access control, usage policies, and retirement. Cloud-native examples include AWS KMS, Azure Key Vault, and Google Cloud KMS. Their defining strength is scalability and ease of integration. A developer can encrypt data with a few API calls, and the KMS handles key storage, rotation schedules, and integration with other cloud services automatically.
The crucial distinction is this: an HSM is fundamentally about hardware-enforced protection of keys, while a KMS is fundamentally about scalable lifecycle management of keys. They are not competing alternatives so much as complementary layers. Modern cloud KMS offerings are typically backed by HSMs under the hood. AWS KMS performs its operations inside FIPS 140-3 Level 3 validated HSMs. Google Cloud KMS offers a Cloud HSM backend that ensures keys are used only in FIPS 140-2 Level 3 validated hardware. Azure Key Vault offers Managed HSM as a fully isolated, standards-compliant HSM pool.
How Do They Differ?
The two technologies serve different primary purposes and understanding where each fits helps clarify when to use one, the other, or both.
| Dimension | Hardware Security Module (HSM) | Key Management Service (KMS) |
|---|---|---|
| Primary purpose | Hardware-enforced key protection | Scalable key lifecycle management |
| Core strength | Tamper-resistant trust boundary | Automation, integration, policy at scale |
| Tenancy | Often single-tenant dedicated hardware | Typically multi-tenant service |
| Key isolation | Keys never leave the hardware | Keys managed within provider infrastructure |
| Operational overhead | High; requires specialized expertise | Low; deploy in minutes |
| Typical cost model | Per HSM | Per key and per request |
| Best fit | Highest-assurance, regulated, sovereign workloads | General-purpose encryption across cloud services |
| Sovereignty role | Enforces that provider cannot access raw keys | Expresses control policies and audit |
Key Custody Models
The real determinant of sovereignty is not simply whether you use an HSM or a KMS, but which key custody model you adopt. These models define who generates the keys, where they live, and critically, whether the cloud provider has any technical ability to access them. The industry uses a set of terms for these models, and while the exact definitions vary somewhat between vendors, the spectrum is clear.
Provider-Managed Keys (PMK): The cloud provider generates, stores, uses, rotates, and backs up the keys entirely within its own infrastructure. This is the default for most cloud encryption. It is operationally simple and requires no customer effort, but the provider has full technical access to the keys and therefore to the data. For sovereignty purposes, this model offers the least control.
Bring Your Own Key (BYOK): The customer generates the key material externally, often in their own HSM, and then securely imports it into the cloud provider’s KMS. This gives the customer tighter control over key creation and lifecycle policy and establishes the customer as the root of trust. However, there is an important limitation: once the key is imported into the provider’s KMS, it resides in the provider’s infrastructure. The provider retains the technical capability to use the key, and law enforcement can potentially compel the provider to use it. BYOK improves control over key creation and rotation but does not by itself remove the provider’s technical access.
Hold Your Own Key (HYOK): The customer maintains the keys entirely within their own key management infrastructure, typically an HSM under their direct control, and never transfers the key material into the provider’s environment. When a cloud workload needs to encrypt or decrypt data, it sends a request to the customer’s key infrastructure rather than using a provider-held key. The encryption keys never enter the provider’s environment, and the provider has no technical ability to access them. This is the model that delivers the strongest sovereignty guarantee, because there is no key for the provider to be compelled to use.
External Key Store (XKS) and External Key Manager (EKM): Cloud providers have built features specifically to support HYOK-style architectures. AWS External Key Store, Google Cloud External Key Manager, and equivalent offerings allow cryptographic operations to be performed using keys held outside the cloud provider’s infrastructure entirely. These features are the technical bridge that makes HYOK practical at cloud scale.
How Encryption Consulting Can Help
Cloud data security and sovereignty sit precisely at the intersection of encryption strategy, key management architecture, and regulatory compliance, which is the core of Encryption Consulting’s expertise.
Our Encryption Advisory Services help organizations design and implement the key management architecture that genuine cloud sovereignty requires. We begin by assessing your current encryption and key custody posture, identifying exactly where the gap between data residency and true sovereignty sits in your environment.
Because the 2026 regulatory landscape including the EU Data Act, DORA, NIS2, and the EU Cloud Sovereignty Framework increasingly demands verifiable technical control over cryptographic keys, our advisory engagements also focus on producing the documented evidence, from key management architecture diagrams to data flow documentation, that regulators and procurement frameworks now require rather than accepting at face value.
For organizations that need the assurance of hardware-protected keys without the burden of building and operating that infrastructure themselves, our HSM as a Service offering provides a high-assurance, FIPS 140-2 Level 3 and PCI HSM approved solution that can be deployed on-premises, in the cloud, or in a hybrid model.
We are vendor-agnostic, working across HSMs from Thales, Entrust, and the major cloud providers, so the architecture is shaped around your requirements rather than a single product line. Crucially for sovereignty, the service is designed so that you maintain complete control over your key material and audit trails at all times, with the keys never exposed to the software layer or to unauthorized users.
Encryption Consulting can fully offload the HSM environment, taking responsibility for provisioning, configuration, patching, and ongoing management, or simply assist where your team needs support, depending on whether you require a dedicated or fully managed model.
Conclusion
Cloud security ultimately comes down on deciding who has the control of the keys and where to put in your trust. Encryption is necessary, but it is the key custody architecture built on HSMs and KMS that determines whether your data is genuinely under your control or merely sitting in a data centre while someone else holds the means to unlock it.
The distinction between the two technologies is foundational. HSMs provide hardware-enforced protection that ensures keys never leave a tamper-resistant boundary and that the cloud provider has no technical path to the raw key material. KMS provides the scalable lifecycle management, policy enforcement, and audit that make key management practical at cloud scale. Together, layered correctly, they convert the abstract goal of data sovereignty into an enforceable technical reality.
At Encryption Consulting, our advisory services and product portfolio are built to help organizations design and implement the key management architecture that real cloud data security and sovereignty require. If you are working through your cloud key control strategy, we would be glad to help.
