The point at which control over an authenticator shifts from the user or platform to the issuing identity system. For device-bound credentials, that boundary determines who can revoke, replace, attest, and recover access, making it a governance issue rather than a storage detail.
Expanded Definition
A credential custody boundary marks the operational handoff where an authenticator stops being controlled by the end user, app, or hosting platform and becomes governed by the issuing identity system. In NHI programs, that boundary determines who can revoke, rotate, rebind, attest, escrow, or recover access when a device or workload is replaced, compromised, or retired.
This concept is closely related to identity lifecycle governance, but it is narrower than generic credential management because it focuses on control authority, not storage location. A token stored in a vault may still sit outside the custody boundary if the issuing system cannot enforce lifecycle actions. For device-bound credentials, the boundary is often defined by enrollment, proof of possession, certificate renewal, or key attestation, which are all discussed in the NIST SP 800-63 Digital Identity Guidelines and the OWASP Non-Human Identity Top 10.
Definitions vary across vendors, especially when “custody” is used to describe either physical possession, logical control, or administrative authority, so teams should define the boundary in governance terms before implementation. The most common misapplication is treating secret storage as custody, which occurs when teams assume a vault or agent runtime automatically gives the issuer enforceable control over revocation and recovery.
Examples and Use Cases
Implementing credential custody boundaries rigorously often introduces lifecycle overhead, requiring organisations to weigh tighter control against more complex enrollment, renewal, and recovery workflows.
- A certificate authority issues a device-bound certificate to an agent, and only the identity system can revoke it after endpoint attestation fails.
- An API key is generated in a pipeline, but the custody boundary is not reached until the central issuer can rotate or disable it during incident response.
- A hardware-backed workload credential is enrolled through an attestation flow, with the issuer retaining the ability to reissue the credential after device replacement.
- A cloud service account uses ephemeral access tokens, and the boundary is defined by the issuer’s ability to expire and rebind those tokens without platform admin intervention.
These patterns align with the shift toward dynamic credentials described in the Ultimate Guide to NHIs — Static vs Dynamic Secrets and are operationally distinct from secret sprawl scenarios such as the Guide to the Secret Sprawl Challenge. In practice, custody boundaries are also tested during supply chain incidents, such as the Reviewdog GitHub Action supply chain attack, where exposed credentials outlive the systems that created them.
Why It Matters in NHI Security
When the custody boundary is unclear, revocation becomes slow, recovery becomes manual, and compromise can spread across workloads that were assumed to be centrally governed. That is especially dangerous in environments with shared pipelines, short-lived agents, and multi-cloud access paths, where a credential may be technically present but no longer under enforceable issuer control. NHIMG research shows that 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with human IAM, which helps explain why custody handoffs are still frequently undocumented.
This is not only a hygiene issue. Once attackers obtain exposed credentials, they move quickly, and the window for issuer-side control narrows sharply; Entro Security reports that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes. That urgency makes custody boundaries central to incident containment, especially in cases like the 230M AWS environment compromise and the Cisco Active Directory credentials breach, where recovery depends on knowing who truly controls the authenticator.
Organisations typically encounter the consequence only after a credential cannot be revoked fast enough during an incident, at which point credential custody boundary 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 SP 800-63, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Focuses on secret and credential lifecycle control for non-human identities. |
| NIST SP 800-63 | AAL2 | Digital identity assurance depends on controlled binding and recovery of authenticators. |
| NIST CSF 2.0 | PR.AA | Identity and access control outcomes require clear authority over authenticators. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires continuous control over identities, devices, and their trust state. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management controls address issuance, change, and compromise response. |
Define issuer control for each authenticator and ensure revocation, rotation, and recovery are centrally enforceable.
