A state in which a Kerberos identity cannot be used in on-behalf-of delegation flows. For machine identities, this control matters because the absence of a visible UI checkbox does not mean the protection is unavailable; it must still be applied where the account is sensitive.
What Not Delegable Means in Kerberos
In Kerberos, not delegable means the identity is marked so it cannot be forwarded in on-behalf-of flows. That prevents a service from using the account’s Kerberos context to obtain delegated access to another service.
Why This Setting Matters
It matters most when the account is sensitive or high-value, because delegation expands where that identity can act. A non-delegable account can still authenticate normally, but it cannot be reused as a bridge for downstream access.
This is especially important for machine and service identities, where administrators may assume a missing checkbox means the protection does not exist. In practice, the control can still be enforced through account flags and directory settings.
How It Works
Kerberos delegation is a trust decision, not just an authentication detail. When delegation is allowed, a service can present the user or principal’s Kerberos material to reach other services on its behalf; when an account is not delegable, that path is closed.
The result is narrower authority and less opportunity for unintended impersonation. It is a containment control, not a replacement for strong authentication, and it does not change the identity’s ability to log on where it is explicitly permitted.
Operational Effects and Common Misunderstandings
Not delegable is often misunderstood as a purely UI-driven setting, but the important question is whether the account can be used in delegated access chains. If that property is not set correctly, downstream services may inherit more trust than intended.
For practitioners, the key issue is scope: the control should be applied wherever delegated use would create unacceptable exposure, especially for privileged or sensitive service accounts. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for framing this as an access-control and account-governance decision, while NIST SP 800-63 Digital Identity Guidelines helps place it in the wider identity assurance model.
Risk and Threat Considerations
Delegation creates a trust extension, so a delegable Kerberos identity can become a pivot point if a service is compromised or misconfigured. When the account should be non-delegable, leaving that pathway open increases the blast radius of compromise.
Failure mechanism: A service or intermediary that can obtain and reuse a delegable Kerberos context may impersonate the identity to other systems, turning a single account compromise into broader access.
Impact: Attackers or misbehaving services can reach resources that should have remained out of scope, enabling lateral movement, privilege abuse, or unauthorized service-to-service access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Delegation is an access decision that defines whether an identity can act on behalf of another principal. |
| IA-5 — Authenticator Management | Kerberos delegation depends on credential handling and account protection across the identity lifecycle. | |
| IA-9 — Service Identification and Authentication | The term is material to service and machine identities that authenticate and then may delegate access. | |
| Recommendation — Enforce account delegation restrictions so sensitive identities cannot be used in on-behalf-of access flows. Manage Kerberos-related credentials and account settings so delegated use is prevented where required. Apply service-authentication controls to limit which service identities can participate in delegation. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Kerberos delegation is part of how authenticated identities are represented and trusted across systems. |
| Recommendation — Use identity assurance and federation guidance to constrain how authenticated identities can be reused across services. | ||
| CIS Controls v8 | CIS-5 — Account Management | Non-delegable is an account-governance property that limits how an account may be used downstream. |
| Recommendation — Govern privileged and sensitive accounts so delegation is disabled where the account should not be reused. | ||
Practitioner Guidance
Why practitioners should care: Treat non-delegable as a trust-boundary control, not a cosmetic setting. It is most valuable for accounts whose authority should not be transferable to other services, including sensitive machine identities and service principals. OWASP Non-Human Identity Top 10 is a useful reference point for the surrounding machine-identity risk model, and NIST Cybersecurity Framework 2.0 provides the broader governance lens for access and protection decisions.
Common misunderstanding: Administrators sometimes assume that if delegation is not visible in a GUI, the account is safe by default. The safer assumption is the opposite, verify the effective directory state and the account’s intended delegation behavior.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org