What do teams get wrong about delegation controls in Active Directory?

A common mistake is treating delegation as a narrow configuration issue instead of a privilege boundary that attackers can target after initial compromise. Teams also underestimate how quickly service accounts become a pivot point when impersonation is possible. If delegation paths are not monitored and constrained, the environment can quietly enable privilege expansion and resource abuse.

Delegation Is an Access Boundary, Not a Checkbox

Teams often treat delegation in active directory as a local admin-style setting, when it is really a privilege boundary that changes who can act as whom. That distinction matters because delegation can let a compromised account impersonate users or services without needing a password directly. Once that trust is in place, the problem is no longer just configuration hygiene; it becomes a path for privilege expansion, lateral movement, and quiet resource abuse.

Delegation also tends to be misunderstood because the visible risk is not always immediate. Kerberos delegation settings can look legitimate to application owners, yet still create an implicit trust relationship that survives long after the original business need has changed. The operational mistake is assuming a delegated service account is harmless if it is “working as designed.” In practice, the design may be too broad, too durable, or too poorly reviewed for current access patterns.

For practitioners, the key question is whether the delegated identity can reach anything that would matter if it were abused. NHI Management Group’s research on non-human identity exposure is relevant here because service accounts are often the exact pivot point attackers look for after initial compromise. Ultimate Guide to NHIs — Standards

In practice, many teams discover delegation risk only after an already trusted service account is used to move sideways across systems.

How Delegation Breaks in Real Environments

Active Directory delegation becomes risky when teams separate the technical setting from the business access path it creates. Constrained delegation, resource-based constrained delegation, and legacy unconstrained delegation all differ in scope, but they share a common property: they allow one security principal to obtain access on behalf of another principal under specific conditions. If those conditions are too broad, poorly documented, or no longer aligned to the application architecture, the delegation path becomes a durable escalation route.

The practical failure is usually not the delegation feature itself; it is weak identity hygiene around the delegated account. Service accounts often run with long-lived credentials, excessive group membership, and weak ownership. That combination makes them attractive targets because once an attacker obtains the account or the ability to abuse its trust, the delegation relationship can be used to request access to sensitive services, impersonate users, or reach systems that were never intended to be directly exposed.

Good practice is to review delegation as part of identity lifecycle management, not as a one-time AD hardening task. Teams should verify three things: what can delegate, to whom it can delegate, and whether the delegated scope still matches the current application need. They should also correlate delegation with monitoring coverage, because abuse often looks like normal service activity unless you are watching for unusual ticket use, unexpected target services, or access from atypical hosts. Microsoft’s control guidance is useful as a baseline for structured account and access review. NIST SP 800-53 Rev 5 Security and Privacy Controls

Review whether delegation is still required for each service account and application.
Limit delegation to the smallest practical target set and protocol scope.
Track who owns the account, who approves the trust, and when the approval expires.
Monitor for ticket abuse, privilege anomalies, and service accounts authenticating in unexpected patterns.

These controls tend to break down in legacy environments where application teams depend on broad delegation to keep older authentication flows working.

Where Teams Overlook the Real Failure Modes

Tighter delegation controls often increase operational friction, so teams need to balance reduced blast radius against application compatibility and support overhead. The most common tradeoff is that a control which is technically safer can still be bypassed informally if it breaks a production workflow, which is why documentation and exception handling matter as much as the AD setting itself.

One overlooked failure mode is delegation sprawl across multiple administrators and application owners. When no one can clearly explain why a delegated trust exists, the organisation is already carrying hidden risk. Another is assuming that a service account is low risk because it is not interactive. If it can impersonate users or services, its abuse potential can be higher than a normal endpoint account, especially when the account can reach file shares, databases, or management services.

Teams also underestimate how quickly delegation becomes a monitoring problem. If the security team cannot distinguish legitimate delegated use from abnormal impersonation, the control exists on paper but not in practice. Current guidance suggests that the review process should focus on business justification, scope, and revocation readiness, not just directory settings. In many environments, delegation drift is discovered only when incident responders trace an unexpected privilege path after compromise.

In practice, the hardest part is not creating stricter delegation; it is proving that every delegated trust still has a current owner, a current purpose, and a clear way to remove it without breaking the environment.

Risk and Threat Considerations

Delegation in Active Directory creates a privilege amplification risk because it lets an attacker who compromises one trusted account act through that account’s delegated authority. The threat is especially serious when service accounts have broad reach, because the delegation path can turn a single foothold into impersonation, lateral movement, and access to protected resources without requiring direct password theft from the final target.

Failure mechanism: Attackers target delegated principals, abuse ticket-granting or impersonation-capable relationships, and then request access to services that trust the delegated identity. If the account is overprivileged, poorly monitored, or used across multiple systems, the attacker can expand access while blending into normal service traffic.

Impact: The environment can lose trust boundaries, exposed systems may accept actions taken on behalf of higher-value users, and defenders may miss the abuse because it appears to come from an authorised service path rather than an obvious intrusion.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Delegation is an access boundary that must be scoped and reviewed.
	5 — Account Management	Delegated service accounts need ownership, lifecycle, and revocation discipline.
Recommendation — Restrict delegated access paths to the minimum approved scope and review them regularly. Track delegated service accounts through their full lifecycle and retire unused trust quickly.
NIST CSF 2.0	PR.AC-4 — Access permissions and authorisations are managed	Delegation changes who can act on behalf of whom and needs formal permission control.
	DE.CM-1 — Monitoring for unauthorized activity	Delegation abuse often looks like normal service traffic without targeted detection.
Recommendation — Manage delegation approvals as explicit authorisations with clear scope and review dates. Monitor delegated authentication patterns for abnormal impersonation and ticket use.
MITRE ATT&CK	T1134 — Access Token Manipulation	Delegation abuse enables impersonation and privilege expansion through trusted access paths.
Recommendation — Hunt for token or ticket abuse that turns delegated trust into expanded access.

Practitioner Guidance

What to prioritise: Start with delegated accounts that can reach tier-0 or business-critical systems, because those are the relationships that turn a single compromise into meaningful blast-radius expansion.

What to verify: Confirm that every delegated trust has a named owner, a current business justification, and a documented revocation path. If any of those are missing, treat the setting as legacy risk rather than accepted architecture.

Decision rule: If a service account can impersonate users or services across security boundaries, require review for scope reduction and monitoring before accepting it as operationally necessary.

Practitioner takeaway: Delegation should be managed as an explicitly bounded trust relationship, because the danger is not the feature itself but the hidden authority it creates when ownership, scope, and monitoring are allowed to drift.