Service account security gaps in Active Directory keep widening

At a glance

What this is: This is an analysis of why service accounts in Active Directory remain hard to govern and how their visibility, rotation, privilege, and logon controls fail in practice.

Why it matters: It matters because service account weakness can undermine NHI governance, privilege management, and broader identity control coverage across both machine and human identity programmes.

👉 Read Semperis' analysis of why service accounts are so difficult to secure

Context

Service accounts are non-human identities that authenticate applications, tools, and backend services in Active Directory. The governance problem is that they are frequently created for operational convenience, then left in place long after the system or team that created them has changed.

That pattern creates a large, persistent identity surface where access is hard to inventory, difficult to rotate, and easy to over-privilege. For IAM and PAM teams, service account security is not a niche admin issue. It is a lifecycle and blast-radius problem that affects discovery, ownership, credential hygiene, and control assurance.

Key questions

Q: How should security teams inventory service accounts in Active Directory?

A: Start by discovering every service account, then assign each one an owner, purpose, privilege level, and dependent system. Remove orphaned or unused accounts, and keep the inventory continuously updated so retired applications do not leave behind unmanaged identities that still have access.

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

A: Because they often hold access beyond what one application truly needs, a compromised service account can move from a small operational trust boundary into broader administrative reach. The risk grows when those accounts are unmonitored, reused across systems, or protected by static credentials.

Q: What breaks when service account passwords are hard-coded in scripts or applications?

A: Rotation becomes slow, inconsistent, and sometimes impossible without breaking production workflows. That leaves one exposed secret reusable across multiple systems, which gives an attacker a durable foothold if the file, script, or memory dump is compromised.

Q: Who is accountable when a service account compromise disrupts business operations?

A: Accountability should sit with the system owner and the identity governance function together, because service accounts are lifecycle assets tied to applications, not just technical credentials. If no owner can explain why the account still exists, the governance model has already failed.

Technical breakdown

Why service account discovery and ownership break down

Service accounts become difficult to secure when their existence is distributed across decades of application change, infrastructure growth, and informal ownership. In AD environments, accounts often outlive the systems that use them, and the original business owner may no longer be identifiable. That makes central inventory the first technical control problem, not an optional hygiene task. Without clear classification by purpose, privilege, and dependency, security teams cannot tell whether an account is active, orphaned, or exposed through a retired application path.

Practical implication: maintain a centralized inventory that ties every service account to an owner, system, and business purpose.

Static service account credentials and hard-coded secret risk

Static passwords are the most common failure mode because they turn a service account into a long-lived secret rather than a governed identity. When passwords are embedded in scripts, config files, or applications, rotation becomes operationally expensive and sometimes avoided altogether. That creates a durable compromise window, especially when the account cannot use MFA and may be reused across systems. In AD, exposed service account credentials also increase exposure to password spraying and Kerberoasting because attackers only need one recoverable secret to pivot deeper into the environment.

Practical implication: eliminate embedded credentials where possible and treat every hard-coded secret as an immediate exposure path.

Excessive privilege turns service accounts into escalation paths

Service accounts are frequently over-permissioned because application teams optimise for functionality instead of delegation precision. The result is identity sprawl with weak authorization boundaries, where one compromised account can unlock movement across multiple systems. In practice, this is less about a single bad password and more about a broken entitlement model. When service account activity is also lightly monitored, compromise can remain invisible until an attacker has already escalated or moved laterally. The technical problem is not just access, but unreviewed access scope.

Practical implication: enforce least privilege and alert on unusual service account behaviour before privilege escalation occurs.

Threat narrative

Attacker objective: The attacker wants a durable foothold that can be reused to expand access inside Active Directory and undermine enterprise identity control.

1. Entry occurs when an attacker finds a service account password embedded in a script, application, or other exposed configuration artifact.
2. Escalation follows when the account has standing privileges that allow the attacker to move laterally or increase access inside Active Directory.
3. Impact emerges when the compromised account provides enough trust to disrupt operations, deepen access, or enable broader environment takeover.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 ownership is assumed rather than proven. The article shows how accounts remain in place because no one is clearly responsible for their lifecycle after application onboarding. That is a governance failure, not just an inventory problem, because accountability disappears as systems age. Practitioners should treat ownership as a control boundary, not an administrative note.

Static credential persistence is the real identity risk, not password age alone. A service account with a rarely changed password behaves like a standing secret with broad reuse potential, especially when it is embedded in code or scripts. The exposure is structural because the credential can outlive the application path that created it. Practitioners should recognize that password rotation is only one part of the control story.

Excessive privilege turns operational convenience into a durable identity blast radius. Service accounts are often granted more access than they need because teams optimise for uptime, not delegation precision. Once that privilege is combined with weak monitoring, the environment has created a hidden escalation route. Practitioners should treat every over-permissioned service account as a potential lateral-movement amplifier.

Standing access assumptions were designed for stable application boundaries. That assumption fails when service accounts are copied across systems, reused for years, and left unmanaged after applications are retired. The implication is that lifecycle governance must be tied to the application and its owners, not only to the account record itself.

Identity security programmes cannot claim maturity while service accounts remain partially invisible. The article describes a control environment where discovery, monitoring, and access restriction are all incomplete. That combination means the organisation may know service accounts exist but still not know how they behave. Practitioners should treat service account visibility as a prerequisite for any meaningful NHI programme.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That lifecycle gap makes 52 NHI Breaches Analysis a useful next reference for understanding how unmanaged identities turn into incidents.

What this signals

Service account visibility is the control that separates governance from guesswork. If teams cannot reliably locate accounts, they cannot prove ownership, prove privilege scope, or prove that retirement removed access. The next programme milestone is not another policy statement, but an identity inventory that is current enough to drive enforcement.

The operational signal to watch is whether the organisation can connect each service account to a living application dependency and a named owner. If that link is missing, offboarding, rotation, and recertification all become partially fictional exercises.

With 91.6% of secrets still valid five days after disclosure according to the State of Secrets in AppSec, service account remediation has to be measured in operational time, not policy intent.

For practitioners

• Build a live service account inventory Map every service account to an owner, business purpose, authentication method, and dependent system. Remove orphaned and unused accounts, then keep the inventory current as applications are retired or replaced.
• Replace embedded credentials with governed storage Scan scripts, scheduled tasks, and applications for hard-coded passwords, then move those secrets into secure storage or managed service account patterns where feasible.
• Reduce privilege to the minimum functional scope Review service account entitlements against actual application requirements and remove broad administrative access unless a specific dependency proves it is unavoidable.
• Monitor for abnormal service account behaviour Alert on unexpected hosts, odd hours, unusual authentication paths, and service account activity that does not match known application patterns.
• Restrict where service accounts can authenticate Use logon restrictions and network scoping so each account can only access the servers and backend services it actually needs.

Key takeaways

• Service accounts remain a high-risk identity class because they are business-critical, hard to inventory, and often left unmanaged after systems change.
• Static secrets and excessive privilege combine to make service accounts durable attack paths rather than simple backend credentials.
• The decisive control is lifecycle governance tied to ownership, inventory, rotation, and access restriction, not just ad hoc hardening.

Key terms

• Service Account: A service account is a non-human identity used by applications, scripts, and infrastructure components to authenticate to other systems. In Active Directory, it often has standing access and long-lived credentials, which makes ownership, rotation, and monitoring essential to prevent silent reuse or compromise.
• Hard-Coded Credential: A hard-coded credential is a secret embedded directly in code, configuration, or automation rather than stored in a managed secrets system. For service accounts, this usually means a password that is difficult to rotate and easy for attackers to extract from files, memory, or build artifacts.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. For service accounts, it creates persistent attack surface because a compromised identity can often move laterally or escalate without any additional approval or time-bound restriction.

Deepen your knowledge

NHI governance, machine identity security, and secrets management 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 lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: Why are service accounts so difficult to secure? How to close the service account security gap. Read the original.