THE BOTTOM LINE
Use a standard account for daily work, require elevation on the secure desktop, and manage UAC centrally rather than disabling prompts when an application misbehaves.
- UAC separates everyday processes from administrator-level actions.
- Never notify removes a useful warning and should not be used as a workaround.
- Group Policy suits domain-managed Windows devices, while Intune suits cloud-managed endpoints.
- UAC reduces the impact of malware but is not a complete security boundary or application-control system.
The right baseline depends on whether the device is a personal workstation, a standard-user endpoint, or a server with remote administration requirements.
What does User Account Control (UAC) do?
User Account Control (UAC) asks for approval or administrator credentials when software or a user attempts an action that requires elevation. It helps keep normal applications running with standard-user permissions instead of full system privileges.
What are UAC benefits and security goals?
UAC supports least privilege by separating ordinary use from administrative changes. Microsoft Learn’s UAC overview, updated May 27, 2026, states that UAC is enabled by default and limits the ability of malicious code to execute with administrator privileges.
The prompt is a decision point, not malware detection. You still need to identify the program, understand the requested change, and reject unexpected installers, scripts, or configuration tools.
What does UAC not protect against?
UAC does not stop a compromised administrator from approving a malicious request, prevent vulnerabilities in already elevated software, or replace endpoint protection. It also does not control which applications are allowed to run.
For a broader layered approach, use UAC alongside application control, updates, backups, and the principles described in this defense-in-depth security guide.
How does UAC work in Windows?
Windows creates security tokens that determine what a process can access. A normal process receives a standard token, while an approved elevated process receives an administrator token with additional rights.
What are standard-user tokens and administrator split tokens?
A standard user normally runs applications with standard permissions. An administrator using Admin Approval Mode also works with a filtered standard token until a specific action is approved.
This split-token design means opening a browser or document does not automatically give that process administrator rights. The separation is useful only if you avoid routinely running software as administrator.
What are consent prompts, credential prompts, and the secure desktop?
A consent prompt asks an administrator to approve elevation. A credential prompt asks a standard user to provide an administrator account and password.
The secure desktop displays the prompt in a protected desktop session that ordinary applications cannot control. Microsoft Learn’s UAC configuration guidance identifies secure-desktop prompting as a central protection against simulated or manipulated elevation dialogs.
What is the elevation decision flow?
- An application requests an operation requiring an administrator privilege.
- Windows checks the account type, policy, application metadata, and requested elevation.
- UAC displays a consent or credential prompt, according to policy.
- Windows launches the approved process with the appropriate elevated token, or denies the request.
Which Windows account types change UAC behavior?
| Account type | Normal token | Elevation behavior | Recommended use |
|---|---|---|---|
| Standard user | Standard | Credential prompt for approved administrator credentials | Daily work |
| Administrator | Filtered administrator token | Consent prompt, unless policy changes the behavior | Limited administration |
| Built-in Administrator | Policy-dependent | May use Admin Approval Mode when enabled | Break-glass recovery only |
| Service account | Service-specific | Usually non-interactive, with rights assigned to its service | Dedicated background services |
What should standard user accounts do?
Standard accounts should handle browsing, documents, development tools, and ordinary application use. They reduce the privileges available to malware launched through a normal user session.
What should administrator accounts do?
Administrator accounts should be reserved for installation, system configuration, driver changes, and approved maintenance. Keep a separate administrator identity instead of using an administrator account for email and web browsing.
How should you treat the built-in Administrator and service accounts?
Restrict the built-in Administrator account, use a strong unique secret, and monitor its use. Service accounts should have only the permissions required by their service, never broad administrator rights by convenience.
Which UAC security settings matter?
| Policy area | Hardened choice | Reason |
|---|---|---|
| Run all administrators in Admin Approval Mode | Enabled | Preserves split-token behavior |
| Administrator prompt behavior | Prompt for consent on the secure desktop | Requires an explicit protected-session decision |
| Standard-user prompt behavior | Prompt for credentials, or deny in tightly managed environments | Prevents silent administrator use |
| Secure desktop prompting | Enabled | Reduces interference from ordinary processes |
| Application installation detection | Enabled | Identifies common installer elevation requests |
Why enable Run all administrators in Admin Approval Mode?
Enable this setting so administrator accounts do not run every process with unrestricted rights. A restart may be required after changing the policy, so schedule the change for a maintenance window.
How should administrators receive elevation prompts?
Use Prompt for consent on the secure desktop for administrator workstations. This gives the administrator a visible decision while preventing ordinary applications from drawing over or manipulating the prompt.
How should standard-user elevation prompts behave?
Prompt for credentials when standard users need approved administrative work. Automatically denying elevation is stricter and suits locked-down enterprise endpoints, but it can disrupt legitimate support and installation workflows.
Why should prompting use the secure desktop?
Secure-desktop prompting keeps the elevation interface outside the normal user desktop. Do not disable it to make scripts or installers more convenient.
Should Windows detect application installations and prompt for elevation?
Yes, keep application-installation detection enabled. It helps catch common installer patterns, although it cannot reliably classify every custom installer or script.
Should you elevate only signed and validated executables?
Where the available Windows policy supports restricting elevation to signed and validated executables, enable it after testing application compatibility. Treat signing as an identity signal, not proof that software is safe, because a validly signed program can still be vulnerable or misconfigured.
What is a recommended UAC hardening baseline?
| Device role | Account model | Prompt baseline | Additional control |
|---|---|---|---|
| Administrator workstation | Separate admin identity | Consent on secure desktop | Application control and endpoint protection |
| Standard-user workstation | Daily standard account | Credential prompt or deny | Managed software catalogue |
| Windows server | Restricted admin group | Secure-desktop prompting | Change monitoring and remote-admin controls |
| Domain controller | Dedicated privileged accounts | Strictest tested baseline | Tiered administration and audit review |
| Any device | Never use shared admin accounts | Never notify avoided | Patch and recover from tested backups |
Which settings suit administrator workstations?
Use separate standard and administrator identities, enable secure-desktop consent, and keep elevation visible. Restrict local administrator membership so a stolen session does not immediately provide broad control.
Which settings suit standard-user workstations?
Make daily accounts standard users and require administrator credentials for elevation. If software deployment is fully managed, deny unexpected elevation and provide approved packages through the organisation’s software process.
Which settings suit Windows servers and domain controllers?
Apply a dedicated server policy, test remote administration, and limit interactive logons. Domain controllers require especially careful privilege separation because an elevated compromise can affect the entire directory.
Which UAC settings should you avoid?
Avoid Never notify, which permits elevation without a visible decision in some administrator scenarios. Do not weaken UAC globally to fix one legacy application; isolate, update, replace, or narrowly remediate that application instead.
How do you configure UAC with Group Policy?
Use Group Policy for domain-joined Windows devices and document the intended baseline before deployment. Local policy changes are useful for testing but can create configuration drift.
Where are the Group Policy paths and policy names?
Open Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The relevant entries begin with User Account Control:, including Admin Approval Mode, elevation prompt behavior, secure-desktop switching, installer detection, and file or registry virtualization.
How should you apply settings through domain GPOs?
Create a narrowly named computer policy, link it to the correct organisational unit, and test it with a pilot group. Use gpupdate /force followed by a restart where required, then verify the resulting policy rather than assuming the link applied.
Why separate workstation and server policies?
Servers often require remote administration and may run software with different elevation assumptions. Separate policies let you enforce a strict workstation baseline without breaking a tested server-management workflow.
How do you configure UAC with Microsoft Intune?
Use Intune security baselines or Settings Catalog policies for cloud-managed Windows endpoints. Avoid configuring the same setting through multiple profiles unless you have confirmed the precedence and conflict behavior.
How should you deploy UAC settings with security baselines?
Start with a baseline, export or record each UAC setting, and assign it to a pilot device group. Review device status and remediate errors before expanding the assignment.
How should you handle assignments, exclusions, and conflicts?
Keep exclusions temporary and documented, particularly for servers or specialist applications. When a setting does not apply, inspect competing profiles, security baselines, local policy, and organisational policy before changing the security level.
What should you do beyond UAC prompt settings?
- Use standard accounts for everyday work: Reserve administrator identities for planned maintenance.
- Restrict local administrator membership: Review membership regularly and remove unnecessary accounts.
- Use Windows LAPS: Windows Local Administrator Password Solution rotates unique local administrator passwords and limits reuse across devices.
- Apply least privilege and just-in-time elevation: Grant administrative access only for the task and time required.
- Combine UAC with application control and endpoint protection: UAC governs elevation decisions, while application control governs what can execute.
These controls also reduce the persistence options available after compromise. Review the mechanics in this guide to how Windows threats survive through persistence.
What are UAC bypass risks and limitations?
UAC is designed to improve privilege separation, but it is not a complete security boundary. Some bypass techniques abuse trusted elevated components, insecure file paths, or vulnerabilities, especially after an attacker already controls an administrator session.
Why is UAC not a complete security boundary?
An approved administrator can still run harmful code with elevated rights. UAC also does not replace patching, application allowlisting, exploit protection, or restrictions on privileged group membership.
Which misconfigurations weaken UAC?
Common weaknesses include disabling UAC, selecting Never notify, allowing broad local administrator membership, running unknown software as administrator, and applying inconsistent policies across similar devices.
How can you reduce the impact of bypass techniques?
Keep Windows and applications patched, use standard accounts, enable endpoint protections, limit writable paths used by elevated programs, and monitor suspicious elevation. A bypass becomes less useful when the attacker lacks administrator credentials and application execution is separately controlled.
How do you test and verify UAC hardening?
- Confirm effective policy settings: Use Resultant Set of Policy,
gpresult, or the Intune device configuration report. - Test administrator and standard-user elevation: Verify that each account type receives the intended consent or credential behavior.
- Validate secure-desktop prompts: Confirm the prompt appears outside the normal desktop and cannot be altered by the requesting application.
- Review elevation and process-creation events: Compare expected administrative changes with security logs and endpoint telemetry.
How do you confirm effective policy settings?
Check the effective result on the device, not only the configured GPO or Intune profile. Record the Windows edition, policy source, applied value, and test date because policy names and management behavior can change in later releases.
How do you test administrator and standard-user elevation?
Use a harmless administrative action, such as opening an approved system management tool, and verify the prompt type. Repeat with a standard account and confirm that an administrator credential is required or the request is denied.
How do you review elevation and process-creation events?
Correlate approved maintenance with process-creation and account-logon telemetry. Unexpected elevated processes, unusual parent-child relationships, or repeated failed elevation attempts deserve investigation.
How do you troubleshoot common UAC issues?
Why do some applications require administrator rights?
Legacy applications may write to protected directories or registry locations instead of per-user paths. Prefer an updated version or a vendor-supported fix; use compatibility remediation only after testing its security and operational effects.
Why does silent elevation or compatibility failure occur?
Silent behavior can result from policy conflicts, installer detection, application manifests, scheduled tasks, or an overly permissive administrator configuration. Compare the effective policy with the application’s requested execution level and test on a non-production device.
How does UAC behave during remote administration?
Remote tools may use different tokens and local security policies than an interactive console. Test approved remote-management methods separately, and do not disable UAC merely because a legacy tool expects unrestricted local administrator access.
How do you recover from an overly restrictive policy?
Use a documented break-glass administrator account, console access, or a tested management channel. Revert the narrow policy causing the failure, not the entire UAC baseline, then retest the affected workflow.
What belongs on a UAC hardening checklist?
- Keep UAC enabled and avoid Never notify.
- Use standard accounts for daily work.
- Enable Admin Approval Mode for administrators.
- Use secure-desktop prompting.
- Require credentials for standard-user elevation.
- Enable application-installation detection.
- Restrict local administrator membership.
- Rotate local administrator passwords with Windows LAPS.
- Deploy separate workstation and server policies.
- Test GPO or Intune results on representative devices.
- Review elevation telemetry and policy exceptions.
- Recheck the baseline after Windows policy or feature updates.
Where can you find further information and Microsoft guidance?
- Microsoft Learn’s User Account Control overview explains tokens, prompts, benefits, supported editions, and the UAC security model.
- Microsoft Learn’s UAC settings and configuration guidance should be checked before changing policy names or deployment methods, because Windows management options can change between releases.
- For related firmware controls, see this guide to how UEFI Secure Boot protects the Windows boot process.
Re-verify Microsoft guidance, effective policy output, and application compatibility after each major Windows release or management-platform change.