A customer-owned HSM is a cryptographic device administered and controlled by the organisation that owns the secrets. It supports stronger key sovereignty because the provider does not hold the raw key material. In practice, its value depends on proper administration, high availability, and the surrounding controls that protect the vault host and operating environment.
Expanded Definition
A customer-owned HSM is a hardware security module that the organisation acquires, configures, and governs so the provider never controls the raw key material. In NHI and IAM environments, that distinction matters because key sovereignty, separation of duties, and auditability depend on who can initialize, back up, restore, and retire the device. The control model is narrower than a general “encrypted at rest” claim and stronger than simple application-level secret storage, because the HSM becomes the trust anchor for signing, wrapping, and key lifecycle enforcement.
Definitions vary across vendors on whether customer-owned means physically on-premises, logically dedicated, or merely customer-controlled through a cloud management plane. NHI Management Group treats the term as a governance pattern, not a marketing label: the customer must retain administrative authority over the key lifecycle and recoverability path. That makes the surrounding environment part of the security boundary, including the vault host, access policy, and operational monitoring. For broader identity governance context, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating a provider-managed encryption service as customer-owned HSM control, which occurs when the vendor can still access, export, or rotate the underlying keys.
Examples and Use Cases
Implementing a customer-owned HSM rigorously often introduces operational overhead, requiring organisations to weigh stronger key sovereignty against device management, resilience planning, and administrative complexity.
- An AI agent signs outbound requests with keys generated inside a customer-owned HSM so the provider cannot extract signing material even if application logs are exposed.
- A payment workflow stores root certificate keys in a customer-controlled HSM to support compliance, key rotation, and explicit approval for every lifecycle event.
- A secrets platform uses the HSM to wrap high-value API keys while the vault service handles retrieval policy, reducing exposure if application storage is compromised.
- A regulated enterprise isolates emergency recovery keys in an HSM operated under dual control, with separate administrators for initialization and export approval.
- A security team pairs the HSM with guidance from the Ultimate Guide to NHIs and maps the design to Zero Trust patterns described in the NIST Cybersecurity Framework 2.0.
In practice, this model is most valuable where a service account or agent must continue operating even as keys are rotated, escrowed, or revoked under tight governance.
Why It Matters in NHI Security
Customer-owned HSMs reduce the blast radius when an NHI credential is exposed, but they do not eliminate risk from misconfiguration, weak access controls, or poor availability design. If administrators overprivilege vault operators, the HSM can become another high-value target rather than a protective boundary. The data in NHI Management Group’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, 73% of vaults are misconfigured, and 79% of organisations have experienced secrets leaks. Those conditions make key sovereignty meaningful only when paired with disciplined lifecycle controls and continuous review.
For NHI security teams, the HSM is not just a cryptographic appliance, it is an operational control that affects offboarding, key rotation, emergency recovery, and incident response. It should be evaluated alongside identity governance, vault hardening, and the organisation’s ability to prove who can authorize use of a key at any moment. Organisations typically encounter the full importance of a customer-owned HSM only after a secrets leak or provider-side compromise, at which point key control becomes operationally unavoidable to address.
See also the governance lens in the NIST Cybersecurity Framework 2.0 for aligning protection, detection, and recovery duties around NHI secrets.
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, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Customer-owned HSMs reduce secret exposure and strengthen key control. |
| NIST CSF 2.0 | PR.AC-1 | Access control and authorization govern who may administer HSM-protected keys. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust assumes continuous verification around key use and trusted components. |
| NIST AI RMF | AI systems rely on secure key custody for model and agent operations. |
Treat HSM access as a protected resource and continuously validate every request to use keys.
Related resources from NHI Mgmt Group
- What breaks when customer-owned API keys are not lifecycle-managed?
- What do security teams get wrong about developer-owned customer IAM?
- What is the difference between keeping AI gateway analytics in customer-owned object storage and running a managed logging database in the provider cloud?
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
