Service accounts are becoming a liability for NHI governance

At a glance

What this is: This article argues that service accounts have become a security liability because they inherit human-centric identity handling despite machine identities changing on engineering time, not HR time.

Why it matters: It matters because IAM, PAM, and NHI programmes need controls that match workload lifecycles, or they will keep accumulating orphaned access, excessive privilege, and hidden exposure.

👉 Read Defakto Security's analysis of why service accounts are becoming a liability

Context

Service accounts were built as a convenience layer for non-human identities, not as a durable governance model for modern workloads. The problem is that the identity lifecycle for applications and services is not the same as the human lifecycle, yet many programmes still manage both through directory patterns optimised for people.

That mismatch creates standing privilege, stale credentials, and orphaned access when workloads are retired, reconfigured, or handed across teams. For IAM and NHI teams, the issue is structural: if the lifecycle is wrong, the control plane is wrong too.

Key questions

Q: What breaks when service accounts are managed like human identities?

A: Lifecycle drift becomes the main failure mode. Human identity controls assume predictable onboarding and offboarding, but workloads are created, replaced, and retired much faster. That leaves service accounts with stale ownership, standing access, and no reliable retirement path, which turns old identities into active security exposure.

Q: Why do service accounts with standing privilege increase lateral movement risk?

A: Because a stolen secret is not just an authentication token, it is a ready-made access path. If the account still has broad permissions, the attacker can use the legitimate identity to reach additional systems, cloud resources, or sensitive data without needing to escalate through more obvious exploit steps.

Q: How do teams know if machine identity governance is actually working?

A: Look for evidence that each service account has a current owner, a narrow purpose, a short credential lifetime, and a clear retirement path. If any of those are missing, the programme may appear controlled on paper while still leaving durable access paths in production.

Q: Who is accountable when an orphaned service account is abused?

A: Accountability should sit with the business or engineering owner of the workload, not only the directory team. If no one can explain why the account still exists, who depends on it, and when it will be retired, the governance model has already failed before the incident occurs.

Technical breakdown

Why service account lifecycle breaks at workload speed

Service accounts are usually provisioned into directories that assume slow, human-paced change. Workloads, by contrast, are ephemeral, frequently redeployed, and often re-scoped without a formal offboarding step. That means identity state becomes detached from operational reality. When ownership, deployment context, and runtime need change faster than directory records, access lingers after the workload that needed it has moved on. The result is not just clutter. It is a control failure where old permissions remain valid after their business purpose has disappeared.

Practical implication: treat workload identity as a separate lifecycle and stop relying on human offboarding processes to clean up machine access.

Long-lived secrets and standing access create durable attack paths

A service account becomes especially risky when it carries a secret that does not expire quickly and privileges that are broader than the workload requires. Long-lived credentials can be leaked in code, copied into pipelines, or forgotten in environment variables, while standing access gives an attacker a ready-made path once the secret is found. The problem is compounded when monitoring is weak, because the account may look legitimate even while it is being abused. This is why account sprawl becomes breach amplification.

Practical implication: reduce the lifetime and scope of machine credentials, then verify that every secret has an owner, a purpose, and a retire date.

Accountless, attestable identities replace static accounts with runtime proof

Accountless identity shifts the model from pre-created credentials to runtime attestation. In that pattern, the workload proves identity, origin, and integrity when it starts, and authorization is issued from current context rather than from a dormant directory object. This removes the need for stored secrets in many cases and breaks the assumption that a machine identity must be represented by a persistent account. The architectural change is significant because it aligns the identity system with how workloads actually behave: transient, dynamic, and frequently re-deployed.

Practical implication: evaluate where runtime attestation can replace persistent service accounts, especially for workloads with frequent redeployment or narrow trust boundaries.

Threat narrative

Attacker objective: The attacker wants durable access through a credentialed identity that security teams have stopped actively governing.

1. Entry often begins when a forgotten service account secret is leaked in a repository, pipeline, or configuration file, giving an attacker a valid path into the environment.
2. Escalation follows when the account still has standing or over-permissioned access, allowing the attacker to move from legitimate authentication to broader system control.
3. Impact occurs when the orphaned account is used as a backdoor for data access, cloud abuse, or lateral movement across dependent systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human lifecycle controls were never designed for machine identities. Service accounts persist because the governance model assumes onboarding, job change, and termination events, but workloads do not follow those rhythms. Their context changes through deployment, reconfiguration, and retirement, which means ownership and access drift long before a human-style review catches it. The practitioner conclusion is straightforward: if the lifecycle model is wrong, the access model will drift too.

Standing privilege in service accounts is the control gap that turns convenience into exposure. This article describes a familiar failure mode where broad permissions remain attached to identities that are rarely used but always valid. That breaks the least-privilege premise because the account stays ready for abuse even when the workload no longer needs the access. Practitioners should recognise this as a governance defect, not just an inventory issue.

Accountless attestable identity is the right architectural response because it removes the persistent account assumption. Service-account governance tries to clean up a structure that should not exist in the first place for many workloads. When a workload can prove its identity at runtime, the security model no longer depends on stored secrets or static directory objects surviving between executions. The practitioner conclusion is to re-evaluate where persistent accounts are still justified and where they are only carrying legacy risk.

Identity blast radius becomes the right field-level concept for this problem. Each orphaned or over-privileged service account increases the blast radius of a single leaked secret, because the attacker inherits both authentication and access scope at once. That is why this issue sits squarely in NHI governance, not just secrets management. The practitioner conclusion is to measure how far a compromised machine identity can travel before detection or revocation.

OWASP-NHI and NIST-CSF align naturally here because the control failure is about lifecycle, visibility, and privilege management. The article is not really about better directory hygiene. It is about replacing a human-centric identity paradigm with one that matches workload behaviour. The practitioner conclusion is to treat service accounts as a transitional pattern, not a default end state.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Nearly 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to the same report.
• That gap in visibility is why teams should also read NHI Lifecycle Management Guide when replacing directory-centric machine identity practices.

What this signals

Identity blast radius is now the more useful design metric than identity count. When a machine identity persists after the workload that created it has changed, the question is not how many accounts exist, but how much damage one account can still do. In practice, that shifts attention toward entitlement scope, ownership clarity, and the retirement path for every service account.

The market signal is clear: organisations are starting to accept that account-based machine identity is a transitional control, not a durable operating model. That will push more teams toward runtime attestation, tighter lifecycle integration, and security reviews that examine whether a workload still deserves a persistent identity at all.

For practitioners, the immediate challenge is to stop treating service-account cleanup as an occasional hygiene exercise. The real work is to design controls that remove standing access, surface abandoned identities, and ensure the directory does not become the default cemetery for machine credentials.

For practitioners

• Separate workload lifecycle from human lifecycle Map service accounts, their owners, and their runtime dependencies separately from employee joiner-mover-leaver processes. Do not assume HR-triggered offboarding will clean up machine identities or remove stale access after a workload is retired.
• Inventory standing privilege on every service account Identify accounts that retain broad permissions even when they are rarely used. Prioritise those with access to production data, cloud control planes, and CI/CD systems, then tie each entitlement to a documented business purpose.
• Rotate or eliminate long-lived secrets Replace persistent credentials with short-lived, workload-bound authentication wherever possible. Where secrets remain necessary, enforce ownership, expiry, and rotation discipline so leaked credentials do not remain valid for months.
• Pilot accountless attestation for transient workloads Start with high-churn services that redeploy frequently or already rely on runtime trust signals. Use attestation to prove workload identity at start-up instead of issuing a durable account and secret that must later be revoked.

Key takeaways

• Service accounts become liabilities when human-centric lifecycle controls are used to govern workloads that change on engineering time.
• The scale of the problem is visible in real breaches, where forgotten service accounts and long-lived secrets create durable access paths for attackers.
• Practitioners should move toward attested, accountless models where possible and reduce the number of persistent machine identities that need ongoing cleanup.

Key terms

• Service Account: A service account is a non-human identity used by applications, scripts, or workloads to authenticate to systems and data. In practice, it often becomes risky when ownership is unclear, privileges are broad, and the account outlives the workload it was created for.
• Accountless Identity: Accountless identity is a model where a workload proves who it is at runtime instead of relying on a persistent directory account and long-lived secret. It reduces static credential exposure and better matches short-lived, dynamic infrastructure patterns.
• Runtime Attestation: Runtime attestation is the process of cryptographically proving a workload's identity, origin, or integrity when it starts executing. It replaces assumptions about static trust with current evidence, which is especially useful when workloads are frequently redeployed or rescheduled.
• Identity Blast Radius: Identity blast radius describes how much damage an abused identity can cause before it is detected or revoked. For machine identities, it is driven by secret lifetime, privilege scope, and the number of connected systems that still trust the account.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Defakto Security: Identity Service Accounts Were a Shortcut. Now They’re a Liability. It’s time to go Accountless. Read the original.