Kerberos Replay Cache

How Kerberos Replay Caches Work

A replay cache is a local safeguard that records recently observed Kerberos authenticators and rejects duplicates within the validity window. Its job is narrow but important: make a reused authenticator look stale, even if the ticket itself is otherwise valid. That helps preserve the one-time nature of the exchange and reduces the chance that an intercepted request can be submitted again.

Because the cache sits close to the authentication flow, it is usually an implementation detail of the Kerberos service or host rather than a user-facing control. The practical effect is simple, but the security property it enforces is central, the same authentication proof should not be accepted twice.

Why Replay Prevention Matters

Kerberos assumes that authenticators are short-lived and fresh. If a request can be replayed successfully, an attacker may be able to duplicate a logon or reuse a captured session initiation before the window closes. That is why replay prevention is part of Kerberos trust, not just a performance optimisation. For a broader view of how Kerberos protections fit together, see the Kerberos Security Guide.

The replay cache does not stop theft of credentials by itself, and it does not replace stronger hardening around tickets, clocks, or transport protections. It specifically narrows the usefulness of duplicated authenticators, which is the condition replay attacks depend on.

Operational Behaviour and Failure Modes

Replay caches are sensitive to timing, uniqueness, and local state. If the cache is too small, flushed too aggressively, or inconsistent across processes, duplicate authenticators may slip through. If clocks drift or time windows are mismanaged, legitimate requests can also be misread as suspicious, creating authentication friction and hard-to-diagnose failures.

In clustered or virtualised environments, the implementation detail matters: a cache that is local to one process may not protect another process handling the same service identity, while a shared cache can introduce contention or availability issues. The control is effective only when the service can reliably compare a new authenticator to the recent set it has already accepted.

Where Replay Caches Fit in a Kerberos Defences

The replay cache is one part of a larger anti-replay design that includes fresh timestamps, ticket lifetimes, and service-side validation. It is especially valuable because it gives the server a concrete memory of what it has already seen, rather than trusting the client’s claim that a request is new. In practice, that makes replay abuse harder to automate and easier to reject deterministically.

For defenders, the main lesson is that replay resistance depends on more than the presence of Kerberos itself. Service configuration, clock health, and consistent authenticator handling all shape whether the cache actually enforces the intended security boundary.

Risk and Threat Considerations

Replay cache weaknesses matter when an attacker can capture a Kerberos exchange and try to reuse it before it expires. The risk is strongest when services accept repeated authenticators, when clocks drift, or when cache handling is inconsistent across hosts or processes.

Failure mechanism: A reused authenticator is accepted as if it were new, allowing duplicated logons, session impersonation, or repeated use of a captured request within the valid window.

Impact: The service may grant access that should have been single-use only, weakening Kerberos anti-replay guarantees and increasing the value of intercepted traffic.

Practitioner Guidance

What to watch for: Treat repeated-authenticator errors, sudden authentication failures after time drift, and inconsistent behaviour across front ends as signals that replay protection is not behaving uniformly. If those symptoms appear, review service configuration, time synchronisation, and whether every relevant process is using the intended replay cache behaviour.

Practitioner takeaway: A replay cache is only as strong as the consistency of the service that enforces it. If the cache is unreliable, Kerberos may still authenticate, but the replay boundary becomes much weaker than it should be.

Related resources from NHI Mgmt Group

• Kerberos Credential Cache Manager (KCM)
• What is the difference between MFA bypass and token replay?
• How should security teams respond to OAuth token replay attacks?
• What is the difference between token replay and credential theft?