Accountability sits with the teams that own device identity, fleet governance, and revocation operations. Organisations need clear ownership for issuance, renewal, revocation checking, and retirement workflows. If those controls are missing, a compromised or decommissioned device can keep authenticating, which turns a lifecycle failure into an access control failure.
Why This Matters for Security Teams
When a device stays trusted after compromise or retirement, the problem is rarely the exploit itself. The real failure is identity lifecycle control: who can issue the device identity, who can challenge it again, and who can revoke it when the device no longer belongs in the fleet. In NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now, only 20% of organisations report formal offboarding and revocation processes for API keys, which is a useful signal for how often lifecycle gaps persist across machine identities too.
For fleet-owned devices, trust must be continuously re-earned. A retired endpoint with valid certificates, cached tokens, or stale enrollment data can continue to authenticate long after its operational status changed. That turns an asset management issue into an access control issue, and in practice the blast radius usually expands before anyone notices. The lesson is simple: accountability is not just about owning the asset; it is about owning the revocation path, the policy checks, and the evidence that trust was removed.
How It Works in Practice
Accountability should be split across three operational functions: device identity ownership, fleet governance, and revocation operations. The team that issues device credentials owns the cryptographic trust anchor. The team that manages the fleet owns device state, such as active, quarantined, retired, or lost. The team that runs revocation owns the technical controls that make trust expire or fail closed when state changes.
In a mature setup, device identity is bound to workload or device certificates, not just inventory records. Revocation is enforced through certificate status checks, short-lived credentials, and policy decisions that reject stale trust. This aligns with the direction of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, system integrity, and lifecycle handling. It also reflects the breach patterns documented in The 52 NHI breaches Report, where compromised non-human identities persist because revocation is slow, incomplete, or never operationalised.
- Define a named owner for issuance, renewal, revocation, and retirement.
- Use short-lived device credentials where possible, with automatic expiry tied to state.
- Require revalidation when a device changes posture, location, or management status.
- Revoke trust at both the certificate layer and the authorisation layer.
- Log who changed lifecycle state, when it changed, and whether revocation completed.
This works best when the fleet is centrally managed and devices regularly check in. These controls tend to break down when devices are offline for long periods, because revocation cannot be confirmed until the next successful trust evaluation.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring organisations to balance stronger trust removal against device availability and support burden. That tradeoff becomes visible in field devices, offline laptops, industrial endpoints, and bring-your-own-device environments, where immediate revocation can interrupt legitimate work.
Current guidance suggests treating these cases as exceptions, not as reasons to keep broad standing trust. If a device cannot reliably receive revocation updates, the safer pattern is reduced trust with narrower permissions, shorter certificate lifetimes, and more frequent re-attestation. For high-risk fleets, organisations may also layer conditional access, posture checks, and network segmentation so that a retired or compromised device cannot move laterally even if one control fails.
There is no universal standard for this yet, but the practical rule is consistent: retirement must mean cryptographic trust is removed, not just that the device is deleted from an asset list. For teams building stronger governance around this problem, the patterns in NHI Management Group’s Ultimate Guide to NHIs and the compromise patterns in 52 NHI Breaches Analysis show why stale trust is usually discovered after exposure, not during planned decommissioning.
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, OWASP Agentic AI Top 10 and CSA MAESTRO 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-03 | Covers rotation and revocation gaps that let retired devices stay trusted. |
| OWASP Agentic AI Top 10 | Useful where device identities support autonomous workloads and tool access. | |
| CSA MAESTRO | Addresses lifecycle governance for machine and agent identities across the fleet. | |
| NIST CSF 2.0 | PR.AC-1 | Identity and access management requires trustworthy lifecycle state for devices. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires continuous verification and limits trust in stale device identities. |
Bind device trust to task-scoped authorization and revoke access when the workload or device state changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
