Who controls the encryption keys and related protection boundaries for sensitive integrations. In identity governance, custody matters because access to the data path is only part of the control story. If the enterprise does not own the keys, it may not fully own the trust model.
Expanded Definition
Cryptographic custody is the operational control of encryption keys, key material, and the boundaries that determine who can use them. In NHI security, this goes beyond whether data is encrypted in transit or at rest. It asks who can create, store, rotate, revoke, escrow, and recover the keys that actually make protection enforceable. The distinction matters because a team can administer an API endpoint, a workload, or a secret vault without truly owning the trust relationship if another party controls the keys.
Usage in the industry is still evolving, and definitions vary across vendors, but the core governance question is stable: does the enterprise control the cryptographic root of trust or only consume it as a service? That question maps closely to the access and protection outcomes described in the NIST Cybersecurity Framework 2.0, especially where control, recovery, and resilience depend on asset ownership. The most common misapplication is assuming encryption equals custody, which occurs when a third party manages the key hierarchy while the organization only sees ciphertext.
Examples and Use Cases
Implementing cryptographic custody rigorously often introduces governance overhead, requiring organisations to weigh stronger trust control against added operational complexity and recovery planning.
- A platform team stores application secrets in a managed vault, but the enterprise retains the root keys so it can revoke access during an incident without waiting on the provider.
- An API integration uses customer-managed keys for envelope encryption, so the business can rotate keys on its own schedule and align custody with internal policy.
- A third-party SaaS encrypts data with provider-owned keys, and the security team documents the resulting custody gap because the vendor, not the enterprise, controls revocation and recovery.
- A regulated workload separates data-path access from key authority, using hardware-backed controls to ensure only designated custodians can approve key usage.
- A migration team reviews service accounts and secrets storage alongside the Ultimate Guide to NHIs because key ownership determines whether the migration preserves actual control or only preserves availability.
For implementation patterns, teams often compare key custody models with published guidance from the NIST Cybersecurity Framework 2.0 and align the custody decision to the sensitivity of the integration, the recovery model, and the blast radius of compromise.
Why It Matters in NHI Security
Cryptographic custody is a governance control as much as a technical one. If an NHI uses tokens, certificates, or API keys to reach sensitive systems, the question is not only whether the secret is protected, but who can change its lifecycle and invalidate it when trust fails. That is why poor custody creates hidden dependency risk, especially in third-party integrations, shared platforms, and delegated administration models. NHIMG notes that 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, which shows how quickly key control failures become identity failures when custody is unclear. The Ultimate Guide to NHIs also shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
In practice, custody affects incident response, offboarding, supplier risk, and zero trust enforcement. If a vendor holds the keys, the enterprise may be unable to prove revocation, isolate a compromised integration, or preserve forensic integrity. Organisations typically encounter the impact only after a breach, contract dispute, or emergency rotation request, at which point cryptographic custody becomes operationally unavoidable to address.
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 | Key custody is central to improper secret and credential management. |
| NIST CSF 2.0 | PR.AC | Access control and identity governance depend on who can exercise cryptographic trust. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit control of trust anchors and authentication boundaries. |
Map key ownership and revocation authority to access governance and recovery processes.
Related resources from NHI Mgmt Group
- When should organisations add risk signals to cryptographic authorization flows?
- Why do partner APIs still need cryptographic trust anchors after registration?
- Why do cryptographic keys need to be part of NHI governance?
- How should security teams build a cryptographic inventory across cloud and CI/CD systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
