Who is accountable for over-privileged service accounts and stale secrets?

Why This Matters for Security Teams

Over-privileged service accounts and stale secrets are not just hygiene issues. They create a standing path into production, CI/CD, cloud control planes, and third-party tooling long after the original business need has changed. The practical problem is ownership: if nobody can prove why the access exists, who approved it, and when it should expire, the risk becomes shared but unresolved. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Guide to the Secret Sprawl Challenge both point to the same operational gap: identity sprawl becomes incident exposure when lifecycle control is weak.

In practice, many security teams discover over-privilege only after a secret turns up in a ticket, repo, or chat channel and the blast radius is already unknown.

How It Works in Practice

Accountability should follow the system that owns the workload, not just the team that stores the secret. For service accounts, that usually means the platform owner, application owner, or engineering manager with authority to justify each permission. For secrets, it means the party responsible for provisioning, rotation, revocation, and validation that the secret is still needed. The key test is simple: can the owner explain the business function, the access scope, and the expiry condition?

Good practice is to make that answer machine-checkable. Policies should require an inventory of non-human identities, mapped to a named owner, a business service, and a review date. Secrets should be short-lived where possible, with dynamic secrets preferred over long-lived static credentials. The 52 NHI Breaches Analysis shows that failure patterns repeatedly include missing ownership, poor rotation discipline, and access that persists past its intended use.

• Assign one accountable owner for each service account and secret set.
• Require a documented business purpose and approved access scope.
• Set rotation and expiry based on risk, not convenience.
• Review entitlements after deployment, offboarding, and environment changes.
• Revoke access automatically when the workload is retired or the token is no longer referenced.

Where teams mature this further, they use policy-as-code and workflow approvals so access can be evaluated at request time rather than during annual reviews. That aligns with current guidance in the OWASP NHI program and the broader identity lifecycle patterns described in Ultimate Guide to NHIs and NIST’s identity governance expectations. These controls tend to break down when secrets are hardcoded into CI jobs, embedded in containers, or shared across multiple services because ownership becomes ambiguous and revocation is no longer isolated.

Common Variations and Edge Cases

Tighter ownership and shorter secret lifetimes often increase operational overhead, requiring organisations to balance faster revocation against deployment friction and incident recovery speed. That tradeoff is real, especially in legacy systems, shared service accounts, and vendor-managed integrations where the business depends on credentials that are difficult to replace immediately.

Current guidance suggests treating shared accounts as transitional exceptions, not a preferred design. When multiple applications use the same NHI, accountability weakens because one owner cannot reliably explain every use case or revoke access without collateral disruption. The same problem appears with emergency accounts, break-glass access, and automation tied to older infrastructure: if the secret cannot be rotated safely, the organisation should document compensating controls and a sunset plan.

Two edge cases matter most. First, in CI/CD pipelines, stale secrets may survive long after the source code has changed, which is why secret scanning and repository governance must sit alongside ownership. Second, in outsourced or SaaS-managed environments, the internal owner still remains accountable for approving the access, validating vendor necessity, and confirming removal when the service ends. The practical lesson from NHIMG research and the 230M AWS environment compromise case study is that accountability fails fastest when access is inherited, duplicated, or never revalidated.

Related resources from NHI Mgmt Group

• 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?
• Who should be accountable for stale or unowned service accounts in AD?