How should security teams reduce Kerberoasting risk in Active Directory?

Reduce Kerberoasting risk by shrinking the number of SPN-backed accounts, removing SPNs that no longer support live workloads, and enforcing strong passwords with regular rotation. Then add monitoring for unusual ticket-request patterns so you can spot abuse quickly. The most effective defence is identity hygiene first, detection second.

Why This Matters for Security Teams

Kerberoasting remains dangerous because it turns ordinary active directory service account into a credential theft path that is cheap to attempt and hard to spot early. The risk is not just the attack itself, but the operational sprawl behind it: too many SPNs, passwords that stay unchanged for too long, and service accounts that survive long after the workload they supported has moved on. That is exactly the kind of identity debt highlighted in NHIMG research on the Top 10 NHI Issues and in the Cisco Active Directory credentials breach coverage, where exposed identity material can become a fast path to lateral movement.

Current guidance suggests treating Kerberoasting as an identity governance problem first and a detection problem second. NIST Cybersecurity Framework 2.0 still maps well here because access control, asset visibility, and continuous monitoring all need to work together, not as separate projects. The practical lesson is that teams must know which accounts are kerberoastable, why they exist, who owns them, and whether they still need SPNs at all. In practice, many security teams discover that a “legacy” service account was still in production only after an incident review, rather than through intentional lifecycle management.

How It Works in Practice

The strongest reduction in Kerberoasting risk comes from shrinking the attack surface before tuning detection. Start by inventorying every SPN-backed account, then classify each one by business function, owner, and dependency chain. If an SPN no longer supports a live workload, remove it. If the service can use a managed identity, gMSA, or another mechanism that reduces password exposure, migrate it. Where a passworded account must remain, use long, random passwords, rotate them on a defined schedule, and ensure the password policy is enforced consistently across domains and trusts.

Least privilege matters, but for Kerberoasting the key point is account quality rather than only role size. The attacker is targeting the password hash, so strong credentials and low account reuse reduce the payoff. Monitoring should focus on abnormal ticket-request patterns, especially repeated requests across many SPNs, requests from unusual hosts, and bursts that do not match the service account’s normal behaviour. Use the NIST Cybersecurity Framework 2.0 as the organising model, and pair it with NHIMG guidance in the Ultimate Guide to NHIs — Key Challenges and Risks and OWASP NHI Top 10, both of which emphasise lifecycle control and visibility as core defences. A useful operational pattern is to tie SPN ownership to a named system owner and require review during change management, not just during annual access recertification. These controls tend to break down in large AD estates with inherited trusts and unmanaged legacy applications because no single team can confidently assert ownership or password change impact.

• Remove unnecessary SPNs from accounts that no longer back active workloads.
• Prefer gMSA or managed identity patterns where the platform supports them.
• Use strong, unique passwords for unavoidable service accounts and rotate them regularly.
• Alert on unusual volume, timing, source, and diversity of Kerberos service ticket requests.
• Track owner, workload, and retirement date for every service account.

Common Variations and Edge Cases

Tighter password rotation and SPN reduction often increases operational overhead, so teams have to balance security gains against application fragility and change risk. That tradeoff is especially visible in environments with vendor-managed software, hard-coded credentials, or applications that cannot yet support modern identity patterns. There is no universal standard for how quickly every service account should rotate, but current guidance generally favours shorter lifetimes for higher-risk accounts and stronger controls for anything tied to broad domain access.

Some environments also confuse Kerberoasting with broader password hygiene and stop at periodic rotation alone. That is not enough if the account remains overexposed, overprivileged, or widely trusted across services. The Ultimate Guide to NHIs — Why NHI Security Matters Now and NIST Cybersecurity Framework 2.0 both point to a larger pattern: identity sprawl and weak lifecycle governance create avoidable exposure. In edge cases such as cross-forest authentication, shared service principals, or applications that require persistent delegation, the best answer may be compensating controls rather than immediate remediation. That typically means stronger monitoring, tighter admin boundaries, and a migration plan with explicit risk acceptance until the workload can be refactored.

Related resources from NHI Mgmt Group

• How should security teams reduce NTLM relay risk in Active Directory?
• How should security teams reduce the risk of password guessing attacks in Active Directory?
• How should security teams reduce ransomware risk from remote access credentials?
• How should teams reduce the risk of exposed AI credentials being abused?