What should teams do when a privileged account can be delegated to a non-tiered server?

Why this is an identity governance problem, not just a server issue

A privileged account that can be delegated to a non-tiered server breaks the separation that tiered administration is meant to enforce. The risk is not only that the host is weaker, but that the privileged identity can now operate from, and through, a lower-trust system. That changes the trust boundary for the account, not just the posture of the server.

Once delegation is allowed, the server becomes part of the effective control surface for the privileged identity. If that host is compromised, an attacker may inherit the ability to abuse the delegated context, which makes the account itself too exposed to remain in its original tier.

That is why the response has to be policy-level first: block the delegation path for the privileged identity, then reclassify the server based on what privilege it can receive and forward. If the relationship is allowed to persist, the organisation has implicitly accepted cross-tier trust that tiering was supposed to prevent.

What changes when delegation crosses a tier boundary

Tiering works only when higher-privilege identities are prevented from interacting with lower-trust systems in ways that can transfer authority, material, or session context. A non-tiered server is not merely “less hardened”, it is outside the intended administrative boundary for that privileged account.

In practice, delegation can create hidden privilege paths even when no interactive login is intended. The important question is not whether the server is administratively convenient, but whether it can receive delegated access that expands the blast radius of the privileged identity. Active Directory and Entra ID Hardening Guide treats delegation and tiered administration as separate controls for exactly this reason.

Where delegation is permitted, teams should assume the account is now coupled to the host’s security posture. If the server belongs to a lower tier, the privileged account has effectively been downgraded in practice, even if its formal role has not changed.

How teams should respond and re-segment access

The immediate action is to remove the delegation allowance for the privileged identity and enforce the trust boundary in policy, not by exception. Then decide whether the server belongs in a stricter access class, or whether it should be rebuilt into a tier that is eligible to receive that level of trust.

For teams managing broad privileged estates, this is a case for least privilege, just-in-time elevation, and session separation rather than broad standing permissions. Privileged Access Management Guide and Just-in-Time Access and Zero Standing Privilege Guide both support the operational pattern: keep privileged authority short-lived, explicit, and tied to the right trust tier.

When the server legitimately needs privileged interaction, use a model that confines that interaction to the minimum required scope. Privileged Session Management Guide is useful here because it keeps privileged activity observable and bounded instead of allowing hidden delegation paths to accumulate.

Risk and Threat Considerations

Allowing a privileged account to delegate to a lower-tier server creates an attack path from a weaker host into a stronger identity. If that server is compromised, the attacker may gain a route to misuse the privileged context, pivot into higher-value systems, or bypass the assumptions behind tier separation.

Failure mechanism: Delegation turns a non-tiered server into an authority-bearing extension of the privileged account, so compromise of the host can become compromise of the trust path.

Impact: The likely result is privilege exposure beyond the intended tier, with increased risk of lateral movement, privilege abuse, and broken administrative separation.

Practitioner Guidance

What to verify: Confirm whether the account can delegate, where that delegation is accepted, and whether the receiving server is assigned to the same trust tier as the privilege it can influence. If those do not match, treat the configuration as a governance defect, not an endpoint hygiene issue.

Decision rule: If a privileged identity can be delegated to a lower-trust host, disable that delegation path first, then decide whether the host belongs in a higher tier or the privileged role must be redesigned.

What good looks like: Privileged identities can only operate on systems whose trust classification matches their authority, with no implicit delegation routes across tiers and no standing exceptions that bypass the policy model.

Practitioner takeaway: The control objective is to keep privilege and host trust aligned. When they diverge, the safest fix is to remove the delegation relationship, because the account has already inherited the weaker host’s risk.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams run access reviews for non-human identities?