Kerberos relay is the reuse of a valid Kerberos ticket against a different service endpoint that accepts it without sufficient binding to the original channel or target. It is a service-level failure mode, not a password theft problem, and it becomes practical when signing or channel binding is missing.
Expanded Definition
kerberos relay describes a condition where a valid Kerberos ticket is reused against a different service endpoint that accepts the ticket without enough binding to the original target or communication channel. In NHI and IAM practice, the problem is not that the ticket is forged or stolen from scratch, but that a legitimate credential can be replayed in a way the receiving service cannot distinguish from an intended request.
That makes Kerberos relay different from simple credential theft and closer to an authorization-context failure. The risk is highest when services trust Kerberos authentication but do not enforce protections such as service binding, channel binding, or tighter endpoint validation. Industry usage is still evolving across products and environments, so practitioners should treat the term as a class of relay-abuse conditions rather than a single protocol flaw. For broader NHI governance context, the Ultimate Guide to NHIs frames why service identities must be controlled as rigorously as human ones, and NIST Cybersecurity Framework 2.0 emphasizes identity and access controls as an operational safeguard. The most common misapplication is treating Kerberos relay like password capture, which occurs when teams focus on credential rotation instead of fixing the endpoint and channel conditions that let a valid ticket be accepted elsewhere.
Examples and Use Cases
Implementing Kerberos protections rigorously often introduces compatibility constraints, requiring organisations to weigh stronger binding guarantees against legacy service interoperability and rollout complexity.
- A Windows service accepts Kerberos authentication on an endpoint that is not strongly bound to the original service name, allowing a relayed ticket to be presented to the wrong backend.
- An internal application uses Kerberos but lacks channel binding, so a ticket captured in one trusted session context can be accepted in another context that should not have received it.
- A service account authenticates through a proxy or gateway that forwards requests without preserving strong origin binding, creating a relay path that looks legitimate to the destination service.
- An enterprise hardens service-to-service traffic after reviewing the Ultimate Guide to NHIs, then aligns the change with identity governance guidance from the NIST Cybersecurity Framework 2.0.
- A legacy application is left unchanged because it depends on older authentication behavior, and teams accept a limited relay risk until the service can be refactored or isolated.
These examples show why Kerberos relay is often a migration and architecture issue, not just a detection issue. It appears where trust boundaries are loose, where service identities are over-privileged, or where authentication is accepted without enough context checking.
Why It Matters in NHI Security
Kerberos relay matters because it turns legitimate non-human authentication into an attack path. When service accounts and machine-to-machine flows are broadly trusted, a relayed ticket can let an attacker move laterally without needing to steal a password or crack a secret. That is especially dangerous in environments with excessive privilege, weak service visibility, or stale credentials. NHIMG research shows that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, which illustrates how quickly identity weaknesses become business impact once trust boundaries fail.
In NHI programs, Kerberos relay is a reminder that authentication strength is only part of the control surface. Governance must cover where tickets can be accepted, what services are allowed to trust them, and whether the receiving endpoint is actually the intended resource. Teams that rely on service accounts for automation should review session binding, endpoint hardening, and privilege scope together rather than as separate concerns. Organisational response typically becomes urgent only after suspicious lateral movement or unexpected service impersonation is detected, at which point Kerberos relay becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Kerberos relay exploits weak NHI trust boundaries and service authentication handling. |
| NIST CSF 2.0 | PR.AC-1 | Identity assurance and access enforcement are central to preventing accepted-but-misbound tickets. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification rather than trusting relayed authentication context. | |
| NIST AI RMF | Identity-related failure modes must be governed as operational risks in system design and monitoring. | |
| CSA MAESTRO | Agentic and service-to-service trust chains must resist credential replay across endpoints. |
Verify service identity context before granting access and limit where Kerberos-authenticated requests are accepted.
