Who is accountable when a forgotten machine identity is still active after a project ends?

Accountability should sit with the business or technical owner assigned to the identity, not with the security team alone. Security can define policy, monitor usage, and enforce guardrails, but the owner must approve access, confirm continued need, and retire the identity when its purpose ends. Clear accountability is what prevents machine identities from becoming invisible long-term exceptions.

Why This Matters for Security Teams

A forgotten machine identity is rarely a technical nuisance. It is an active trust path that can continue to authenticate, call APIs, sign artifacts, or reach internal services long after the project that created it has ended. That is why accountability matters: if no named owner is responsible for retirement, the identity becomes an invisible exception that security tools may observe but not truly govern. NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces the need for defined ownership, access review, and system accountability, but the operational burden sits with the assigned business or technical owner.

This issue is especially visible in environments where NHI sprawl outpaces governance. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs. When ownership is unclear, offboarding stalls, secrets stay valid, and expired projects leave behind live credentials. In practice, many security teams encounter the problem only after an audit, incident, or access review has already exposed the orphaned identity.

How It Works in Practice

Accountability for a forgotten machine identity should follow the same lifecycle logic as any other production asset, but with tighter emphasis on issuance, use, review, and retirement. The owner is the person or team that requested the identity, understands the workload it supports, and can confirm when that workload no longer exists. Security defines the control framework, but it should not be the default custodian of every service account, API key, certificate, or automation token.

Operationally, this means every machine identity needs a named owner, an expiry or review date, a documented purpose, and a retirement trigger tied to the project or system it supports. Current guidance suggests pairing this with access attestations and automated lifecycle controls, because manual tracking does not scale. NHIMG notes that 57% of organisations lack a complete inventory of their machine identities, while only 20% have formal offboarding processes for API keys. That is why the governance model must connect identity records to project records, ticketing, and decommission workflows, rather than leaving them in isolated IAM tables.

A practical control pattern looks like this:

• Assign a business and technical owner at creation time, not after deployment.
• Bind the identity to a workload, environment, or service catalog entry.
• Set short review intervals for long-lived access and enforce exceptions through approval.
• Revoke credentials automatically when the project, pipeline, or service is retired.
• Monitor for dormant use, unexpected callers, and secrets that remain valid after notice.

For deeper lifecycle context, NHI Mgmt Group’s Ultimate Guide to NHIs — What are Non-Human Identities is useful when mapping ownership to the broader identity estate, while NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate that responsibility into auditable control requirements. These controls tend to break down when identities are created outside formal provisioning paths, because no one can prove who owns the credential once the team reorganises or the project is archived.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance fast delivery against the risk of orphaned access. The tradeoff is most visible in DevOps, CI/CD, and temporary integration work, where teams resist ownership checks because they fear slowing deployment.

There is no universal standard for this yet, but current guidance suggests treating exceptions differently from normal production identities. Short-lived test credentials may be acceptable with stronger logging and tighter TTLs, while service accounts used by customer-facing systems should have stricter attestation and documented offboarding. The key edge case is shared ownership: if multiple teams rely on one identity, one team must still be named the accountable owner, otherwise retirement never happens. NHIMG’s Top 10 NHI Issues is a useful reference for recognising where ownership, visibility, and rotation failures combine into persistent risk.

Another common failure mode appears during reorganisations, acquisitions, or vendor-managed automation. If the original requester leaves and no handoff occurs, the identity survives by inertia. In those cases, security can flag exposure and enforce policy, but only the business or technical owner can confirm whether the workload still has a legitimate purpose. That distinction prevents accountability from collapsing into “security owns everything,” which is how forgotten identities stay active for months or years after a project ends.

Related resources from NHI Mgmt Group

• Who is accountable when contractor badge access is still active after the engagement ends?
• When does a machine identity become a compliance problem?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?