Why does constrained delegation increase risk when services can impersonate protected users?

Constrained delegation still allows a service to act on behalf of a user, so the security boundary depends on ticket integrity and careful control of delegation rights. If that boundary is weakened, an attacker who controls the service can abuse forwarded tickets to reach resources the user could access. The risk is highest where privileged accounts and sensitive users are allowed through the delegation path.

How constrained delegation changes the trust boundary

Constrained delegation is still delegation: the service is allowed to obtain access on behalf of a user, but only to specific back-end services and only within the scope the directory or Kerberos policy permits. That means the security decision is not simply “can this service authenticate,” but “what can this service cause to happen with a user’s ticket once it has it.”

The practical risk is that the service becomes a high-value trust intermediary. If the service is compromised, misconfigured, or granted broader delegation rights than intended, the attacker inherits the service’s ability to act as a proxy for protected users. That turns a single service compromise into a path toward resources the user could legitimately reach, which is why delegation scope and ticket handling matter as much as the original login.

That boundary is only meaningful if the underlying tickets, delegation settings, and service identity are protected end to end. When any of those elements are weak, constrained delegation stops being a narrow exception and starts behaving like an impersonation channel with a bounded but still dangerous blast radius.

Where the abuse actually happens

The core abuse pattern is not that constrained delegation creates new permissions out of nothing, but that it preserves the user’s effective access while shifting control to the service. An attacker who owns the service can request or forward tickets in ways that let them reach the same downstream systems the user could reach, including sensitive application tiers or privileged administration paths if those users are in scope.

This becomes more dangerous when protected users are included in the delegation path. If a privileged account, support account, or high-value operator account can be impersonated, the attacker does not need to steal the user’s password to obtain useful access. They only need to control the delegated service and wait for an opportunity to leverage the impersonation path.

Constrained delegation also tends to hide behind normal service activity. That makes the security problem partly one of visibility: the access may look legitimate at the destination even when the initiating service has been compromised. For that reason, teams should treat delegation rights as an authorization boundary and a detection problem, not just a convenience feature.

Risk and Threat Considerations

Constrained delegation increases exposure because it lets one system borrow another user’s authority. If the delegated service is compromised, the attacker can reuse that trust path to reach systems the protected user can access, which can collapse the distinction between service compromise and user compromise.

Failure mechanism: The service’s delegated rights, ticket forwarding behavior, or access to the underlying keys and trust material are abused to impersonate a user beyond the intended security boundary.

Impact: Attackers can pivot into sensitive applications, access protected data, or elevate the effect of a single service compromise into broader unauthorized access, especially when privileged users are in scope.

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 MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication, and Access Control	Constrained delegation is an access-control and trust-boundary issue.
	PR.AC-4 — Access Permissions and Authorizations	Delegation scope determines what a service may impersonate and where it may reach.
Recommendation — Define and enforce delegation boundaries so services can only act within approved access scope. Restrict delegated permissions to the minimum set of users and target services.
OWASP Non-Human Identity Top 10	NHI-02 — Privilege and Access Control	Impersonation by a service is a non-human privilege boundary that can be overbroad.
	NHI-05 — Secret and Credential Lifecycle	Delegated access depends on protected ticket and credential handling.
Recommendation — Limit service impersonation rights to the smallest possible resource and user set. Protect and rotate the material that enables delegated impersonation and ticket use.
MITRE ATT&CK	T1558 — Steal or Forge Kerberos Tickets	Ticket abuse is the core attack path when delegation is compromised.
Recommendation — Hunt for Kerberos ticket abuse and unusual delegation-based lateral movement.
CIS Controls v8	6 — Access Control Management	Delegation rights are a form of access that must be granted and reviewed.
Recommendation — Review service delegation rights and remove any unnecessary impersonation paths.

Practitioner Guidance

What to verify: Confirm exactly which users and back-end services are in the delegation allowlist, and challenge any design that includes privileged or highly sensitive accounts by default. Also verify that the service account, host, and ticket-handling controls are monitored as a single trust chain, not as separate low-risk components.

Decision rule: If a service can impersonate a user who can reach admin tools, sensitive data stores, or cross-tier resources, treat the delegation path as a privileged access path and review it with the same care you would apply to a high-impact admin control.

Practitioner takeaway: The main question is not whether delegation is constrained, but whether the constraint still leaves a compromise path that matters. If the answer is yes, the service’s privilege boundary must be governed, monitored, and minimized as if it were a privileged identity.