Private key custody describes where a certificate’s secret key is stored and who can access it. Strong custody keeps keys non-exportable, limits access to the smallest necessary service account set, and avoids storage in code, shared filesystems, or other exposed locations.
Expanded Definition
private key custody is the operational answer to a simple question: where does the secret key live, and who can exercise control over it? In NHI security, custody is stronger than “storage” because it also includes exportability, access paths, and the service identities allowed to use the key. Definitions vary across vendors, but the practical goal is consistent: keep the key non-exportable, tightly bound to an approved workload, and protected from casual reuse or disclosure.
This is especially important for certificates used by agents, service accounts, workload identities, and automation pipelines. A key stored in a code repository, a shared filesystem, or an image layer is not really under secure custody, even if it is technically encrypted. By contrast, keys held in hardware-backed keystores, cloud KMS, HSMs, or well-governed secrets systems can support stronger control and auditability. The NIST Cybersecurity Framework 2.0 is useful here because it frames custody as part of broader asset protection and access governance, not just cryptographic handling.
The most common misapplication is treating any encrypted storage location as secure custody, which occurs when teams ignore export permissions, backup exposure, or shared admin access.
Examples and Use Cases
Implementing private key custody rigorously often introduces operational friction, requiring organisations to weigh rapid deployment against tighter issuance, access, and recovery controls.
- A Kubernetes workload uses a certificate stored in a node-local secure store, with the private key marked non-exportable and bound to a single service account for mutual TLS.
- A CI/CD pipeline requests short-lived credentials from a managed signing service instead of embedding a private key in build scripts, reducing the blast radius if the pipeline is compromised. The Ultimate Guide to NHIs discusses why secret placement outside controlled systems remains a recurring failure pattern.
- An internal API gateway rotates its certificate through an HSM-backed workflow so operators can renew identities without exposing raw key material to application teams.
- A software agent authenticates to downstream services using a certificate issued through a central trust service, aligning with identity lifecycle practices described in the NIST Cybersecurity Framework 2.0.
- A legacy batch job keeps its key in a shared config directory for convenience, which may work until a backup operator, container escape, or over-broad filesystem permission exposes it.
In practice, the right custody model depends on how often the key must be used, whether it must be exported, and how much failure tolerance the workload needs. The Ultimate Guide to NHIs is a useful reference for connecting custody decisions to lifecycle governance and rotation discipline.
Why It Matters in NHI Security
Private key custody is where cryptography becomes governance. If the wrong team, process, or platform can access a private key, the certificate no longer proves anything reliable about the workload using it. That failure can enable impersonation, lateral movement, broken trust between services, and unnoticed persistence after an incident.
Custody also affects how quickly organisations can contain damage. When keys are scattered across code, filesystems, and ad hoc tooling, revocation becomes slower and more error-prone. NHI risk data from the Ultimate Guide to NHIs shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes custody failures common rather than exceptional. Strong custody supports the intent of NIST Cybersecurity Framework 2.0 by reducing asset exposure and limiting unauthorised use.
Organisations typically encounter the operational impact only after a secret leak, service compromise, or certificate abuse, at which point private 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 | Addresses secret storage and misuse patterns that weaken private key custody. |
| NIST CSF 2.0 | PR.AC-1 | Private key custody is an access control issue because keys grant machine identity use. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires strong identity proof, which depends on protected key custody. |
Restrict key usage to approved workloads and review who can access or administer custody systems.
