Who is accountable when a service identity retains access after the data need has ended?

Why This Matters for Security Teams

When a service identity keeps access after the data need has ended, the issue is rarely limited to one stale role assignment. It is usually a governance failure across ownership, review, and decommissioning. That matters because service identities often carry broad, persistent privileges and are easy to overlook in standard access reviews. Guidance from the OWASP Non-Human Identity Top 10 makes clear that non-human identities need explicit lifecycle controls, not informal assumptions about application teams.

Security teams often get this wrong by treating the cloud platform team as the default owner of access, even when the dataset owner, application owner, and identity administrators each hold part of the control surface. The practical risk is not only unauthorized access, but also audit failure, broken segregation of duties, and hidden paths for lateral movement. Once a service identity is embedded in automation, the access can persist long after the original business purpose has ended. In practice, many security teams encounter this only after a review finding, an incident, or a failed decommissioning, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability works best when it is assigned to the team that can prove the business need, approve continued access, and remove it when that need expires. That usually means the dataset owner or service owner is accountable for justification, while IAM or platform teams are responsible for enforcement mechanisms. The control expectation aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, accountability, and configuration management.

In mature environments, this is implemented through named ownership, expiry dates, and recurring recertification. A service identity should not simply exist because it once worked in production. It should have a recorded purpose, a linked system or dataset, an approver for continued access, and an offboarding path when the task ends. Current best practice also includes secret rotation, key inventory, and deprovisioning checks tied to change management. For higher-risk environments, some organisations add just-in-time access or short-lived credentials, but there is no universal standard for this yet across all cloud and identity stacks.

• Assign one accountable business owner for the dataset or workload.
• Record the service identity purpose, scope, and expiry date.
• Separate approval for creation, continued access, and retirement.
• Automate recertification and alert on identities that miss review deadlines.
• Remove unused keys, tokens, and certificates when the task ends.

Where this becomes most effective is when identity lifecycle controls are tied to asset inventory and data classification, so the organisation can prove why access still exists. These controls tend to break down when service identities are created outside standard onboarding workflows because ownership, expiry, and review obligations are never recorded.

Common Variations and Edge Cases

Tighter lifecycle governance often increases operational overhead, requiring organisations to balance access assurance against delivery speed. That tradeoff is real for ephemeral workloads, CI/CD pipelines, and machine-to-machine integrations that change frequently. In these cases, the accountability model needs to be explicit: the product or data owner remains answerable for the business need, while engineers implement the technical guardrails. Best practice is evolving, but the principle is stable: ownership cannot disappear just because the access is automated.

There are also edge cases where multiple teams legitimately share responsibility. For example, a managed service provider may operate the workload, while the customer retains data ownership and approval authority. In regulated contexts, shared responsibility should be documented in contracts, control matrices, and access review procedures. Another common exception is break-glass or emergency access, which should be time-bound and reviewed after use rather than treated as standing entitlement. If the identity is tied to a third-party integration, the accountability question should also include vendor offboarding, because expired data use is often missed during contract renewal.

For identity-heavy environments, the same logic applies to non-human identities that access APIs, data stores, and orchestration tools. If the system still trusts the identity after the data purpose has ended, the control failure is governance, not just authentication. In that sense, the core accountability question is less about who clicked the permission and more about who owned the decision to let the identity remain active.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• Who is accountable when an inactive non-human identity is still present after business use has ended?
• Who is accountable when fragmented identity data causes access failures?
• Who is accountable when a cloud workload retains privileged access after it should have been removed?