A hardware security module is a tamper-resistant device or service used to generate, store, and use cryptographic keys without exposing them directly to endpoints. For code signing, it reduces the chance that a compromised workstation or build server can steal the signing authority.
Expanded Definition
A hardware security module, or HSM, is a tamper-resistant cryptographic boundary that generates, protects, and uses keys without exposing them in application memory or on general-purpose servers. In NHI operations, it is commonly used for certificate authority keys, code-signing keys, token issuance, and root-of-trust functions. Standards and vendor implementations vary, so the exact operating model may be on-premises, cloud-managed, or embedded in a wider key-management service. What matters is that the private key material remains under tightly controlled hardware-backed protection, with policy enforced at the boundary rather than by software alone. That distinction is important for service accounts, CI/CD systems, and autonomous agents that need cryptographic authority but should not receive reusable secrets. NIST guidance on the NIST Cybersecurity Framework 2.0 aligns well with this model because it emphasises protecting credentials, limiting abuse, and maintaining trustworthy system operations.
The most common misapplication is treating an HSM as a general secret store, which occurs when teams place low-value tokens, application passwords, or ad hoc exports into hardware that was designed for high-assurance key protection.
Examples and Use Cases
Implementing HSM controls rigorously often introduces latency, operational complexity, and recovery planning overhead, requiring organisations to weigh stronger key protection against slower change workflows and stricter administration.
- Code signing for software releases, where build pipelines call the HSM to sign artifacts without ever exposing the signing key to the CI runner.
- Certificate authority protection, where the issuing key stays hardware-backed while lifecycle steps such as renewal and revocation are governed centrally.
- Payment and tokenisation systems, where cryptographic boundaries help protect card-related material and reduce the blast radius of a compromised server.
- Cloud workload identity issuance, where an HSM-backed root key supports subordinate keys or certificates used by services and agents.
- Key custody for NHI governance, where the Ultimate Guide to NHIs is often used to frame lifecycle controls around rotation, visibility, and offboarding.
In practice, teams often pair HSMs with policy enforcement so that only approved workloads can request cryptographic operations. This is especially relevant where a signing key authorises production deployments, because a compromised developer laptop should not be able to mint trusted releases. The NIST Cybersecurity Framework 2.0 provides a useful operational lens for mapping those protections to access control and resilience objectives.
Why It Matters in NHI Security
Hardware-backed key protection matters because many NHI incidents start when a secret is copied into code, a build system, or a vault with weak controls. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage. That is why an HSM should be viewed as part of a broader control stack, not as a standalone cure. It helps reduce the chance that credentials can be extracted after endpoint compromise, but it does not solve over-privilege, poor rotation, or weak monitoring. The same governance logic appears in the Ultimate Guide to NHIs, where key custody is inseparable from lifecycle discipline, visibility, and revocation. For architecture teams, that means pairing hardware-backed keys with least privilege, rotation, and clear ownership; for security teams, it means validating that the HSM is actually in the critical path for the right operations. Organisations typically encounter HSM relevance only after a signing key, token issuer, or certificate authority has been abused, at which point hardware-backed control becomes operationally unavoidable to restore trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret protection and key custody for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Addresses credential protection and access enforcement around sensitive assets. |
| NIST Zero Trust (SP 800-207) | SC-3 | Supports zero trust by limiting trust in endpoints that request key operations. |
Keep signing and issuer keys hardware-backed and remove direct secret exposure from workloads.
Related resources from NHI Mgmt Group
- What is the difference between API-key security and hardware-bound identity for AI agents?
- Why has identity replaced the network perimeter as the primary security boundary?
- What is phishing-resistant authentication and how does it relate to NHI security?
- What is the first step in building a modern NHI security programme?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org