Who is accountable when an audit finds unmanaged service accounts or secrets?

Why This Matters for Security Teams

Unmanaged service account and secrets are not just hygiene issues. They are evidence that no single team can currently prove who owns the identity, who approves its use, and who is responsible for its removal. That is why auditors focus on accountability chains, not just technical findings. When ownership is unclear, remediation stalls, access persists, and secrets become reusable entry points across systems.

NHIMG’s research on the Guide to the Secret Sprawl Challenge shows how quickly secrets spread beyond formal control, while the NHI Lifecycle Management Guide emphasises that ownership must exist from creation through retirement. External guidance aligns with that view: the NIST Cybersecurity Framework 2.0 expects clear governance and asset accountability, while the OWASP Non-Human Identity Top 10 treats unmanaged NHI sprawl as a direct security failure. In practice, many security teams encounter missing ownership only after a secret is exposed or a dormant account is reused in an incident.

How It Works in Practice

The practical answer is to treat accountability as shared, but not vague. The system owner is accountable for the business purpose of the service account or secret. The identity governance function is accountable for lifecycle controls such as approval, review, rotation, and removal. The security team is accountable for policy, monitoring, and escalation when controls fail. That division matters because an audit finding usually spans provisioning, use, and retirement.

Current guidance suggests three operational anchors:

• Assign a named owner for every non-human identity and every secret store entry.
• Require an approver who is separate from the requester for privileged or production access.
• Maintain evidence that access is reviewed, rotated, and revoked on schedule.

For mature environments, this often means tying service accounts to application inventories, CMDB records, or workload registries, then reconciling them against vault records and cloud IAM permissions. Where secrets are stored in code, tickets, or chat tools, the accountability chain must still identify who accepted that risk and who is responsible for fixing it. The 2025 State of NHIs and Secrets in Cybersecurity, attributed to Entro Security, reports that 62% of all secrets are duplicated and stored in multiple locations, which is a strong signal that ownership and control are often fragmented. That finding is consistent with the control intent in the Top 10 NHI Issues and with NIST’s expectation that assets and identities be tracked throughout their lifecycle. These controls tend to break down when identity records live in one tool, secrets live in another, and nobody reconciles them after application changes or staff turnover.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, so organisations must balance auditability against operational speed. That tradeoff becomes visible in environments with dozens of application teams, shared platform accounts, or outsourced operations, where naming a single owner can be politically difficult but still necessary.

There is no universal standard for this yet, but current practice is converging on a few edge-case rules. Shared platform service accounts should usually be owned by the platform team, with application teams accountable for their specific usage. Vendor-managed secrets still need an internal business owner, even if an external party rotates them. Ephemeral workload identities are different: their accountability rests less on human holders and more on the team responsible for the workload and its policy enforcement.

Audit findings also change when a secret is discovered in source control, a ticketing system, or a collaboration tool. In those cases, the issue is not just exposure but failure of process ownership across development and operations. The right response is to document the accountable owner, the control gap, and the remediation deadline, then verify that the control exists in the lifecycle process, not just in the incident ticket.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?