SecurityDelegation is a Windows impersonation level that lets a server use a client’s security context on remote systems. It is the most permissive impersonation level, because the server can present the caller’s identity across network hops when the account and configuration allow delegation.
What SecurityDelegation means in Windows
SecurityDelegation is the most permissive Windows impersonation level, allowing a server to act on a client’s behalf on remote systems when the account, protocol, and delegation settings allow it. That makes it fundamentally different from lesser impersonation levels, which stop at local access or at the current host boundary.
How delegation changes trust boundaries
Delegation extends the caller’s security context beyond the original connection, so the server is no longer just processing a request, it is carrying authority across network hops. That is useful for multi-tier applications, but it also means the server becomes part of the trust path for the user’s identity and access decisions.
Because this behavior depends on configuration and account properties, delegation is only safe when the server is intentionally trusted to forward identity to downstream systems. A permissive setting on the wrong service can turn a normal application tier into an access bridge into file shares, databases, directory services, or other remote resources.
Where SecurityDelegation is used
SecurityDelegation appears in Windows and COM/DCOM-style architectures, and in other designs where a front-end service must access a backend resource as the caller rather than as itself. In practice, it is used when the backend must evaluate the original user’s permissions, not just the service account’s permissions.
That design can preserve business logic and auditing, but it also creates a stronger dependency on the middle tier. If the server is compromised, or if the delegated context is broader than necessary, the attacker may inherit the ability to reach remote systems with the caller’s authority.
For that reason, teams should treat delegation as an explicit architecture choice, not as a default convenience feature. The question is not simply whether the server can impersonate a client, but whether it truly needs to do so across a network boundary.
Security implications of the impersonation level
SecurityDelegation is dangerous when overused because it can expand the blast radius of a compromised service, expose high-value backend resources, and make privilege boundaries harder to reason about. When delegation is enabled broadly, a service that was meant to mediate access can become a path for lateral movement.
It also increases the importance of service identity hygiene, because the effective authority seen by downstream systems may depend on both the caller and the service configuration. Strong controls around account scope, host trust, and backend authorization are what keep delegation from becoming invisible privilege amplification.
For background on the control model that underpins least-privilege access boundaries, see NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture.
Risk and Threat Considerations
Delegation is risky because it turns a server into an authority relay, which means compromise of that server can expose any downstream system that accepts the delegated context. Attackers value this pattern because it can preserve trusted access while masking the origin of the request.
Failure mechanism: If a service is allowed to delegate too broadly, or if its host is compromised, an attacker can reuse the client’s security context on remote systems and move from a single application tier into deeper network resources.
Impact: The result can be lateral movement, unauthorized backend access, and a much larger compromise radius than the original client session would suggest.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Authentication and Access Management | Delegation changes how access is granted across systems. |
| Recommendation — Limit delegated access to the minimum trusted services and resources. | ||
| NIST Zero Trust (SP 800-207) | 5.2 — Least Privilege Access | Delegation creates cross-boundary trust that Zero Trust is designed to constrain. |
| Recommendation — Constrain delegation so services receive only the access needed for each backend call. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Identification and Authentication) | Delegated remote access depends on service-to-service authentication and trust. |
| AC-6 — Least Privilege | Delegation can amplify authority beyond what a service needs. | |
| Recommendation — Require strong service authentication before allowing delegated network access. Reduce delegated privileges to the smallest set of permitted backend actions. | ||
Practitioner Guidance
Governance implication: Treat SecurityDelegation as a high-trust setting that deserves explicit ownership and review. Only the specific services that truly need remote impersonation should be permitted to use it, and the delegated path should be limited to the smallest set of backend systems required by the application design.
What to watch for: Review delegation-enabled services whenever a tier begins reaching new remote resources, when privilege boundaries are unclear, or when a backend depends on caller identity for authorization. Those are the places where the impersonation level can quietly become an access escalation path.