Key custody is the ownership and control of cryptographic keys across their lifecycle, including storage, rotation, emergency use, and retirement. Poor custody turns encryption into a weak barrier because any identity with key access can recover data that should have remained protected.
Expanded Definition
Key custody describes who can create, store, retrieve, use, rotate, disable, and retire cryptographic keys across their full lifecycle. In NHI security, custody is not just possession. It is the combination of technical controls, operational approvals, and auditability that determines whether a key can actually be used to decrypt data, sign requests, or unlock an automated system.
Definitions vary across vendors, but the control problem is consistent: if an agent, service account, pipeline, or administrator can reach the key without strong guardrails, encryption becomes a policy promise rather than a real barrier. This is why key custody must be understood alongside NIST Cybersecurity Framework 2.0 principles for protection and governance, and alongside lifecycle guidance in the Ultimate Guide to NHIs. The term is especially important where non-human identities hold signing or decryption authority that outlives a single deployment or user session.
The most common misapplication is treating key storage as the same thing as key custody, which occurs when teams equate being in a vault with being safely controlled.
Examples and Use Cases
Implementing key custody rigorously often introduces operational friction, requiring organisations to weigh faster automation against tighter approval, logging, and recovery controls.
- A CI/CD pipeline signs release artifacts with a private key stored in a hardware-backed system, but only a limited break-glass path can access it during incident recovery.
- An AI agent uses a signing key to authenticate tool calls, while rotation is enforced through automated expiry and approval workflows rather than manual operator handling.
- A data platform encrypts backups with keys whose custody is separated from the administrators who manage the storage layer, reducing the chance of lateral misuse.
- A service account receives temporary access to a decryption key for a batch job, then loses that access automatically when the job ends, consistent with least privilege guidance in the Ultimate Guide to NHIs.
- A security team defines who can approve emergency key use, how those actions are logged, and how revocation is verified after the incident closes.
In practice, key custody is often discussed together with vaulting, secret rotation, and service account governance, but the real issue is whether a non-human identity can exercise key power without inappropriate persistence. For related control patterns, practitioners often align custody decisions with identity lifecycle expectations from NIST Cybersecurity Framework 2.0 and broader NHI governance controls.
Why It Matters in NHI Security
Key custody is a security boundary because a compromised key often grants more authority than a compromised password. When custody is weak, attackers do not need to defeat encryption. They simply inherit the ability to use it. That is especially dangerous for api key, signing keys, certificate keys, and recovery keys tied to service accounts, workloads, and autonomous agents.
NHIMG research shows that 71% of NHIs are not rotated within recommended time frames, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs. Those findings point to a custody problem as much as a storage problem: unmanaged retention, weak revocation, and unclear ownership create exposure long after a key should have been retired. That is why custody should include emergency access, audit evidence, and clear handoff rules across teams and systems.
Organisations typically encounter the consequences only after a credential leak, service compromise, or failed incident response, at which point key 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 | Covers improper secret handling and custody failures for machine identities. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance applies to who can use protected keys. |
| NIST Zero Trust (SP 800-207) | Zero trust limits implicit trust in any identity that can reach a key. |
Inventory key holders, restrict access paths, and verify rotation and retirement controls.
