Who is accountable when Kerberoasting succeeds in a domain environment?

Why This Matters for Security Teams

Kerberoasting is not just a technical exploit against a service principal name. It is a governance failure that exposes how well identity ownership, service account hygiene, and monitoring are actually working. When an attacker can request Kerberos tickets and crack weak service account passwords offline, the immediate failure is usually not one control, but a chain of weak ownership decisions across AD, IAM, and application teams. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as access control, authentication, and auditability working together rather than as a single product setting.

For security leaders, the accountability question matters because Kerberoasting tends to succeed where service accounts are inherited, passwords are long-lived, and encryption settings are left unchanged for compatibility. That is why NHI Management Group treats it as an identity control failure, not only an intrusion event. The operational lesson is reinforced by The State of Secrets in AppSec, which shows how fragmented secret management and weak developer practices persist even in mature programmes. In practice, many security teams learn who owns a service account only after an attacker has already cracked it and moved laterally.

How It Works in Practice

Accountability for Kerberoasting usually lands with the teams that control the attack surface the technique depends on: identity governance for account lifecycle, Active Directory administrators for Kerberos and encryption policy, and application owners for service account use. The practical failure mode is predictable. A service account gets created for one application, set to a weak or never-rotated password, granted elevated rights, and then forgotten. An attacker with domain access requests a ticket, extracts the service hash, and attempts offline cracking without triggering the same controls that would stop an interactive login.

Good practice starts with ownership clarity. Every SPN should map to a named business owner, a technical owner, and a review cadence. Service accounts should use long, random passwords or managed identities where possible, and where legacy systems block that, the exception should be documented and time-bound. Current guidance also favours reducing RC4 exposure, tightening Kerberos encryption settings, and monitoring for abnormal ticket requests and ticket-granting service behaviour. The implementation logic aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls and with the identity-centric lessons surfaced in DeepSeek breach, where exposed credentials and poor containment quickly became an enterprise problem.

• Inventory every SPN and service account, then assign a human owner.
• Review password age, entropy, and rotation exceptions for all high-value accounts.
• Prefer managed service accounts or equivalent mechanisms where the platform supports them.
• Alert on unusual ticket requests, unusual source hosts, and repeated offline-cracking indicators.

These controls tend to break down in legacy domain environments where applications cannot tolerate password rotation, encryption upgrades, or managed identity migration because business continuity is prioritised over identity hygiene.

Common Variations and Edge Cases

Tighter service account control often increases operational overhead, so organisations must balance attack resistance against application compatibility and support burden. That tradeoff is most visible in older domains, third-party software, and industrial or regulated environments where Kerberos settings cannot be changed quickly. In those cases, accountability does not disappear; it becomes more important to document which team accepted the risk, what compensating controls exist, and when the exception will be removed.

There is no universal standard for assigning accountability in mixed on-prem and cloud estates, but current guidance suggests the owner of the identity control should be the first accountable party, followed by the system owner that consumes the account. If the same service principal is reused across multiple applications, accountability becomes shared and therefore easier to evade unless ownership is formally recorded. Security teams should be especially careful with environments that still rely on RC4-compatible settings, because those configurations expand the number of accounts that can be roasted. The broader lesson from The State of Secrets in AppSec is that fragmented ownership and weak remediation habits are common, and they rarely improve without explicit governance pressure.

Related resources from NHI Mgmt Group

• Who is accountable when Pass the Hash succeeds in a Windows domain?
• Who is accountable when AD confusion leads to domain compromise?
• Who is accountable for security and compliance when SAP data is moved into a new environment?
• Who should be accountable for access governance when enterprise API tools use SCIM, domain capture, and domain lock together?