When should a privileged account be marked as sensitive and cannot be delegated?

What “Sensitive and Cannot Be Delegated” Actually Controls

The flag is a Kerberos delegation safeguard, not a general privilege label. It tells Windows authentication not to let the account’s tickets flow through delegation paths that could re-present the account on another system. That matters when the account’s authority is too sensitive to be forwarded, impersonated, or used in workflows that widen the blast radius of a compromise.

In practice, you apply it to accounts whose authentication context must stay tightly bound to the originating logon session. That includes Tier 0 administrative identities, domain administrators, and any account that should not be usable by services, middle tiers, or delegation chains that might expose it to weaker hosts or broader trust boundaries.

For teams that are separating high-value administration from normal user work, the cleanest way to think about the setting is as a containment marker: it reduces where the ticket can travel, but it does not replace least privilege, separate admin accounts, or a proper delegation design. NHIMG’s Kerberos Delegation Security Guide covers the delegation models and the abuse paths that make this control relevant.

Which Accounts Should Be Marked First

The strongest candidates are accounts that hold control-plane authority or can change security boundaries. That usually means domain admins, forest or enterprise admins, and other Tier 0 identities that administer directory services, authentication systems, or core infrastructure. If an attacker could turn that account into a pivot into other systems, the account belongs on the short list.

It is also appropriate for accounts that participate in administrative workflows but should never be delegated through intermediate hosts. A common mistake is to focus only on named administrator roles and miss service-linked privileged identities, emergency access accounts, or operator accounts that are functionally equivalent to admin access even if they do not have the title.

NHIMG’s Admin panels and super admin accounts is useful here because the same logic applies to highly privileged console access: the smaller the trusted path, the lower the chance of delegated exposure.

Another useful check is whether the account is ever expected to authenticate through application tiers, remote execution paths, or helpdesk-style delegation. If the answer is no, then “sensitive and cannot be delegated” is usually the safer default than trying to prove that every possible delegation path is harmless.

How to Decide Whether Delegation Is the Real Problem

Marking an account as sensitive only makes sense when delegation is part of the exposure. If the account never enters a delegation workflow, the flag may add little practical value. If the account routinely appears in S4U, constrained delegation, protocol transition, or tiered admin workflows, the flag can stop an unsafe trust hop before it happens.

This is why discovery matters. You need to know which privileged accounts are actually present in delegation paths, which service accounts can impersonate users, and which admins still rely on legacy patterns that forward tickets too widely. NHIMG’s Privileged Account Discovery and Onboarding Guide helps teams inventory those accounts before they are quietly embedded in tooling.

Delegation settings become especially risky when they combine with service accounts, nested group membership, or admin roles that are harder to see than normal user accounts. That is why the control should be reviewed alongside actual privilege paths, not just directory labels. For accounts that are already carrying sensitive authority, the question is not whether delegation is convenient, but whether any delegated path is acceptable at all.

Risk and Threat Considerations

Delegation expands the number of systems that can handle a privileged authentication context, and that creates a clear attack surface. If an attacker compromises a less trusted server, a delegated ticket or forwarded credential path can become a bridge into higher-value systems. The risk is greatest when the account can be used to administer directory services, cloud control planes, or other Tier 0 functions.

Failure mechanism: An attacker abuses a delegated logon path, replays or leverages the privileged context on another host, and then moves laterally or escalates with the borrowed authority.

Impact: The compromise can spread beyond the original host, turn a single server issue into a domain-wide incident, and expose directory, admin, or service-control functions that should never have been reachable through delegation.

Practitioner Guidance

What to verify: Confirm whether the account is used in any delegation flow, service hop, or tiered admin path before marking it. If it never needs delegation, the flag is low-cost protection; if it does, redesign the workflow rather than relying on the exception.

Decision rule: If the account can alter authentication, authorization, or directory trust, treat any delegated path as a containment failure unless there is a documented, tightly bounded business need. For those accounts, separate admin use, narrower trust paths, and explicit monitoring matter more than convenience.

Practitioner takeaway: Use the setting for accounts whose authority must stay anchored to the original logon session, then validate that the environment is not quietly depending on delegation to make privileged operations work.

Related resources from NHI Mgmt Group

• What should teams do when a privileged account can be delegated to a non-tiered server?
• How can IAM teams tell whether a delegated AD account is effectively privileged?
• How should security teams govern sensitive data in file types that cannot be labeled?
• What breaks when organisations cannot map sensitive data to service accounts and application identities?