Account Is Sensitive And Cannot Be Delegated | Fix Steps

System owners and admins run into this line in Active Directory, security dashboards, and audit tools, then wonder if something broke. In reality, it is a safety switch that changes how that account can pass credentials to other services. If you work with Windows domains, you need to understand what it does before you switch it off for convenience.

What The Sensitive Non Delegated Account Setting Does

In a Windows domain, users and computers sign in with Kerberos tickets. Delegation lets one service act on a user’s behalf when it calls another service. That makes single sign on smooth, yet it also opens a door for attackers who manage to control a delegated system.

The flag named Account is sensitive and cannot be delegated tells Active Directory to strip the delegate level token from that account. When it is set, the account can still sign in, but its credentials are not passed on to back end services through delegation. Security teams use this control mainly for admin accounts so stolen tokens cannot ride across servers.

• Blocks credential forwarding — delegated services stop receiving tokens for that user or computer.
• Limits damage from compromise — an attacker on one host cannot reuse that account to reach more servers through Kerberos delegation.
• Changes how some tools behave — features that depend on delegation, such as certain management consoles or live migration flows, may no longer work for that account.

This change looks small, just a single checkbox in account properties, yet it reshapes how the account interacts with the rest of the domain. That is why many security baselines mark it as required for privileged identities with broad rights.

From a user’s point of view, nothing looks unusual; the account still signs in and opens tools as it always did. The change only appears when that sign in tries to hop to another server, run a remote management call, or reach a back end service that expects delegated tickets.

Where You See The Sensitive Account Flag

The exact text appears in several places. Sometimes it is a clean label next to a checkbox. In other cases it looks like an error that blocks a task you are trying to run. Before you chase the message, it helps to know which layer is showing it.

Location	How It Appears	What It Tells You
Active Directory Users And Computers	Checkbox “account is sensitive and cannot be delegated” on the Account tab	The flag is set for that user or computer object.
Microsoft Secure Score Or Defender For Identity	Recommendation to enable the “sensitive and cannot be delegated” setting for privileged accounts	Your admin accounts may be missing the flag and stand out as weak spots in security reports.
Line Of Business Apps, Management Tools, Or Scripts	Error text that mentions this sensitive non delegated account setting when trying to run remote actions	The app or script expects delegation to work, yet the account’s flag blocks delegate level tokens.

Many admins first meet this phrase during a security hardening push when a report lists accounts that still allow broad delegation. Others only notice it when a long running script, backup job, or management console stops working after someone tightens delegation settings.

When you see that text in a log, wizard, or help article, pause and ask which account owns the flag and why. Many times it belongs to an admin identity that someone locked down on purpose.

Can I Change Account Is Sensitive And Cannot Be Delegated For My User

Admins often try to clear the setting for a single user because a task fails, such as remote management or a migration job. That may fix the symptom, yet it can also remove a strong guard around high value accounts. The safer route is to work through a short checklist before you flip the switch.

1. Check the account type — find out whether the account is a normal user, a service account, a Domain Admin, or a computer object.
2. Look at where it signs in — if the account signs in on shared servers, jump hosts, or machines with lower hardening, the flag likely exists to limit how far an attacker could move.
3. Confirm what broke — note the exact tool or workflow that fails and capture the full error, not only the short text about delegation.
4. Check existing guidance — review your security baseline, Microsoft guidance, and any local policies that name this flag for admin identities.

For admin identities, that checkbox rarely stands alone. It usually sits beside controls such as limited logon workstations, stricter password rules, and multi factor sign in. Clearing only this flag can undo part of that design and make it easier for an attacker on a weak host to reuse an admin ticket somewhere else.

If the account is an everyday user with no admin roles and the only purpose is to run a single delegated task, you might decide to clear the flag. In many shops, though, the safer answer is to leave it set and create a separate service account with just enough rights for that task.

Step By Step Fixes When This Sensitive Account Setting Breaks Tasks

Once you know which scenario triggers the message, you can pick a fix that removes the friction while keeping security goals in place. The right choice depends on whether you control both the app and the domain, and how much you can change roles and design.

Use A Dedicated Service Account

For many remote admin tools and automation jobs, the cleanest method is to stop using a human admin identity at all. Instead, create a low privilege service account whose only job is to run that tool or job.

• Create a new account — give it a clear name that marks it as a service identity, not a person.
• Grant only needed rights — assign the smallest set of roles or group memberships that still let the job run.
• Leave admin accounts locked down — keep the Account is sensitive and cannot be delegated flag on Domain Admin and similar identities so their tokens never leave hardened hosts.

Once you move a task to a service identity, treat its credentials like any other sensitive secret. Store them in a vault, rotate them on a schedule, and avoid hard coding passwords in scripts that live on many machines.

Switch To Constrained Delegation Where Possible

Older designs used unconstrained delegation, which means a delegated server could pass your credentials almost anywhere once it had them. Newer designs encourage constrained delegation, where you spell out which back end services are allowed.

• Inventory delegation paths — map which front end servers call which back end servers with user context.
• Move away from unconstrained modes — reconfigure services to use constrained delegation that targets specific SPNs.
• Reserve the sensitive flag for true admin identities — keep the flag on accounts that hold broad rights, then fix broken flows by adjusting delegation paths instead.

Constrained delegation designs often need coordination between app owners, identity admins, and operations teams. Take the time to map who owns each piece so changes to service principals or host names do not quietly break the trust chain later.

Adjust Group Memberships And Policies

Some guidance tells you to use both the Account is sensitive and cannot be delegated flag and the Protected Users group. The mix can change how tickets behave and which hosts accept delegated access.

• Review who sits in Protected Users — check that only high value admin identities and service operators live there.
• Align GPO settings with the flag — ticket lifetimes, encryption types, and delegation policies should match your plan for admin accounts.
• Test changes in a lab — before you clear or add the flag on wide groups, replay common tasks such as Hyper V live migration or backup jobs in a safe test domain.

Before you clear “account is sensitive and cannot be delegated” for any admin identity, prove in a test setup that the change does not quietly open routes for token theft or cross server hopping.

Best Practices For Admins Using The Sensitive Account Flag

Security teams often treat this flag as part of a larger plan, not as a one off tweak. Strong plans tend to share a few habits that keep daily work running while keeping high value accounts away from casual use.

1. Tag all privileged accounts — Domain Admins, Enterprise Admins, and similar roles should carry the flag by default.
2. Keep admins off general workstations — admin identities should sign in only on hardened jump hosts and management servers.
3. Use separate identities for admin and mail — avoid using a heavy admin account for email, browsing, or chat; use a normal user identity for that.
4. Document exceptions — when you must clear the flag for a special case, record who approved it, where the account signs in, and which controls compensate for the added exposure.
5. Audit regularly — run reports that surface admin accounts without the flag and service accounts that still carry wide rights.

This approach lines up with guidance from Microsoft and many security standards, which treat delegated tokens as a high value target for attackers on compromised hosts.

Plenty of teams bake these checks into weekly or monthly hygiene runs. A simple script or reporting tool that surfaces new admin accounts without the flag, or sudden changes to where admins sign in, can catch drift long before it turns into an incident review.

That discipline turns the flag from an odd checkbox into a normal part of how you design, use, and retire accounts across the domain. It also makes training new admins far easier and safer overall.

Practical Wrap Up For Handling Sensitive Non Delegated Accounts

Account hardening steps often show up as small checkboxes, and this one is no exception. The setting looks simple, yet it ties directly into how Kerberos tickets move through your domain and how far an attacker can roam if they land on one host.

When you see this kind of sensitive non delegated account message, read it as a hint that someone tried to protect that identity from being used as a stepping stone. Instead of clearing the flag on a live admin account to fix a broken job, shape your design so that only tightly scoped service accounts need delegation rights.

If you treat the message as a pointer toward better account hygiene, not just an annoying pop up, you end up with admin identities that are safer to hold, automation that uses purpose built service accounts, and fewer surprises when the next audit arrives.