By NHI Mgmt Group Editorial TeamPublished 2025-07-22Domain: Workload IdentitySource: Semperis

TL;DR: Compromised service accounts sit at the centre of destructive breaches, with Semperis citing the Merck NotPetya case where initial access came through a patching account and damages exceeded $1.4 billion. The lesson is that static passwords, excessive privilege, and forgotten identities turn routine machine accounts into durable breach paths.


At a glance

What this is: This is a Semperis analysis of why service accounts are high-risk identities and how discovery, monitoring, response automation, and attack path analysis reduce exposure.

Why it matters: It matters because service accounts span NHI, hybrid directory, and lifecycle governance, so IAM teams need controls that find stale identities, reduce standing privilege, and respond before attackers can pivot.

By the numbers:

👉 Read Semperis's analysis of service account protection and AD attack paths


Context

Service accounts are non-human identities that run core business processes without a person actively driving each action. The security problem is not just that they exist, but that they often accumulate static passwords, broad permissions, and weak ownership over time, which makes them attractive entry points for attackers.

In hybrid environments, service accounts sit inside identity systems, directories, and workflow chains that many teams only partially inventory. That creates a lifecycle problem as much as a security problem, because forgotten accounts and unclear purpose make it hard to judge whether access is still justified or whether it should be removed.

For IAM and security teams, the practical issue is not discovery alone. The challenge is connecting inventory, privilege scope, monitoring, and response so that service accounts are governed as active identities rather than legacy artefacts. That is where lifecycle discipline and attack path visibility converge.


Key questions

Q: How should security teams govern service accounts with standing privilege?

A: Treat them as governed identities with owners, scope, and lifecycle states, not as technical leftovers. Start by mapping each account to a workload, removing unused permissions, and forcing a retirement decision for anything without a clear business purpose. Standing privilege is dangerous because it gives attackers a trusted path if credentials are exposed.

Q: Why do forgotten service accounts increase breach risk?

A: Forgotten accounts are risky because no one knows who owns them, what they do, or whether their access is still justified. That makes it easy for stale credentials and excessive privileges to persist long after the original application has changed or been retired. Attackers benefit from the same invisibility that frustrates defenders.

Q: What breaks when service account monitoring is only periodic?

A: Periodic review misses the period when attackers can exploit changes, because service accounts often move from normal to risky state faster than a quarterly or monthly control can see. A one-time snapshot also fails to catch newly created, misconfigured, or reclassified accounts that have already become part of the attack surface.

Q: Who is accountable when a compromised service account causes an incident?

A: Accountability should sit with the account owner, the workload owner, and the identity team that approved the entitlement, because all three shape the account's risk. Frameworks such as the NIST Cybersecurity Framework 2.0 support that split by tying access governance to operational ownership and response. Without clear ownership, service account remediation stalls.


Technical breakdown

Why static passwords make service accounts durable targets

Service accounts often use credentials that are difficult to change without breaking applications, which encourages long-lived secrets and weak rotation discipline. Once attackers obtain those credentials, the account can behave like a trusted system identity and bypass normal user-facing controls. Excess privilege increases the blast radius because the account can interact with infrastructure, directories, or business applications that assume the caller is legitimate. The risk is not only compromise but persistence, because the account may remain valid long after its original purpose is forgotten.

Practical implication: inventory service accounts with static credentials and set ownership, rotation, and retirement rules before the next audit cycle.

How continuous discovery and object lists reduce identity blind spots

Discovery matters because many environments contain service accounts that are stale, duplicated, misconfigured, or missing from central records. Continuous discovery turns service account governance from a snapshot exercise into an ongoing control, while object lists help security teams group related AD objects for monitoring, reporting, and rule creation. The mechanism is simple: if you can classify the account population accurately, you can detect drift sooner and focus controls on the identities that matter most. This is especially useful in directory-heavy environments where the attack surface changes faster than manual reviews can track.

Practical implication: build dynamic object groupings for service accounts and use them to drive change detection, review scope, and exception handling.

What automated rollback changes in incident response

Automated response rules matter because attackers can move from suspicious activity to damage faster than a human analyst can triage an alert. A rollback action can reverse a risky directory change, while disabling an account can stop an active misuse path before it spreads. This is not a replacement for investigation, but it changes the response window from after-the-fact containment to near-real-time interruption. The important architectural point is that response logic becomes part of identity protection, not just the SOC workflow.

Practical implication: predefine which service account behaviours trigger rollback, disablement, or ticketing so response is not improvised during an incident.


Threat narrative

Attacker objective: The attacker objective was to turn a trusted service account into a foothold that enabled wider destructive movement inside the victim environment.

  1. Entry occurred when attackers compromised a service account used for OS patching, giving them a trusted machine identity instead of a user login.
  2. Escalation followed through the account's legitimate privileges, which let the attackers operate inside the environment with the authority needed to spread and disrupt systems.
  3. Impact came when the compromise contributed to the NotPetya attack against Merck, where the breach produced major business disruption and damages exceeding $1.4 billion.

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


NHI Mgmt Group analysis

Service account governance fails when identity is treated as infrastructure rather than as a living access population. Semperis is right to frame service accounts as breach-critical identities, because static credentials, excessive privilege, and forgotten ownership create a durable attack surface. The field problem is not simply that service accounts exist, but that many programmes still manage them as side assets outside normal identity governance. Practitioners need to treat service accounts as governed identities with owners, lifecycle states, and reviewable scope.

Attack path visibility is now a control, not an after-action report. When service accounts sit inside complex Active Directory relationships, privilege escalation often follows the shortest graph path rather than the most obvious one. That means the meaningful question is no longer whether a service account is present, but whether its relationships create an exploitable path into higher-value systems. Practitioners should use attack path analysis to identify which accounts can become breach multipliers before they are abused.

Automated rollback exposes a broader identity operations truth: response speed has become part of access control. If a misbehaving service account can be disabled or reversed before damage occurs, then identity security is no longer limited to prevention and detection. The control gap is the delay between alert and action, especially in directories where changes propagate quickly. Practitioners should design response rules as first-class governance logic, not as optional SOC tooling.

Legacy service accounts create trust debt that compounds as people leave and systems age. Semperis describes accounts created decades ago by employees who have retired, and that is a classic lifecycle failure mode. This is not just inventory debt, it is accountability debt: access remains in place even after the human memory of why it exists has disappeared. Practitioners need to assume that any unowned service account is already a governance incident waiting to be exploited.

Hybrid directory security now depends on collapsing the gap between AD visibility and Entra ID response. The post shows that modern identity attack surfaces span both on-premises and cloud directory layers, so siloed controls miss real attack paths. A control model that cannot correlate changes across both planes will miss the moments when attackers pivot or persist. Practitioners should align monitoring, rollback, and tamperproof logging across the full directory estate.

From our research:

What this signals

Service account risk is now a governance, not a tooling, problem. The organisations that keep discovering hidden machine identities are the ones that can no longer rely on point-in-time inventory or periodic recertification alone. With two-thirds of enterprises already suffering compromise from non-human identities, the signal is clear: the control model must shift toward continuous ownership, scope review, and response readiness.

Identity teams should expect service account oversight to merge with attack-path management. As directory structures become more complex, the question is not whether an account exists but whether it can be used to reach privileged systems. That is why practitioners need to pair operational controls with resources such as the 52 NHI Breaches Analysis to understand repeat failure modes across real incidents.


For practitioners

  • Assign owners to every service account Create a named business and technical owner for each account, including an escalation path for orphaned identities. Use that ownership to force decisions on rotation, retirement, and exception handling.
  • Reduce standing privilege on machine identities Review each account's permissions against actual workload needs and remove any access that is not required for the current application state. Prioritise accounts that can reach directory, patching, or administrative functions.
  • Build continuous discovery into identity operations Use ongoing discovery and object grouping to surface unknown, stale, and misconfigured service accounts before they become hidden entry points. Reconcile what is found against approved inventories and retirement records.
  • Predefine automated containment actions Map suspicious service account behaviours to rollback, disablement, and ticket creation so the first responder is the control plane, not a manual workflow. Test those actions against benign changes before allowing them in production.
  • Use attack path analysis for directory risk Trace which service accounts can lead to high-value assets through group membership, delegation, or inherited permissions. Focus remediation on the paths that would let an attacker pivot from a low-value account to a privileged outcome.

Key takeaways

  • Service accounts are not secondary identities. They are high-value access paths that can power major breaches when ownership, privilege, and lifecycle controls are weak.
  • The Merck NotPetya example shows the scale of the issue, with service account compromise contributing to damages exceeding $1.4 billion.
  • Teams should combine discovery, attack-path analysis, and automated containment so service account risk is managed continuously rather than reviewed after the fact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01Service account discovery and protection map directly to NHI inventory and exposure control.
NIST CSF 2.0PR.AC-4Least privilege and access review are central to the service account risk described here.
NIST Zero Trust (SP 800-207)PR.AC-4Continuous verification and reduced trust fit the article's focus on hidden machine identities.

Inventory service accounts, classify ownership, and remove any account that cannot be tied to a live workload.


Key terms

  • Service Account: A service account is a non-human identity used by applications, scripts, or platform components to authenticate and access resources. Unlike a person, it should exist only for a defined workload and should be governed by ownership, scope, and lifecycle controls so its access remains auditable and justified.
  • Standing Privilege: Standing privilege is access that remains continuously available rather than being granted just for a specific task. For service accounts, it creates a persistent blast radius because an exposed credential can be reused at any time until the entitlement is removed or the account is retired.
  • Attack Path Analysis: Attack path analysis maps the relationships and permissions that let an attacker move from one identity or system to a more valuable target. In directory-heavy environments, it is used to find the shortest exploitable route from a low-value account to privileged access before defenders learn the hard way.
  • Identity Attack Surface: Identity attack surface is the set of accounts, permissions, trust relationships, and misconfigurations that can be used to compromise an identity system. For machine identities, it includes stale accounts, forgotten credentials, inherited rights, and directory relationships that defenders may not review often enough.

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 Semperis: Why is securing service accounts essential for reducing breach risk? Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-07-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org