Access custody is the practical ownership of an access path, including who can grant it, use it, review it, and revoke it. For sovereign services, custody matters because a platform may appear local while key operational control still sits with external parties or cross-border support teams.
Expanded Definition
Access custody is the accountable control of an access path, meaning the party that can provision it, approve it, observe it, and remove it when needed. In NHI operations, that custody may sit with a platform team, a security team, an external managed service provider, or an upstream cloud service. The term is practical rather than theoretical: it describes who can actually intervene when a service account, API key, certificate, or agent credential becomes risky.
Usage in the industry is still evolving, and no single standard governs this yet. For that reason, access custody is best understood as a governance layer above permissions and below strategic ownership. It complements RBAC, PAM, and ZTA, but it is not the same as any of them. RBAC answers who is authorised to do something, while custody answers who can change or rescind that authorisation in real time. The OWASP OWASP Non-Human Identity Top 10 treats identity lifecycle weaknesses as a core risk area, and access custody is the control point that makes those lifecycle actions enforceable.
The most common misapplication is treating local administration as custody, which occurs when a team can use an access path but cannot independently revoke it, rotate it, or prove who else can do so.
Examples and Use Cases
Implementing access custody rigorously often introduces approval latency and cross-team coordination overhead, requiring organisations to weigh rapid operations against tighter control over who can alter privileged access.
- A SaaS engineering team can run a production service account, but security operations retains custody for emergency revocation and rotation after compromise.
- A cross-border support vendor can troubleshoot an API integration, yet the customer organisation keeps custody of the API key so the vendor cannot extend access beyond contract scope.
- An agentic AI system is allowed to call internal tools, but the platform team owns custody of the agent credentials and can suspend them if behaviour changes unexpectedly.
- A certificate used by a data pipeline is issued by a central identity team, while the application team only has use rights and must request renewal through controlled workflow.
- For background reading on service-account lifecycle failures, see the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis, which show how weak control of non-human access paths repeatedly becomes an incident multiplier.
- When custody is embedded in a federated trust model, the technical path may span systems, but the revocation authority must remain unambiguous and auditable.
Practical implementation often aligns with identity governance concepts described in the OWASP Non-Human Identity Top 10, especially where secrets, rotation, and offboarding are handled by different teams.
Why It Matters in NHI Security
Access custody is critical because many NHI failures are not caused by missing authentication alone, but by unclear authority over the full access lifecycle. When no one can quickly revoke a credential, rotate a secret, or verify third-party support privileges, dormant access can persist far beyond the incident window. That is especially dangerous for service accounts and secrets that are embedded in code, CI/CD pipelines, or external integrations.
NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and the Ultimate Guide to NHIs — Key Challenges and Risks links those failures to poor visibility, slow remediation, and unclear ownership. That matters because custody is what makes remediation actionable rather than merely documented. It is also closely tied to ZTA thinking: the NHI must be continuously governable, not only trusted at the moment of issuance.
For governance teams, access custody is a control question: who can prove authority over this path today, and who can terminate it if trust changes? Organisations typically encounter the consequences only after a breach, failed audit, or vendor dispute, at which point access 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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Lifecycle and secret-handling risks map directly to NHI custody controls. |
| NIST Zero Trust (SP 800-207) | PA-5 | Zero Trust requires continuous control over identities and their access paths. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management depends on accountable custody of entitlements. |
Assign a clear owner for issuance, use, review, rotation, and revocation of every NHI.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
