Accountability should sit with the business owner of the workflow, the technical owner of the integration, and the security team governing policy. If no one owns the lifecycle, the identity becomes a permanent exception. That is how delegated access persists after the original use case no longer exists.
Why This Matters for Security Teams
Accountability for employee-created non-human identities is not a paperwork question. It determines whether a service account, API key, or automation token has a real owner when it starts making changes, calling downstream systems, or outliving the workflow that created it. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes, while 97% of NHIs carry excessive privileges.
That combination is dangerous because employee-created identities are often provisioned for convenience, not governed as production assets. If the business owner, technical owner, and security policy owner are not explicit, nobody is responsible for rotation, scope review, or retirement. The result is usually a permanent exception that survives team changes, vendor changes, and application rewrites. Current guidance in the NIST Cybersecurity Framework 2.0 points toward clear ownership, continuous risk management, and repeatable lifecycle control rather than informal trust.
In practice, many security teams discover the ownership gap only after a dormant token is still active long after the employee who created it has moved on, rather than through intentional lifecycle governance.
How It Works in Practice
The best operating model is shared accountability with a single accountable owner. The business owner owns the outcome and justifies why the NHI exists. The technical owner owns implementation details such as scope, token storage, rotation, and removal from pipelines or applications. The security team sets policy, approves exceptions, and validates that the control works. That separation mirrors the way NHI Management Group guidance on lifecycle governance frames NHI risk: ownership must follow the identity from creation through retirement.
In operational terms, accountability should be attached to the workflow, not the individual employee. If someone creates a CI/CD token for an integration, the record should identify the application, the business service, and the technical steward who can rotate or revoke it. Mature programs also enforce joiner-mover-leaver style reviews for NHIs, with periodic attestation and automated expiry where possible. That aligns with NIST CSF 2.0 principles for governance, and it supports zero trust by reducing standing access.
- Assign one accountable business owner per NHI, even if multiple teams use it.
- Require a named technical steward who can rotate secrets and respond to alerts.
- Document the system, data, and permissions the NHI is allowed to touch.
- Set an expiry date or review date at creation, not after the fact.
- Revoke or re-approve the identity when the workflow, vendor, or employee changes.
When teams fail here, the usual trigger is not a sophisticated attack but routine turnover, forgotten integrations, or a copied credential left behind in code or automation. These controls tend to break down when identities are embedded in ad hoc scripts and no configuration inventory exists because ownership cannot be enforced on assets nobody can reliably find.
Common Variations and Edge Cases
Tighter ownership rules often increase operational overhead, requiring organisations to balance speed against auditability. That tradeoff matters because not every employee-created NHI should be treated the same way. A low-risk read-only token for an internal dashboard may justify lighter review than a production secret that can deploy code, query customer data, or trigger payments. Best practice is evolving, and there is no universal standard for this yet.
Some organisations assign accountability to the manager of the employee who requested the NHI. That can help with approvals, but it is not enough for ongoing control because managers rarely know the technical blast radius. A stronger model is to treat the business process owner as accountable, with the technical owner responsible for day-to-day administration and security responsible for governance. That approach is especially important when credentials are stored outside vaults or spread across CI/CD systems, a pattern highlighted in the JetBrains GitHub plugin token exposure research and by the broader NHI exposure trends documented in the Ultimate Guide to NHIs.
Edge cases include contractor-built automations, shared service accounts, and tool-generated identities created outside formal IT tickets. In those situations, the control should be to force a human owner of record before the identity is granted broad access. If no one can accept that responsibility, the identity should not be permitted to persist.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Ownership and lifecycle gaps are core NHI governance failures. |
| NIST CSF 2.0 | GV.OV-01 | Governance requires clear accountability for identity lifecycle risk. |
| NIST AI RMF | GOVERN | Accountability for autonomous or automated identities fits AI governance expectations. |
Assign accountable owners for NHI creation, review, rotation, and revocation under governance oversight.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
