Why do service accounts and delegation settings create so much risk in Active Directory?

Service accounts often run with persistent privileges and weak password practices, while delegation settings can let an attacker reuse authentication material or impersonate trusted systems. Together, they create low-noise paths to escalation that do not depend on malware. The risk is not the account name itself, but the effective access it can provide if abused.

Why This Matters for Security Teams

Service accounts and delegation settings are risky because they often sit outside the normal human-identity lifecycle. They are created to keep systems running, not to be reviewed like employee access, so they accumulate privileges, live too long, and are rarely tied to a clear owner. That makes them ideal for stealthy escalation, especially when an attacker can replay delegated trust instead of dropping malware. The broader pattern is well documented in the Ultimate Guide to NHIs — Key Challenges and Risks and in the Cisco Active Directory credentials breach, where identity misuse turned into enterprise impact without a noisy initial foothold.

The operational mistake is assuming “service” means “low risk.” In active directory, service accounts can authenticate to critical systems, and delegation can turn that authentication into lateral movement or impersonation. Current guidance from NIST Cybersecurity Framework 2.0 still points teams toward least privilege, asset visibility, and ongoing access governance, but those principles only work if NHIs are actually inventoried and reviewed. In practice, many security teams encounter delegated trust abuse only after an unexpected admin-level action has already occurred, rather than through intentional review.

How It Works in Practice

The risk usually comes from three mechanics working together. First, service accounts often hold persistent permissions because applications and schedulers depend on them. Second, passwords or keys are frequently long-lived, embedded in code, stored in scripts, or left in configuration files. Third, delegation settings can let one account act on behalf of another, which means a compromised service account can inherit trust it never earned directly.

This is why organisations should treat these identities as a distinct NHI class, not as a special case of user access. The Top 10 NHI Issues highlights that excessive privilege and poor visibility are routine failure points, and the fact that 97% of NHIs carry excessive privileges, from Ultimate Guide to NHIs — What are Non-Human Identities, shows how normalised over-entitlement has become. Practically, teams should:

• inventory every service account and link it to a workload owner
• separate interactive admin accounts from non-interactive service identities
• restrict Kerberos delegation to only the exact services that need it
• replace standing secrets with short-lived secrets and JIT credential issuance where possible
• monitor for unusual service-to-service authentication paths and token reuse

Where possible, pair RBAC with just-in-time access and Zero Trust checks so a delegated action is approved at request time, not assumed forever. That approach aligns with NIST Cybersecurity Framework 2.0 and the broader zero trust direction in modern identity programs. These controls tend to break down when legacy applications require unconstrained delegation or when ownership of the service account is unclear, because remediation stalls before privilege can be reduced.

Common Variations and Edge Cases

Tighter delegation control often increases operational overhead, so organisations have to balance application continuity against exposure reduction. That tradeoff is most visible in older Windows estates, domain migrations, and vendor-managed systems where teams fear breaking production if they change trust settings too quickly.

There is no universal standard for this yet, but current guidance suggests treating constrained delegation, JIT issuance, and workload identity as the safer default where the platform supports them. For high-value services, a workload identity model gives stronger assurance than a shared password because the credential proves what the system is, not merely what secret it knows. This is the direction reflected in modern identity guidance and in the 52 NHI Breaches Analysis, which repeatedly shows that credential sprawl and weak governance turn ordinary service accounts into breach paths.

Edge cases deserve special handling: backup systems, batch jobs, and cross-domain trusts may still require standing access, but that should be exceptional and time-bound, with explicit logging and compensating controls. The practical question is not whether delegation exists, but whether it is narrowly bounded, observable, and revocable. Mature programmes also use NIST Cybersecurity Framework 2.0 to align recovery, monitoring, and access review so delegated trust does not become permanent trust.

Related resources from NHI Mgmt Group

• Why do Active Directory service accounts create more risk than their labels suggest?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why do service accounts create so much hidden risk in SaaS stacks?