Why do service accounts create such a large Kerberoasting exposure?

Why This Matters for Security Teams

service account are not dangerous because they exist. They become dangerous when they are allowed to persist, accumulate privileges, and keep SPNs without the same review discipline applied to human users. Kerberoasting turns that neglect into a measurable exposure: any valid domain user can request a service ticket, and the attacker can work on cracking it offline. That means detection often happens after the ticket has already been harvested, not when the account was created or its password age drifted past policy. NHIMG research shows this is part of a broader non-human identity problem, with 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Why NHI Security Matters Now both showing how often service accounts and other NHIs are the weak link in real incidents. The operational risk is not just credential theft, but lateral movement into application tiers, data stores, and privileged workflows. In practice, many security teams encounter Kerberoasting only after the crackable ticket has already been collected and the service account has already become an escalation path.

How It Works in Practice

Kerberoasting succeeds because Kerberos allows a requester to ask the domain controller for a service ticket tied to an SPN, then attempt offline password cracking against the encrypted blob. That means the attacker does not need direct service access, and the service itself may never show an obvious compromise. A weak or reused service account password, especially one that is long-lived and shared across environments, increases the chance of recovery from offline cracking. This is why current guidance pushes teams toward short-lived secrets, tighter review, and service-account minimisation rather than assuming RBAC alone will contain the risk. NIST’s Zero Trust Architecture guidance supports the broader principle that access should be continuously evaluated, not granted as a durable entitlement. Practitioners usually reduce exposure by combining several controls:

• Replace weak passwords with managed, randomised secrets or gMSA where feasible.
• Remove unnecessary SPNs and split high-value services into separate identities.
• Use PAM and JIT processes so privileged service credentials are issued only when needed.
• Rotate secrets on a defined schedule and shorten validity windows wherever the application allows.
• Track where service accounts authenticate, which hosts they reach, and whether the account should even exist.

This aligns with NHIMG reporting that only 5.7% of organisations have full visibility into service accounts, a visibility gap discussed alongside broader secret sprawl in the Guide to the Secret Sprawl Challenge. For attack-path context, the Anthropic report Anthropic — first AI-orchestrated cyber espionage campaign report is a useful reminder that automation increases the speed at which harvested credentials can be operationalised. These controls tend to break down in legacy Windows estates where SPNs are duplicated, passwords are static for years, and application owners refuse to tolerate rotation outages.

Common Variations and Edge Cases

Tighter service-account control often increases operational overhead, requiring organisations to balance blast-radius reduction against application fragility and recovery time. That tradeoff is real: some older systems cannot tolerate frequent password rotation, some vendor apps hard-code service credentials, and some environments depend on shared identities to keep batch jobs running. Best practice is evolving here, and there is no universal standard for how often every service account should rotate; the right cadence depends on criticality, recoverability, and whether JIT or gMSA can be used. There are also edge cases where Kerberoasting is not the primary concern. If the service account is backed by a managed platform identity, or the SPN is removed entirely, the attack surface changes materially. Likewise, if an organisation has strong detection for unusual ticket requests, the risk shifts from initial harvesting to post-crack usage. NHIMG’s The 52 NHI breaches Report shows that compromise usually becomes severe when weak lifecycle controls combine with excessive privilege, not when one control fails in isolation. For teams modernising toward Zero Trust, the practical goal is to treat service accounts as workload identities with explicit ownership, visible purpose, and revocation paths, rather than as invisible infrastructure leftovers. Where applications still require static credentials, compensating controls such as isolation, constrained delegation, and aggressive monitoring become essential, but they are second-best options rather than a durable design pattern.

Related resources from NHI Mgmt Group

• Why can a single SaaS app create such a large blast radius?
• Why do stale service accounts create such a large security risk?
• 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?