Ticket reuse

Expanded Definition

Ticket reuse refers to continuing access with an already issued authentication artefact, most commonly a Kerberos ticket, rather than re-entering the original password or re-establishing the full authentication flow. In NHI environments, this matters because the artefact may remain valid even after the underlying secret has been changed, rotated, or discovered to be exposed. That makes ticket reuse distinct from password reuse, token reuse, or simple session persistence, although those patterns can overlap in operational reports.

Definitions vary across vendors when ticket reuse is discussed alongside session hijacking, delegated authentication, or bearer token abuse, so the term should be used precisely. In practice, the key question is whether access continues because the ticket itself is still trusted by the system. NIST’s NIST Cybersecurity Framework 2.0 is useful here because the control problem is not just credential issuance, but ongoing access validation and revocation discipline. The most common misapplication is assuming a password reset or key rotation automatically ends access, which occurs when the ticket lifetime and revocation path are not independently controlled.

For broader NHI governance context, the Ultimate Guide to NHIs is the most relevant starting point.

Examples and Use Cases

Implementing ticket management rigorously often introduces operational friction, because shorter lifetimes and tighter revocation can interrupt legitimate automation, requiring organisations to weigh containment speed against service continuity.

• A Windows service account keeps working after its password is changed because the Kerberos ticket already granted to that session remains valid until expiry.
• An incident responder revokes a compromised secret, but an attacker who already obtained a valid service ticket continues accessing a backend API until ticket expiration.
• A CI/CD job authenticates once and reuses a cached ticket across multiple pipeline steps, reducing login overhead but increasing exposure if the runner is compromised.
• A federated workload receives a short-lived ticket from an identity broker and reuses it for downstream service calls, which is safer than long-lived credentials but still requires lifecycle control.
• During access review, an engineer discovers that rotating a credential in a vault did not invalidate an active ticket held by a privileged automation account.

For NHI risk analysis, the Ultimate Guide to NHIs shows why service-account visibility and revocation discipline matter, especially when temporary access artefacts outlive the secret that created them. The same pattern is described in NIST Cybersecurity Framework 2.0 under access governance and protection activities.

Why It Matters in NHI Security

Ticket reuse becomes a governance issue when defenders believe a rotation event has closed the door, but active access remains. That gap is especially dangerous for NHIs because machine identities often operate continuously, integrate deeply with other systems, and are rarely watched with the same scrutiny as human logins. NHI Management Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, highlighting how often remediation lags behind exposure. When ticket reuse is present, that lag can extend the attacker’s dwell time even further if the artefact itself is still accepted.

This is why ticket reuse intersects with Zero Trust thinking, revocation procedures, and visibility into service accounts. It is not enough to harden the source secret if downstream artefacts remain valid and broadly trusted. The Ultimate Guide to NHIs is useful for framing the broader lifecycle problem, while NIST Cybersecurity Framework 2.0 reinforces the need for disciplined access control and response.

Organisations typically encounter the operational impact only after a password change fails to stop suspicious access, at which point ticket reuse becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do AI agents create more risk when they reuse existing credentials?
• How should teams respond when a secret is found in a support ticket?
• What is the difference between secrets exposure and credential reuse risk?
• Should organisations prioritise reducing secret reuse over faster scanning?