How Hardware Keeps Key Generation, Storage, and Cryptographic Operations Inside a Secure Boundary
Part 1 of our Beyond the Algorithm series, "PQC Migration Isn't Just an Algorithm Swap," explained why replacing an algorithm is only one part of PQC migration. Organizations must also decide where cryptographic keys are generated and how they are protected.
In this article, we look at one of the foundations of key management: what an HSM (Hardware Security Module) is and how it differs from handling keys directly on an application server.
A Vault and a Wallet: Same Cash, Different Levels of Protection
The same amount of cash can face very different levels of risk depending on where it is kept.
Keep it in a wallet and it is always within reach—but lose the wallet, and the cash goes with it. Store it in a bank vault, and accessing it takes a few extra steps. Those safeguards, however, also make it far more difficult for anyone else to reach. The money is the same, but the way it is stored changes the risk of theft.
Cryptographic keys work in much the same way. Handling a key directly in an application server's files or memory is like carrying cash in a wallet: if the server is compromised, the key may be exposed to the same risk.
Generating and using a key within a separate hardware boundary, while returning only the result of the cryptographic operation to the application, is closer to keeping cash in a bank vault. An HSM is the dedicated hardware that provides this protection.
What an HSM Actually Is
According to NIST's definition, an HSM is a physical computing device that safeguards and manages cryptographic keys while also providing cryptographic processing.
Put simply, an HSM serves as both a vault for cryptographic keys and an engine that uses those keys to perform cryptographic operations. Its role can be understood through two main characteristics.
First, an HSM can be configured so that protected keys never leave the device in plaintext. Encryption, decryption, and digital signing take place inside the HSM, while the application receives only the result of the operation—not the key itself. When a key needs to be backed up or transferred to another device, it is typically protected in encrypted or wrapped form.
Second, an HSM may include protection against physical attacks. Higher-assurance HSMs are designed to detect or resist attempts to open or tamper with the device and, under defined conditions, zeroize sensitive key material.
These security properties are not based solely on vendor claims. Standards such as FIPS 140-3 classify cryptographic modules into four security levels and evaluate far more than physical security alone. The assessment covers areas including interfaces, roles and authentication, software and firmware security, sensitive security parameter management, and self-tests.
Not every HSM provides the same level of tamper detection, resistance, or zeroization. Organizations should therefore check not only whether a product has been validated, but also its security level and the exact scope of that validation.
The Risks of Handling Keys in Software: What Heartbleed Revealed
The case for using an HSM becomes clearer when we look at what can happen when keys are handled directly in application memory.
Heartbleed, a vulnerability discovered in OpenSSL in 2014, allowed an attacker to remotely read portions of a server's memory. That memory could contain more than user credentials and application data—it could also expose TLS private key material.
Cloudflare tested this risk through a public challenge. Participants were able to reconstruct the server's RSA private key by repeatedly collecting and analyzing leaked memory fragments. Cloudflare's results demonstrated that an application-memory disclosure vulnerability could result in the compromise of a private key.
Not every server vulnerability leads directly to key compromise. But when a plaintext key is present in application memory, a memory-disclosure vulnerability may expose that key as well.
If the key is configured for use only inside an HSM, compromising the application server's memory does not directly expose the plaintext key. The security boundary protecting the key has been moved away from the application server and into dedicated hardware.
What Risks Does an HSM Reduce?
img source: gettyimagesbank.com
An HSM can meaningfully reduce several key security risks.
Key Exposure Through Server Memory
When a key is configured for use only inside an HSM, compromising the application server's memory does not directly expose the plaintext key.
Physical Theft and Tampering
Higher-assurance HSMs are designed to detect or resist attempts to open or tamper with the device. Under defined conditions, they may also zeroize sensitive key material.
Unauthorized Copying by Insiders
Generating keys as non-exportable objects, combined with appropriate separation of roles and permissions, makes it difficult for even a system administrator to view or copy key material directly. Requiring multi-party approval for sensitive operations can further reduce the risk created by concentrating too much authority in one person.
An HSM does not solve every security problem, however. If access policies are misconfigured or an authorized application credential is compromised, an attacker may be unable to extract the key but could still instruct the HSM to perform encryption or signing operations.
HSM deployment must therefore be supported by operational controls such as least privilege, separation of duties, multi-party approval, API access controls, and audit logging. An HSM creates a strong hardware boundary around cryptographic keys, but organizations must still control who can access its services and for what purpose.
Why HSMs Still Matter in the PQC Era
Migrating to PQC algorithms can be accomplished in large part through software and protocol updates. But deciding where the new keys are generated, how they are stored, and how they are protected during cryptographic operations remains a separate design challenge.
During the transition, legacy RSA and ECC keys are likely to coexist with new ML-KEM and ML-DSA keys. Organizations will need to track the purpose, validity period, and access rights associated with each algorithm and key, while retaining the ability to replace them securely when necessary.
Putting NIST's crypto agility guidance into practice requires organizations to understand where their algorithms, keys, and certificates are used, what purposes they serve, and how they can be replaced when security requirements change. An HSM can provide a foundation for generating, separating, and operating multiple generations of keys according to consistent policies.
An existing HSM, however, does not automatically support new PQC algorithms. A migration plan should therefore consider algorithm support, firmware upgrade options, API compatibility, processing performance, and the scope of relevant validations.
Algorithms may change, but the need to generate and protect cryptographic keys remains. That is why HSMs continue to matter in the PQC era.
Wrapping Up
An HSM is more than a hardware vault for storing cryptographic keys. It performs cryptographic operations within the device itself, reducing the need to expose plaintext keys to an application server.
As Heartbleed demonstrated, a key held in application memory may be exposed by a memory-disclosure vulnerability. Keeping the key within a separate hardware boundary makes it far more difficult for an attacker to obtain the plaintext key directly, even if the application server is compromised.
Moving to PQC algorithms does not eliminate the need for this boundary. During a transition in which legacy cryptography and PQC coexist, the role of an HSM in managing and protecting different types of keys under consistent policies may become even more important.
Frequently Asked Questions
How Is an HSM Different from a KMS?
A KMS (Key Management System or Key Management Service) is a system or service for managing the lifecycle of cryptographic keys, including their generation, storage, rotation, revocation, and destruction, as well as the permissions governing their use. An HSM is a physical security device that protects keys and performs cryptographic operations.
A KMS may use an HSM as its security foundation. The two are therefore not direct substitutes: one provides the broader key management framework, while the other provides hardware-based protection and cryptographic processing. In a software-only implementation, depending on its architecture, plaintext key material may be exposed in server memory during cryptographic operations.
Why Does FIPS 140-3 Validation Matter?
It allows organizations to assess a cryptographic module's security claims against a recognized standard instead of relying solely on the vendor's claims.
FIPS 140-3 evaluates far more than physical security. It covers areas including interfaces, roles and authentication, software and firmware security, sensitive security parameter management, and self-tests. When comparing products, organizations should check not only whether a module has been validated, but also its security level and the scope of the validation.
Does Deploying an HSM Make Key Management Completely Secure?
No. An HSM reduces the risk of key exposure, but it does not automatically correct misconfigured access policies, overly broad API permissions, or compromised credentials.
If an attacker obtains a legitimate account and its permissions, the attacker may be able to instruct the HSM to perform cryptographic operations without extracting the key itself. Operational controls—including least privilege, separation of duties, multi-party approval, and audit logging—must therefore be applied alongside the HSM.
Why Do HSMs Still Matter After Migrating to PQC?
Because the fundamental requirements remain unchanged: cryptographic keys must still be generated securely, stored safely, and protected from exposure during cryptographic operations, whether they are used with RSA, ECC, ML-KEM, or ML-DSA.
During the period when legacy cryptography and PQC coexist, a management foundation capable of separating and rotating different algorithms and keys according to policy becomes even more important. Not every HSM supports PQC, however, so organizations must verify algorithm support, performance, compatibility, and validation scope.
References
Check It Out
Curious how VIA PUF™-based hardware Key Management actually works in practice? Take a look at ICTK's security module lineup.
☑️ Explore ICTK Security Modules
☑️ Ask about qTrustHSM
How Hardware Keeps Key Generation, Storage, and Cryptographic Operations Inside a Secure Boundary
Part 1 of our Beyond the Algorithm series, "PQC Migration Isn't Just an Algorithm Swap," explained why replacing an algorithm is only one part of PQC migration. Organizations must also decide where cryptographic keys are generated and how they are protected.
In this article, we look at one of the foundations of key management: what an HSM (Hardware Security Module) is and how it differs from handling keys directly on an application server.
A Vault and a Wallet: Same Cash, Different Levels of Protection
The same amount of cash can face very different levels of risk depending on where it is kept.
Keep it in a wallet and it is always within reach—but lose the wallet, and the cash goes with it. Store it in a bank vault, and accessing it takes a few extra steps. Those safeguards, however, also make it far more difficult for anyone else to reach. The money is the same, but the way it is stored changes the risk of theft.
Cryptographic keys work in much the same way. Handling a key directly in an application server's files or memory is like carrying cash in a wallet: if the server is compromised, the key may be exposed to the same risk.
Generating and using a key within a separate hardware boundary, while returning only the result of the cryptographic operation to the application, is closer to keeping cash in a bank vault. An HSM is the dedicated hardware that provides this protection.
What an HSM Actually Is
According to NIST's definition, an HSM is a physical computing device that safeguards and manages cryptographic keys while also providing cryptographic processing.
Put simply, an HSM serves as both a vault for cryptographic keys and an engine that uses those keys to perform cryptographic operations. Its role can be understood through two main characteristics.
First, an HSM can be configured so that protected keys never leave the device in plaintext. Encryption, decryption, and digital signing take place inside the HSM, while the application receives only the result of the operation—not the key itself. When a key needs to be backed up or transferred to another device, it is typically protected in encrypted or wrapped form.
Second, an HSM may include protection against physical attacks. Higher-assurance HSMs are designed to detect or resist attempts to open or tamper with the device and, under defined conditions, zeroize sensitive key material.
These security properties are not based solely on vendor claims. Standards such as FIPS 140-3 classify cryptographic modules into four security levels and evaluate far more than physical security alone. The assessment covers areas including interfaces, roles and authentication, software and firmware security, sensitive security parameter management, and self-tests.
Not every HSM provides the same level of tamper detection, resistance, or zeroization. Organizations should therefore check not only whether a product has been validated, but also its security level and the exact scope of that validation.
The Risks of Handling Keys in Software: What Heartbleed Revealed
The case for using an HSM becomes clearer when we look at what can happen when keys are handled directly in application memory.
Heartbleed, a vulnerability discovered in OpenSSL in 2014, allowed an attacker to remotely read portions of a server's memory. That memory could contain more than user credentials and application data—it could also expose TLS private key material.
Cloudflare tested this risk through a public challenge. Participants were able to reconstruct the server's RSA private key by repeatedly collecting and analyzing leaked memory fragments. Cloudflare's results demonstrated that an application-memory disclosure vulnerability could result in the compromise of a private key.
Not every server vulnerability leads directly to key compromise. But when a plaintext key is present in application memory, a memory-disclosure vulnerability may expose that key as well.
If the key is configured for use only inside an HSM, compromising the application server's memory does not directly expose the plaintext key. The security boundary protecting the key has been moved away from the application server and into dedicated hardware.
What Risks Does an HSM Reduce?
img source: gettyimagesbank.com
An HSM can meaningfully reduce several key security risks.
Key Exposure Through Server Memory
When a key is configured for use only inside an HSM, compromising the application server's memory does not directly expose the plaintext key.
Physical Theft and Tampering
Higher-assurance HSMs are designed to detect or resist attempts to open or tamper with the device. Under defined conditions, they may also zeroize sensitive key material.
Unauthorized Copying by Insiders
Generating keys as non-exportable objects, combined with appropriate separation of roles and permissions, makes it difficult for even a system administrator to view or copy key material directly. Requiring multi-party approval for sensitive operations can further reduce the risk created by concentrating too much authority in one person.
An HSM does not solve every security problem, however. If access policies are misconfigured or an authorized application credential is compromised, an attacker may be unable to extract the key but could still instruct the HSM to perform encryption or signing operations.
HSM deployment must therefore be supported by operational controls such as least privilege, separation of duties, multi-party approval, API access controls, and audit logging. An HSM creates a strong hardware boundary around cryptographic keys, but organizations must still control who can access its services and for what purpose.
Why HSMs Still Matter in the PQC Era
Migrating to PQC algorithms can be accomplished in large part through software and protocol updates. But deciding where the new keys are generated, how they are stored, and how they are protected during cryptographic operations remains a separate design challenge.
During the transition, legacy RSA and ECC keys are likely to coexist with new ML-KEM and ML-DSA keys. Organizations will need to track the purpose, validity period, and access rights associated with each algorithm and key, while retaining the ability to replace them securely when necessary.
Putting NIST's crypto agility guidance into practice requires organizations to understand where their algorithms, keys, and certificates are used, what purposes they serve, and how they can be replaced when security requirements change. An HSM can provide a foundation for generating, separating, and operating multiple generations of keys according to consistent policies.
An existing HSM, however, does not automatically support new PQC algorithms. A migration plan should therefore consider algorithm support, firmware upgrade options, API compatibility, processing performance, and the scope of relevant validations.
Algorithms may change, but the need to generate and protect cryptographic keys remains. That is why HSMs continue to matter in the PQC era.
Wrapping Up
An HSM is more than a hardware vault for storing cryptographic keys. It performs cryptographic operations within the device itself, reducing the need to expose plaintext keys to an application server.
As Heartbleed demonstrated, a key held in application memory may be exposed by a memory-disclosure vulnerability. Keeping the key within a separate hardware boundary makes it far more difficult for an attacker to obtain the plaintext key directly, even if the application server is compromised.
Moving to PQC algorithms does not eliminate the need for this boundary. During a transition in which legacy cryptography and PQC coexist, the role of an HSM in managing and protecting different types of keys under consistent policies may become even more important.
Frequently Asked Questions
How Is an HSM Different from a KMS?
A KMS (Key Management System or Key Management Service) is a system or service for managing the lifecycle of cryptographic keys, including their generation, storage, rotation, revocation, and destruction, as well as the permissions governing their use. An HSM is a physical security device that protects keys and performs cryptographic operations.
A KMS may use an HSM as its security foundation. The two are therefore not direct substitutes: one provides the broader key management framework, while the other provides hardware-based protection and cryptographic processing. In a software-only implementation, depending on its architecture, plaintext key material may be exposed in server memory during cryptographic operations.
Why Does FIPS 140-3 Validation Matter?
It allows organizations to assess a cryptographic module's security claims against a recognized standard instead of relying solely on the vendor's claims.
FIPS 140-3 evaluates far more than physical security. It covers areas including interfaces, roles and authentication, software and firmware security, sensitive security parameter management, and self-tests. When comparing products, organizations should check not only whether a module has been validated, but also its security level and the scope of the validation.
Does Deploying an HSM Make Key Management Completely Secure?
No. An HSM reduces the risk of key exposure, but it does not automatically correct misconfigured access policies, overly broad API permissions, or compromised credentials.
If an attacker obtains a legitimate account and its permissions, the attacker may be able to instruct the HSM to perform cryptographic operations without extracting the key itself. Operational controls—including least privilege, separation of duties, multi-party approval, and audit logging—must therefore be applied alongside the HSM.
Why Do HSMs Still Matter After Migrating to PQC?
Because the fundamental requirements remain unchanged: cryptographic keys must still be generated securely, stored safely, and protected from exposure during cryptographic operations, whether they are used with RSA, ECC, ML-KEM, or ML-DSA.
During the period when legacy cryptography and PQC coexist, a management foundation capable of separating and rotating different algorithms and keys according to policy becomes even more important. Not every HSM supports PQC, however, so organizations must verify algorithm support, performance, compatibility, and validation scope.
References
Check It Out
Curious how VIA PUF™-based hardware Key Management actually works in practice? Take a look at ICTK's security module lineup.
☑️ Explore ICTK Security Modules
☑️ Ask about qTrustHSM