Who should own Kerberoasting risk in an identity programme?

Ownership should sit with IAM, directory administrators, and application owners together, because the attack spans account lifecycle, authentication, and workload dependency. Security teams need a named owner for each service identity, a clear decommissioning path, and an agreed review cadence for privilege and encryption settings. Without that accountability, service-account risk stays invisible.

Why This Matters for Security Teams

Kerberoasting risk belongs to the identity programme because it lives where directory design, service-account hygiene, and application dependency management intersect. The attack is not just a password problem; it is a privilege and exposure problem that often persists in long-lived service identities. NHI Management Group’s Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which makes ownership gaps especially dangerous. The question is less about who detects the threat and more about who can change the conditions that make it possible.

Security teams frequently treat Kerberoasting as a SOC or threat-hunting issue because the compromise is adversarial and noisy. That framing misses the operational root cause: weak ownership over service principals, overprivileged accounts, stale encryption settings, and poor decommissioning discipline. The most useful control model is the one that assigns responsibility before exposure, not after ticket escalation. Current guidance from NIST Cybersecurity Framework 2.0 reinforces that identity risk must be governed as an enterprise capability, not as a narrow detection task. In practice, many security teams encounter Kerberoasting only after a service account has already been abused, rather than through intentional ownership review.

How It Works in Practice

Effective ownership is usually shared, but not ambiguous. IAM owns policy, lifecycle standards, and review mechanics. Directory administrators own the technical state of accounts, encryption types, SPNs, delegation settings, and disablement workflows. Application owners own business justification, dependency mapping, and the decision to retire or replace a service identity. That division matters because Kerberoasting is enabled by weak coordination more than by any single misconfiguration.

A practical programme usually includes:

• A named owner for every service principal or service account, with an escalation path when ownership is unclear.
• Regular review of Kerberos encryption settings and service-account privilege, with a clear remediation target for weak configurations.
• Decommissioning controls that remove orphaned accounts as part of application retirement, not as a separate cleanup project.
• Detection rules that feed ownership records so investigations can identify the accountable app or platform team quickly.

Those practices align with the lifecycle emphasis in Top 10 NHI Issues and the broader accountability lens in 52 NHI Breaches Analysis, both of which show how service identities become persistent attack surface when no one owns them end to end. NIST guidance on identity governance and risk management supports the same operational pattern: assign ownership, review routinely, and remove access when the business need ends. These controls tend to break down in legacy Windows environments with many inherited service accounts because ownership metadata is missing and application dependencies are poorly documented.

Common Variations and Edge Cases

Tighter ownership models often increase administrative overhead, requiring organisations to balance clarity against the friction of maintaining accurate records. That tradeoff is worth making, but the right structure varies by environment. In mature enterprises, a central identity team can enforce standards while app teams retain accountability for business justification. In smaller organisations, the same person may wear multiple hats, but the ownership model still needs to be explicit rather than implied.

There is no universal standard for this yet, but current guidance suggests a few common edge cases:

• Shared service accounts should still have a primary owner, even if multiple systems depend on them.
• Third-party managed applications need contract-level accountability, because the enterprise still inherits the risk.
• Legacy systems that cannot support modern Kerberos hardening should be tracked as exception items with expiry dates.
• Service accounts used by scheduled jobs or automation should be reviewed with the same cadence as privileged human accounts, because they often outlive the applications they support.

For organisations building a broader NHI governance programme, the practical lesson from Ultimate Guide to NHIs is that ownership only works when it is tied to lifecycle controls, visibility, and revocation. Where asset inventories are incomplete or identity records are decoupled from CMDB data, ownership can become symbolic rather than operational. In those environments, accountability breaks down fastest when application teams assume IAM is tracking the risk and IAM assumes the application team is remediating it.

Related resources from NHI Mgmt Group

• When does secret exposure become a broader identity risk?
• Who should own third-party access risk in an identity programme?
• Who should own vendor risk management in an identity programme?
• Who should own cryptographic risk in an identity programme?