UAC hardening and Windows Administrator protection

User Account Control (UAC) splits an administrator's logon into two tokens: a filtered, standard-user token used for everything by default, and a full administrator token that is only used after an elevation prompt. When it is configured well, malware running in an admin's session still starts without admin rights and has to either trick the user into approving a prompt or use a bypass.

UAC is also misconfigured more often than people think. Imaging scripts turn prompts off, vendors ask for LocalAccountTokenFilterPolicy = 1, and the built-in Administrator account quietly runs with a full token everywhere. This guide covers the settings that matter, what the Microsoft security baseline sets, and the newer Administrator protection model in Windows 11. It assumes you are already working to remove local admin rights from everyday users; UAC is the second line for the people who keep them.

How the pieces fit

All the classic settings live in Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options, with names beginning User Account Control:. They write to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

Step 1: check the current state

Read the registry directly, because GPO results do not tell you what an imaging script or a vendor installer set locally:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" |
  Select-Object EnableLUA, ConsentPromptBehaviorAdmin, ConsentPromptBehaviorUser,
                PromptOnSecureDesktop, FilterAdministratorToken, EnableInstallerDetection,
                EnableSecureUIAPaths, EnableVirtualization, LocalAccountTokenFilterPolicy

EnableLUA = 0 means UAC is off entirely: every administrator runs with a full token, and modern apps may stop working. Treat it as an incident-level finding on any client or server.

Step 2: set the core UAC policies

These are the values from the Microsoft security baseline for Windows 11 and Windows Server, with notes where you may want to go further:

A few notes on the choices:

• The Windows default for administrators is Prompt for consent for non-Windows binaries (5), which silently auto-elevates many signed Windows binaries. That auto-elevation list is exactly what most UAC bypass techniques abuse. Setting 2 makes every elevation show a prompt.
• Automatically deny for standard users removes the credential prompt that helpdesk staff use to type an admin password on a user's device. If your support process depends on that, use Prompt for credentials on the secure desktop (1) instead, and make sure the credential they type is a LAPS password, not a domain admin account.
• Changing EnableLUA requires a reboot. The prompt behaviour settings take effect immediately.

In Intune, the same settings are exposed in the settings catalog under Local Policies Security Options (the LocalPoliciesSecurityOptions policy CSP), with names such as User Account Control Behavior Of The Elevation Prompt For Administrators.

Step 3: filter the built-in Administrator

By default the built-in Administrator account (RID 500) is exempt from Admin Approval Mode: it always runs with a full token and is also exempt from remote UAC filtering. That makes it the most valuable local account to an attacker holding its hash.

Enabling Admin Approval Mode for the Built-in Administrator account (FilterAdministratorToken = 1) puts it under UAC like any other admin, and also subjects it to remote UAC, so its hash can no longer be used over the network for full administrative access. Pair this with LAPS so the account has a unique password, and keep it disabled or reserved for break-glass use.

Step 4: keep remote UAC on for local accounts

When a local account in the Administrators group authenticates over the network (SMB, WMI, WinRM), remote UAC gives it a filtered token. That single behaviour stops a large amount of pass-the-hash lateral movement with local accounts.

The control is LocalAccountTokenFilterPolicy under the same registry key:

• Absent or 0: filtered token for local accounts over the network (secure).
• 1: full token, remote UAC disabled.

The Microsoft security baseline enforces this through Apply UAC restrictions to local accounts on network logons, found under Computer Configuration > Policies > Administrative Templates > MS Security Guide once you import the SecGuide.admx template from the Security Compliance Toolkit. Set it to Enabled.

Remote UAC does not apply to domain accounts in the local Administrators group; they receive a full token over the network. That is why the network logon restrictions in admin tiering still matter. Also deny network logon to the Local account and member of Administrators group SID (S-1-5-114) as described in the LAPS guide, which blocks local admins over the network regardless of this value.

Step 5: evaluate Administrator protection

Administrator protection is a newer model for Windows 11, generally available on 24H2 and 25H2 with the August 2026 update KB5120998 and off by default. Instead of keeping a filtered and a full token for the same user in the same session, Windows creates a hidden, system-managed, profile-separated account for each administrator and issues the elevated token from that account, just in time, after the user authenticates with Windows Hello. The elevated process gets its own profile and registry hive, and the token is discarded when the process ends. Many classic UAC bypasses rely on the filtered and elevated tokens sharing a profile, environment and auto-elevation list, and those assumptions no longer hold.

Where the policy is available, it is configured under Security Options with User Account Control: Configure type of Admin Approval Mode, set to Admin Approval Mode with Administrator protection, and User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection. In Intune, use the UserAccountControl_TypeOfAdminApprovalMode and UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection settings of the LocalPoliciesSecurityOptions CSP. The change requires a reboot.

Before you plan a rollout:

• It is supported on Windows 11 Home, Pro, Enterprise and Education, but not on Windows Server, Windows 365 Cloud PCs or Azure Virtual Desktop session hosts, and Microsoft advises against it on devices that require Hyper-V.
• Test application compatibility carefully. Installers and tools that expect the elevated process to write to the same user profile, mapped drives or per-user registry as the unelevated user can behave differently.
• It also changes remote logons: by default, domain users in the local Administrators group get a non-elevated token over the network while it is on. Two policies (Allow remote logon with elevated privileges for domain users... and ...for specified domain users and groups...) restore elevated remote logons, so test remote management tools. Tiering, remote UAC and LAPS are still required.

A good approach is to enable it first on IT staff devices, where admins elevate regularly and can report breakage, then extend it to any remaining users who keep local admin rights.

What breaks

• Legacy installers and updaters that assume they run elevated. With installer detection on, they prompt; with standard users set to auto-deny, they fail. Deploy them from your management tool in system context.
• Remote management tools that connect as a local account over SMB or WMI. Remote UAC blocks them. Use a domain account in the right tier, or an agent-based tool.
• Accessibility and remote support tools that use UIAccess and live outside Program Files. The secure UIAccess paths setting blocks them until they are installed in a secure location.
• Scripts that use the built-in Administrator expecting a full token. With FilterAdministratorToken on, they must run elevated explicitly.

Verify it

1. Registry state. Re-run the query from Step 1 on a sample of devices and collect it fleet-wide through a compliance script. Flag any EnableLUA = 0 or LocalAccountTokenFilterPolicy = 1.
2. Token type. Enable Audit Process Creation and look at Security event 4688. The Token Elevation Type field shows %%1936 (full token, UAC disabled or RID 500 exempt), %%1937 (elevated) or %%1938 (limited). A steady stream of %%1936 from interactive sessions of administrator accounts means UAC is not doing its job (standard users have no split token, so their processes normally show %%1936 too).
3. Remote UAC test. From another machine, try to reach \\target\C$ with a local admin account. It should be refused.
4. Tamper monitoring. Alert on changes to EnableLUA, ConsentPromptBehaviorAdmin and LocalAccountTokenFilterPolicy (Sysmon Event 13, or your EDR). Malware sets these to make the next stage easier.

Checklist

• EnableLUA is 1 everywhere, no exceptions
• Admin prompt set to consent or credentials on the secure desktop, not the default auto-elevate option
• Standard user prompt set to auto-deny, or credentials only with LAPS
• FilterAdministratorToken enabled for the built-in Administrator
• LocalAccountTokenFilterPolicy absent or 0, enforced through the MS Security Guide template
• Administrator protection piloted on IT devices where supported
• Event 4688 elevation type and UAC registry changes monitored

UAC is the last line on a device where someone still holds admin rights. It works best as part of the full Accounts & Privileged Access series, and alongside Credential Guard and LSA protection, which protect the credentials an elevated attacker would go after next.