A service ticket is the Kerberos ticket that grants access to a specific service, such as LDAP or host access, after authentication succeeds. It is distinct from the initial login ticket. In trust abuse scenarios, service tickets are the practical payload attackers seek because they enable access to targeted systems and services.
Expanded Definition
A service ticket is a Kerberos credential issued after initial authentication that authorises access to a specific service principal, such as LDAP, CIFS, or host access. It is narrower than the initial login ticket because it is scoped to one target, one session, and one trust path. In NHI operations, that scope matters: a service ticket often becomes the actual access artefact used by applications, automation, and administrators. For governance purposes, service tickets sit at the intersection of identity assurance, ticket lifetimes, and delegation boundaries, which is why they must be considered alongside NIST Cybersecurity Framework 2.0 practices for access control and monitoring. Definitions vary across vendors when Kerberos is abstracted by cloud brokers or SSO layers, but the underlying concept remains a service-specific credential derived from an authenticated identity. In NHI programs, the operational risk is not the ticket itself so much as what it can unlock if stolen, forwarded, or left valid longer than necessary. The most common misapplication is treating service tickets as ordinary session tokens, which occurs when teams ignore Kerberos-specific lifetime, replay, and delegation behavior.
Examples and Use Cases
Implementing service-ticket handling rigorously often introduces operational friction, requiring organisations to balance service continuity against shorter credential exposure windows.
- A workstation receives a ticket for a file service, allowing access to a shared path without re-entering credentials during the session.
- An automation account requests a ticket for LDAP to query directory data as part of scheduled provisioning or audit workflows.
- A helpdesk operator obtains a ticket for a host service when using delegated admin tools to manage endpoints remotely.
- Adversaries who compromise a service ticket can reuse it to impersonate the ticket holder against the targeted service, which is why Kerberos abuse remains a central NHI threat pattern discussed in the Ultimate Guide to NHIs.
- Identity teams align service ticket visibility with NIST Cybersecurity Framework 2.0 logging expectations so they can detect unusual service access patterns.
In practice, the term is especially relevant where Kerberos is used for machine-to-service trust, because the ticket becomes the consumable proof that a specific service may be accessed. The design challenge is not just issuing the ticket, but ensuring that service identity, host identity, and delegation settings all remain aligned.
Why It Matters in NHI Security
Service tickets matter because they are often the point where authenticated identity becomes usable access. If a service ticket is exfiltrated, replayed, or issued with excessive privilege, the compromise can spread laterally without needing the original password or primary login ticket. NHI management issues become visible here: Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which means a single ticket can overreach far beyond its intended service boundary. This is why service-ticket governance belongs in detection, rotation, and privilege review workflows, not only in authentication design. It also fits the broader control logic of NIST Cybersecurity Framework 2.0, especially where organisations must validate that access is authorised, observable, and limited to the minimum necessary scope. Organisational confusion usually appears when incident responders discover that a “valid session” is actually a Kerberos ticket with service-specific reach. Organisations typically encounter service-ticket risk only after lateral movement or service impersonation is detected, at which point the term 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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Service tickets are service-scoped NHI credentials that attackers abuse after authentication. |
| NIST CSF 2.0 | PR.AC | Access control and monitoring govern whether service tickets grant only intended service access. |
| NIST Zero Trust (SP 800-207) | SC-2 | Zero Trust requires each service access decision to be explicitly evaluated, including ticket use. |
| NIST SP 800-63 | Digital identity assurance informs how strongly the originating authentication should be trusted. | |
| OWASP Agentic AI Top 10 | A-04 | Agentic systems often use service tickets for tool and service access, creating abuse paths. |
Treat service tickets as high-value NHI credentials and monitor issuance, scope, and reuse.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
