Who is accountable when a relayable Kerberos service is exploited?

Why This Matters for Security Teams

Relayable Kerberos service abuse is not just an authentication flaw. It is an accountability problem that exposes where service ownership, platform hardening, and identity governance stop lining up. When a service accepts a relayed ticket, the failure is usually in the application or host configuration, not in the directory itself. That distinction matters because incident response, remediation, and control ownership all depend on it.

Security teams often miss the issue because Kerberos relay can look like “just another auth bypass” until lateral movement starts. The right question is which layer allowed unsigned, unconstrained, or unbound authentication to remain live. NIST’s control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls is helpful here because it separates identity assurance, access enforcement, and service configuration into different responsibilities. NHIMG’s 52 NHI Breaches Analysis shows the same pattern in NHI incidents: failures become visible only after trust assumptions have already been abused. In practice, many security teams encounter relay abuse only after a privileged service account has already been used to move laterally.

How It Works in Practice

Accountability for a relayable Kerberos service is shared, but the technical fault is usually local to the service and its hosting stack. The service owner is responsible for the application behavior, the platform team is responsible for host and network hardening, and the identity governance function is responsible for ensuring authentication expectations are actually enforced. If the service can be coerced into accepting relayed authentication, then the control gap sits where the service accepted the ticket or where the environment failed to bind the session to the original channel.

Operationally, that means teams should verify whether the service enforces signing, channel binding, SPN validation, and other protections that prevent ticket relay. They should also confirm whether delegation is constrained, whether authentication is mutual where required, and whether the service depends on legacy settings that preserve unsafe defaults. The practical test is simple: if an attacker can relay an otherwise valid Kerberos exchange into a different endpoint, then the control failed at the service boundary, not at the user’s credential boundary. For broader identity context, NHIMG’s Ultimate Guide to Non-Human Identities is useful because it frames why service identities must be governed as first-class assets, not as invisible plumbing.

• Service owners should document which Kerberos protections are required and which are optional.
• Platform teams should remove legacy authentication paths that allow unsigned or unbound traffic.
• Identity governance should require evidence that high-risk services cannot accept relayed authentication.
• Incident responders should treat relay as a service-layer control failure, not a directory compromise by default.

These controls tend to break down in hybrid environments with legacy Windows services, third-party appliances, or unmanaged integrations because the authentication path crosses systems that do not share a single enforcement point.

Common Variations and Edge Cases

Tighter Kerberos hardening often increases compatibility testing and operational overhead, so organisations have to balance stronger assurance against application fragility. That tradeoff is especially visible in older enterprise environments, where disabling a legacy setting can break a business-critical workflow.

There is no universal standard for every Kerberos relay scenario yet, so current guidance suggests using layered responsibility rather than arguing over a single owner. In some cases, the platform team is accountable for exposing a risky service configuration; in others, the service owner is accountable for accepting unsafe authentication patterns; and in heavily governed environments, identity governance may also share blame for approving exceptions without compensating controls. The key is to map the failure to the control that would have stopped the relay, not to the team that merely observed the attack. External control frameworks such as NIST SP 800-53 help structure that mapping, while NHIMG’s breach analysis shows how quickly ambiguity turns into delayed remediation. If the service was relayable because a vendor appliance could not support the required protection, then the exception itself becomes the accountability issue. If the service was relayable because hardening was never deployed, then the deployment owner is accountable for leaving the exposure in production.

In practice, accountability gets disputed most often when services are inherited, delegated across teams, or operated by a platform group that did not author the application but did control the runtime.

Related resources from NHI Mgmt Group

• Who is accountable when an exposed access appliance is exploited?
• Who is accountable when a default Windows service allows remote write abuse from low-privilege users?
• What are common vulnerabilities associated with service accounts in AI deployments?
• How should teams respond when a service account token is exposed?