How should security teams handle unconstrained delegation in Active Directory?

Why This Matters for Security Teams

Unconstrained delegation turns a server into a reusable trust bridge inside active directory, which makes it a high-value NHI asset rather than a normal workload. If that host is compromised, Kerberos tickets can be exposed and replayed against other services, collapsing separation between systems that should not share authority. For teams already dealing with credential sprawl, this is a classic example of why standing trust becomes an attack path. NIST’s NIST Cybersecurity Framework 2.0 is clear that access control and continuous monitoring must be paired, not treated as separate tasks.

The practical risk is not abstract. Identity abuse frequently follows exposed secrets and over-privileged service accounts, and NHIMG research shows the same pattern across broader NHI incidents: lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations in The State of Non-Human Identity Security. That matters here because unconstrained delegation effectively extends the lifespan and reach of any credential already in memory. Security teams should therefore treat delegation settings as identity infrastructure, not as a routine server option. In practice, many security teams encounter unconstrained delegation only after ticket theft or lateral movement has already occurred, rather than through intentional review.

How It Works in Practice

The first step is inventory. Find every computer object and service that still has unconstrained delegation enabled, then map which privileged identities can authenticate to those hosts. Any system that can receive delegated tickets should be classified like a Tier 0 or near Tier 0 asset if it touches domain control, admin jump paths, or sensitive service accounts. That includes hardening the host, restricting interactive logon, removing unnecessary admins, and forcing strong monitoring on memory access, ticket use, and service account activity.

From there, separate the business need from the legacy configuration. Some applications still depend on delegation to reach downstream systems, but current guidance suggests replacing unconstrained delegation with constrained or protocol transition models wherever the application permits it. Where the service cannot be changed immediately, place it under strict NIST Cybersecurity Framework 2.0 monitoring and alert on unusual ticket forwarding, service logons from non-standard sources, and sudden privilege changes. For identity context, this is also an NHI issue: Cisco Active Directory credentials breach shows why exposed directory credentials and excessive trust boundaries are operationally dangerous, not just administratively messy.

• Remove unconstrained delegation wherever the application allows it.
• Restrict remaining hosts to Tier 0 administration and change-controlled access.
• Monitor LSASS and related memory surfaces for ticket exposure indicators.
• Review service accounts that can authenticate to delegated servers.
• Prefer constrained delegation, stronger segmentation, and JIT admin access.

Where possible, combine PAM with JIT elevation so administrative authority is short-lived and auditable rather than persistent. A similar lesson appears in NHIMG reporting on the DeepSeek breach: once secrets are embedded in an environment, exposure can persist far beyond the original intent. These controls tend to break down in legacy Windows estates with shared service accounts and no clean ownership because delegation is often coupled to application dependencies that teams are reluctant to interrupt.

Common Variations and Edge Cases

Tighter delegation control often increases operational overhead, requiring organisations to balance attack surface reduction against application compatibility and support burden. That tradeoff is real, especially where older middleware, clustered services, or vendor-managed apps still depend on Kerberos delegation. Best practice is evolving, but there is no universal standard for this yet: some environments can move directly to constrained delegation, while others need a staged migration plan with compensating controls.

The most important exception is the environment where delegation is not simply a server setting but a core business dependency. In those cases, teams should document the dependency, assign an explicit owner, and put the host under heightened logging, restricted admin paths, and reviewable exception handling. Unconstrained delegation should never be left in place because “it has always worked.” The real question is whether the service is allowed to hold reusable Kerberos authority at all, and if so, under what controls.

Modern identity governance should also consider workload identity and intent-based authorization for services that are gradually being refactored into autonomous workflows. If a service is being redesigned anyway, that is the moment to remove standing trust and replace it with short-lived credentials, narrow service permissions, and request-time policy decisions. For programs aligning to the NHI security maturity curve, this is the difference between preserving a fragile legacy exception and turning the workload into a governed identity with clear boundaries.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• How should security teams handle risks from AI browser extensions?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?