Device custody is the accountable chain showing who currently controls a piece of hardware and in what state it exists. When custody is unclear, the organisation cannot reliably answer who can use the device, what it contains, or whether it should still be trusted.
Expanded Definition
Device custody is more than physical possession. In NHI security and broader IAM operations, it is the accountable record of who has the device, what state it is in, and whether it is authorised for use, transfer, or retirement. That record matters because a laptop, phone, hardware token, or dedicated appliance can carry secrets, certificates, cached sessions, recovery credentials, or agent tooling that turns hardware into a trust boundary.
Definitions vary across vendors when teams mix custody with ownership, asset inventory, or simple checkout tracking. In practice, custody should answer three questions at once: who is accountable, what security state the device is in, and whether the device is fit for the workload it supports. That makes it closely related to lifecycle governance, offboarding, and device trust decisions described in the Ultimate Guide to NHIs and to the identity assurance mindset reflected in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating custody as a logistics concern, which occurs when devices are handed around without a current accountable owner or security-state check.
Examples and Use Cases
Implementing device custody rigorously often introduces operational friction, requiring organisations to weigh faster handoffs against stronger accountability and device trust.
- A build server is reassigned after a contractor exits, but custody is not updated. The device still contains cached API keys and signing certificates, so the transfer is not just physical, it is a trust event.
- A hardware security token is issued to an AI operations engineer for break-glass access. Custody records must show who holds it, when it was last verified, and whether it has been reported lost or duplicated.
- A mobile device used for admin access is sent for repair. Until the chain of custody is restored and the device is re-imaged, it should not be trusted for privileged sessions.
- A robot controller or edge appliance is moved between facilities. The custody record helps determine whether its local credentials, certificates, or agent configurations still reflect the approved environment.
- After an account cleanup, the organisation checks whether any device in active custody still has orphaned secrets. This is a common follow-up when using guidance from the Ultimate Guide to NHIs alongside NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Device custody becomes security-critical because devices often carry the materials that make NHIs usable: tokens, certificates, secrets, and cached authority. If custody is weak, an attacker does not need to defeat identity controls directly. They can exploit a missing handoff record, an untracked repair, a shared admin laptop, or a device that was never formally decommissioned. That is why device custody is part of the same control surface as secret hygiene, offboarding, and Zero Trust enforcement.
The risk is not theoretical. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and 91.6% of secrets remain valid five days after notification, which means a lost or reassigned device can remain dangerous long after the event is detected. Those patterns are discussed in the Ultimate Guide to NHIs, especially where custody intersects with lifecycle control and access revocation.
Organisations typically encounter the custody problem only after a lost device, an unexplained access event, or a failed decommissioning, at which point the chain of 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-06 | Device custody affects lifecycle and offboarding control of NHI-bearing hardware. |
| NIST CSF 2.0 | PR.AA-1 | Identity and access assets must be managed so only authorised devices retain trusted access. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuously validating device trust, including custody and state. |
Track custody changes and verify device sanitisation before any reassignment or retirement.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
