On-premises HSM, HSM Cloud, and KMS address different needs for cryptographic key protection and management.
The choice depends on factors such as control over the hardware, security and compliance requirements, application architecture, integration with existing systems, scalability, and operational responsibility. In many mission-critical environments, these technologies can even be combined.
As banks, fintech companies, payment institutions, and other organizations expand their operations into the cloud and hybrid environments, an important decision arises: where should cryptographic keys be stored, and how can their lifecycle be securely managed?
There is no one-size-fits-all answer. A physical HSM installed in a data center offers a different control model than a cloud-based HSM. A KMS, on the other hand, adds a management layer that can simplify policies, permissions, and operations involving large volumes of keys.
Therefore, the answer should not be based simply on a comparison of the three technologies. The first step is to understand the role of each one and your organization’s needs!
What is on-premises HSM?
An on-premises HSM (Hardware Security Module) is a cryptographic device installed and operated within the organization's own controlled infrastructure.
Its function is to protect cryptographic keys and perform sensitive operations in an environment specifically designed for that purpose.
Depending on the hardware and its configuration, sensitive data can remain protected within the HSM's cryptographic boundary while applications request operations such as signing, encryption, or decryption.
This model offers a high level of control over aspects such as:
- Physical location of the equipment;
- HSM Administration and Policies;
- Initialization and custody procedures;
- Backup and recovery;
- Connectivity;
- Segregation of duties;
- Infrastructure updates and maintenance.
When does an on-premises HSM make sense?
It tends to be considered when there are internal, contractual, technical, or regulatory requirements that call for greater control over the cryptographic infrastructure, or when existing applications were developed for traditional HSM interfaces.
This scenario is commonly found in financial infrastructures, PKIs, digital signature systems, payment processing, and other highly critical operations.
The benefits of control, however, come with responsibility. High availability, redundancy, disaster recovery, updates, monitoring, and maintenance must all be part of the project.
What is HSM Cloud?
HSM Cloud moves the physical infrastructure of the cryptographic module to a cloud environment, while continuing to use specialized hardware to protect the keys.
Depending on the service purchased, there may be different models for isolation, administration, and liability. Therefore, it is incorrect to assume that all cloud-based HSMs work the same way.
Current solutions can offer dedicated capacity, administrative control by the customer, and traditional interfaces used by applications originally developed for physical HSMs.
When should you consider a cloud-based HSM?
This model may be useful when the company:
- It is migrating critical applications to the cloud;
- You must maintain hardware-based key protection;
- Do you want to reduce the amount of in-house physical infrastructure management?;
- Requires interfaces compatible with applications that access the HSM directly;
- You need to balance security requirements with a cloud or hybrid architecture.
Even so, the decision to migrate should not be based solely on operational convenience. It is necessary to evaluate latency, availability, connectivity, key sovereignty, the accountability model, certifications, supported interfaces, and business continuity requirements.
What is KMS, and how does it differ from HSM?
The KMS (Key Management System or Key Management Service) focuses on managing cryptographic keys throughout their lifecycle.
Depending on the solution, you can centralize activities such as:
- Generation and storage;
- Policy-making;
- Granting and revoking access;
- Rotation;
- Enabling and disabling;
- Monitoring;
- Audit;
- Integration with applications and services.
There is an important distinction here: using a KMS does not necessarily mean doing without an HSM.
There are KMS services in which certain keys are protected by HSMs. There are also architectures in which a key management system uses external or dedicated HSMs as the root of trust.
In summary, what is the difference between on-premises HSM, Cloud HSM, and KMS?
To put it simply:
| Technology | Key feature | Recommended when |
| On-premises HSM | Cryptographic hardware installed within the organization's own infrastructure | Greater control over the equipment and its operation is needed |
| HSM Cloud | HSM Capacity Available in Cloud Infrastructure | The organization needs hardware-based protection without having to host the equipment in its own data center |
| KMS | A service or system designed to manage the lifecycle of keys | It is necessary to centralize policies, access, rotation, use, and auditing of keys |
An important point is that KMS and HSM are not necessarily mutually exclusive alternatives.
A KMS can use HSMs as a layer of protection for cryptographic material. Therefore, the decision must take into account the entire architecture, not just where the key will be stored.
HSM Cloud or KMS: Are They Competitors?
Not necessarily. This is one of the most important points to keep in mind to avoid a technically simplistic comparison.
HSM focuses on the protection and secure execution of cryptographic operations on specialized hardware. KMS focuses on the management of keys, policies, and their lifecycle.
Depending on the solution chosen, these functions may be integrated into a single service or distributed across different components.
The most appropriate question, therefore, is not simply “HSM or KMS?”, but rather:
Which architecture provides the level of protection, control, governance, and integration required for the keys used by the organization?
How do you choose between on-premises HSM, Cloud HSM, and KMS?
For critical environments, the decision must be based on clearly documented technical and business requirements.
1. Assess the criticality of the keys
Not all keys have the same impact.
A key used for a critical financial transaction may require controls different from those applied to the encryption of data in an internal application.
Classifying assets helps determine which keys require hardware-based protection and which access and segregation policies should be adopted.
2. Identify the compliance requirements
Certifications and regulatory requirements must be evaluated for the specific solution and use case, and should not be assumed simply because a particular product is classified as an HSM.
Providers offer services with varying levels of certification, isolation, sovereignty, and administrative accountability.
3. Analyze the interfaces required by the applications
Existing applications may rely on standards such as PKCS#11, JCE/JCA, OpenSSL, or other specific interfaces.
This aspect is particularly important when migrating legacy systems to the cloud. Not every KMS offers the same interfaces as a traditional HSM.
4. Consider availability and recovery
Cryptographic protection must also be analyzed from the perspective of continuity.
If an application cannot access the required key, a cryptographically secure infrastructure may become operationally unavailable.
Therefore, the architecture must take into account redundancy, backup, recovery, contingency planning, and procedures for component failures.
5. Compare control and operational responsibility
The greater the control over the infrastructure, the greater the organization's responsibility for its management tends to be.
With on-premises HSM, much of this responsibility remains in-house. With managed services, certain activities may fall under the provider’s responsibility. Between these two extremes, there are various Cloud HSM and KMS models.
Is it possible to combine on-premises HSM, HSM Cloud, and KMS?
Yes. For organizations with multiple applications, hybrid environments, or different levels of criticality, a hybrid architecture may be more appropriate than standardizing all cryptographic management on a single technology.
For example, an organization can keep certain critical keys secure in an HSM, use cloud services for other workloads, and adopt a management layer capable of centralizing controls.
This approach requires attention to governance: it is important to know which keys exist, where they are located, who can use them, which applications depend on them, and how each asset will be rotated, revoked, recovered, and audited.
How does PRODIST integrate different key protection models?
PRODIST develops solutions for institutions that need to use encryption in critical processes, including integrations with BACEN and NÚCLEA systems.
PRODIST STS allows you to work with different key protection strategies, including:
- PRODIST STS's own KMS;
- HSMs from approved partners;
- Vaults;
- Cloud-based KMS;
- On-premises or cloud architectures.
The proposal, therefore, is not to choose a single cryptographic infrastructure, but to integrate the solution with security requirements and the existing architecture.
For BACEN and NÚCLEA systems based on the SFN security protocol, PRODIST STS also performs activities related to the packaging and validation of messages and files, including the cryptographic processes necessary to protect these packets.
Thus, the organization can structure key protection in accordance with its technology strategy without separating that decision from the applications and processes that actually depend on those assets.
PRODIST: Expertise in Cryptography for Critical Financial Operations
Choosing between on-premises HSM, HSM Cloud, and KMS requires more than just comparing features. It is necessary to understand applications, security requirements, integrations, key governance, and operational continuity.
PRODIST has been operating in the Brazilian market since 1987 and has had solutions in operation within the National Financial System since the SPB’s inception in 2002. Its operations combine proprietary technology, expertise in cryptography, and knowledge of the integrations used by financial institutions.
In addition to implementation, PRODIST monitors projects from design through production operations, providing ongoing maintenance and specialized technical support.
For banks, fintech companies, credit unions, acquirers, sub-acquirers, and other organizations that rely on crypto assets, this experience allows them to evaluate the technology within the real-world context of their operations.
Do you need to define or modernize your institution’s cryptographic key protection architecture? Contact PRODIST to learn about integration options with HSMs, KMS, and cloud environments.
FAQ – On-Premises HSM, Cloud HSM, and KMS
On-premises HSM uses cryptographic hardware within the organization's infrastructure; Cloud HSM provides HSM capabilities in the cloud; and KMS focuses on managing the lifecycle and usage policies of keys.
No. HSM Cloud refers to the provision of HSMs in a cloud infrastructure. KMS is a key management system or service and, depending on the solution, may use HSMs to protect keys.
Not necessarily. HSMs and KMSs serve different purposes and can be used together, especially when an organization needs to combine hardware-based protection with centralized key management.
On-premises HSM is recommended when an organization needs a high degree of control over the hardware, its management, location, and operation, or when it has applications and requirements that are compatible with this model.
HSM Cloud may be suitable for cloud or hybrid applications that require hardware-based cryptographic protection without having to physically house the HSM in the company's data center.
KMS is recommended when it is necessary to centralize the management of keys, access policies, key rotation, permissions, auditing, and integration with various applications.
Yes. Hybrid architectures can combine different protection and management mechanisms depending on the criticality of the keys, the systems used, and the organization's requirements.
Yes. PRODIST STS has its own KMS and supports integration with HSMs from certified partners, as well as cloud-based vaults and KMS, allowing key protection to be tailored to the institution’s architecture.
