KMS vs HSM: The Difference Between a Key Management Service and a Hardware Security Module

If you use AWS KMS, your security keys already live inside hardware security modules. AWS states that keys created in the service are protected by FIPS 140-3 Security Level 3 validated HSMs. However, choosing between a standalone key management service (KMS) and a dedicated hardware security module (HSM) is a critical decision in cryptographic security architecture. The choice directly impacts operating costs, compliance posture, and who ultimately retains control over encryption keys, as a managed KMS often runs on the very devices it is being compared against.

KMS vs HSM: The Short Answer

So what is the difference between the two? 

A hardware security module (HSM) is a tamper-resistant physical device that generates, stores, and uses cryptographic keys so they never leave it in plaintext. 

A key management service (KMS) is the layer that manages keys across their lifecycle, deciding who can use them, when they rotate, and how every use is logged, and most production KMS setups run on HSMs underneath.

An HSM Keeps Keys Inside Dedicated Hardware

An HSM is a dedicated cryptographic device, sold as a network appliance, a card that plugs into a server, or a hosted cloud service. It generates keys from its own hardware randomness, performs encryption and signing internally, and returns only the results. If someone tries to open the device or tamper with it physically, it detects the attempt and erases its keys. 

A cloud HSM is a dedicated, single-tenant HSM hosted in a provider's data center, such as AWS CloudHSM: you manage the keys and cryptographic configuration, while the provider maintains the hardware and facility, which removes the racking and upkeep of an on-premises appliance.

HSMs are validated against FIPS 140-3, the standard run by NIST's Cryptographic Module Validation Program. It defines four security levels, and Level 3 requires tamper detection and response plus identity-based authentication, which makes it the level typically associated with HSMs. On September 21, 2026, NIST moved every remaining FIPS 140-2 certificate to its historical list, so FIPS 140-3 is now the validation to check for in any new purchase.

We break down HSMs alongside TPMs, secure elements, and TEEs in our post on the hardware behind SpaceComputer satellites.

Most Key Management Services Run on HSMs

While an HSM excels at safeguarding keys and executing cryptographic functions, it lacks built-in capabilities to enforce application access policies, automate key rotation, or integrate across modern application ecosystems. A KMS provides this orchestration layer, handling access controls, rotation schedules, audit logging, and developer-friendly APIs, while relying on the underlying HSM for core cryptographic execution.

Tenancy is the primary practical distinction between these architectures. Managed KMS environments typically leverage shared HSM infrastructure with logical isolation per customer, whereas dedicated HSMs serve a single tenant. AWS illustrates this model by employing multi-tenant HSMs for AWS KMS, while reserving AWS CloudHSM as a single-tenant offering to satisfy specialized compliance, cryptographic, or application requirements.

KMS vs HSM Comparison

There are substantial variances in cost as well. On AWS, KMS pricing is set at $1 monthly per key alongside $0.03 for every 10,000 requests, whereas CloudHSM runs approximately $1.60 hourly, totalling around $1,152 monthly per instance, excluding operational labor. According to AWS estimates, KMS generally delivers 35% to 99% savings for workloads under 500 million monthly operations.

When To Choose an HSM, a KMS, or Both

• A dedicated HSM fits when a regulation or contract requires dedicated validated hardware, when you're protecting certificate authority root keys or payment systems, or when your software expects a traditional HSM interface.
• A managed KMS fits most application encryption, especially for teams that don't have the staff to operate HSMs.
• Both together is common in mature setups. AWS, for example, lets KMS keys be generated and stored in a customer's own CloudHSM cluster, so the KMS handles policy and integration while the customer controls the hardware.

5 questions to help you make the decision:

Most application encryption lands on a managed KMS, and running both together is common in mature setups. AWS, for example, lets KMS keys be generated and stored in a customer's own CloudHSM cluster, so the KMS handles policy and integration while the customer controls the hardware.

For many organizations, the bigger risk is encrypting nothing at all. IBM's 2026 Cost of a Data Breach Report found that 53% of breached organizations hadn't encrypted sensitive data at rest and in transit at the time of the incident.

Where TEEs and Secure Elements Fit

HSMs are one rung on a wider ladder of key protection. A key in a software file or in application memory is the weakest option, readable by anyone who compromises the operating system. A Trusted Platform Module (TPM) raises the cost of extraction, an HSM keeps keys inside dedicated tamper-resistant hardware, and a secure element delivers similar guarantees in a chip small enough for payment cards, phones, and satellites.

A trusted execution environment (TEE) takes a different approach: it isolates code and data inside the processor itself, so the host operating system can't read what runs inside, and remote attestation lets an outside party verify what's running. We explain how secure elements generate signing keys on our satellites after launch in What Is a Signing Key?

SpaceComputer's Key Management Service

Our Key Management Service will be live soon. Key operations run inside hardware-isolated environments, either Intel TDX TEEs or an HSM, as our CTO Filip Rezabek describes in Secure Key Management Services Beyond the Cloud. Keys are non-exportable by design, so applications use them without ever receiving them.

Frequently Asked Questions

Is AWS KMS an HSM?
No. AWS KMS is a managed key management service, and the keys inside it are protected by FIPS 140-3 Level 3 validated HSMs that AWS operates. Teams that need a dedicated, single-tenant HSM use AWS CloudHSM instead.

Do I need a dedicated HSM for compliance?
It depends on the requirement. Some standards and contracts call for dedicated validated hardware, while many accept a managed KMS backed by validated HSMs, so check the exact control your auditor is testing against.

What is FIPS 140-3?
It's the U.S. and Canadian standard for validating cryptographic modules, with four security levels. After September 21, 2026, NIST moved all remaining FIPS 140-2 certificates to its historical list, leaving FIPS 140-3 as the current validation for new systems.

Can a key ever leave an HSM?
HSMs can be configured so private keys never leave the device in plaintext. Many support encrypted backups that can only be restored into another HSM, so keys survive a hardware failure without ever being readable outside protected hardware.

SpaceComputer is the open, credibly neutral infrastructure layer that connects the space economy, providing the hardware and software standard for verifiable compute across operators, jurisdictions, and satellites, with high security guarantees and verifiability.

We turn space from something you integrate mission by mission into infrastructure you can reuse: shared hardware lowers cost, Space Fabric makes workloads portable, and common services make deployment across missions seamless.

Visit our documentation to learn more about our Key Management Service.
Follow us on X (Twitter) and LinkedIn.