Start by inventorying every server and account with delegation enabled, then disable unconstrained delegation wherever possible. For systems that truly need impersonation, move them to constrained delegation and protect high privilege accounts with the setting that prevents delegation. Teams should also review who can change delegation settings, because excessive administrative rights often create the exposure in the first place.
What to do first when unconstrained delegation is found
The first move is not to tweak a single server, it is to establish scope. Build a complete inventory of systems and accounts with delegation enabled, identify where unconstrained delegation is actually being used, and separate true business exceptions from accidental exposure. Active Directory and Entra ID Hardening Guide covers this hardening sequence in the broader identity and delegation context.
That inventory matters because unconstrained delegation is often the difference between a limited impersonation path and a much larger trust boundary. If a server can receive and reuse delegated credentials broadly, the exposure is not local to that host, it can extend to any account that authenticates to it, including high-value accounts if other protections are absent.
Once the scope is known, the default response should be to disable unconstrained delegation wherever possible. For systems that truly require delegation, move them to constrained delegation and confirm that the target services and allowed protocols are tightly limited. Where privileged accounts are concerned, use the setting that blocks delegation so a compromise of a delegating server does not automatically become a privilege escalation path.
Why the control breaks down in practice
Unconstrained delegation fails when teams treat it as a legacy compatibility setting instead of a trust decision. The main issue is not just that delegation exists, but that it can silently accumulate across servers, service accounts, and administrators over time. RFC 8693: OAuth 2.0 Token Exchange is useful background for thinking about delegation and impersonation as explicit, bounded trust relationships rather than open-ended reuse.
Another common failure mode is change control. Teams often disable delegation on the obvious servers but leave management paths intact, so new systems can be re-enabled later by anyone with broad administrative rights. That means the exposure is both technical and governance-related: if too many people can change delegation settings, the control can be undone faster than it is remediated.
Reviewing who can modify delegation settings is therefore part of the first-pass response, not a later cleanup task. If the same administrators who manage routine server builds can also enable high-risk delegation patterns, the environment is likely to recreate the problem after the initial fix.
What good remediation looks like
Effective remediation has three parts: inventory, reduction, and prevention. Inventory tells you where unconstrained delegation exists. Reduction means disabling it or replacing it with constrained delegation wherever the application path allows. Prevention means removing unnecessary rights to change delegation, then validating that privileged accounts are protected from delegation exposure.
If an application truly depends on impersonation, document the service dependency and the exact allowed target scope before making exceptions. The goal is not to preserve every old configuration, but to preserve only the minimum delegation path needed for the application to function. That distinction is what keeps a legacy compatibility requirement from becoming a standing trust problem.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Unconstrained delegation and admin rights both hinge on limiting excess access. |
| AC-2 — Account Management | Delegation exposure depends on discovering and governing accounts and system roles. | |
| IA-5 — Authenticator Management | Delegation abuses rely on credential material that can be reused or abused across services. | |
| Recommendation — Restrict delegation changes and server permissions to the minimum set of approved administrators. Inventory delegated accounts and remove or disable unnecessary delegation configurations. Rotate and protect credentials involved in delegation paths and privileged service access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Delegation is a trust decision that should be bounded and explicitly verified. |
| Recommendation — Treat delegation as a constrained trust relationship and verify every allowed access path. | ||
Practitioner Guidance
What to prioritise: Start with systems that can reach sensitive tiers, because those are the highest-impact candidates for credential capture and impersonation abuse. If a delegating server can touch privileged services, treat it as a containment problem, not just a configuration issue.
What to verify: Confirm which accounts are actually protected from delegation, which services still require impersonation, and which administrators can change those settings. A clean policy is not enough if the effective change path remains broad.
Common mistake: Teams often fix the server setting but ignore privilege creep. If change rights stay wide, unconstrained delegation tends to reappear through new service deployments, inherited templates, or operational exceptions.
Practitioner takeaway: The first real decision is whether the environment can eliminate the trust path entirely; if it cannot, the next best outcome is to tightly bound delegation and make the remaining exception visibly owned, reviewed, and hard to expand.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
