AlwaysInstallElevated: How to Find and Disable It (CIS, Wazuh and STIG Findings)

AlwaysInstallElevated is a Windows Installer policy that, when set to 1 in both HKLM and HKCU under SOFTWAREPoliciesMicrosoftWindowsInstaller, makes every MSI package install with SYSTEM privileges, so any local user can run code as SYSTEM. Fix it by setting “Always install with elevated privileges” to Disabled in both Computer and User Configuration.

Below: which checks raise it, how to confirm it on a host and find the GPO behind it, fixes for Group Policy, Intune and standalone machines, and what to expect on rescan.

What the scanner is actually detecting

This is a configuration compliance finding, not a missing patch. The scanner reads a registry value through a credentialed check or a local agent. The same setting appears under several names depending on the benchmark and version:

The value behind all of them is AlwaysInstallElevated (REG_DWORD) under SOFTWAREPoliciesMicrosoftWindowsInstaller, in HKEY_LOCAL_MACHINE and in each user’s HKEY_CURRENT_USER. The Group Policy setting lives at Windows Components > Windows Installer > Always install with elevated privileges in both the Computer and User Configuration trees, from the MSI.admx template that ships with Windows. Windows’ default is Disabled.

Real-world risk

Microsoft’s documentation describes this option as equivalent to granting full administrative rights and strongly discourages it. When both values are 1, Windows Installer runs every package, including one a standard user built, as SYSTEM. The CIS rationale spells out the obvious abuse: a user packages an MSI that creates a local administrator, adds their own account to Administrators, or installs anything else they like. Metasploit has shipped a local exploit module for this since 2010, and MITRE ATT&CK T1218.007 lists disabling the policy as the mitigation.

The limits matter for prioritization. It is local privilege escalation only: an attacker first needs code execution as some user on the host. Nothing is exposed to the network. Per Microsoft, if the value is not 1 in both places, the installer elevates only managed (administrator-deployed) applications and runs everything else with the user’s own rights. One caveat: Microsoft also notes that once the machine-level policy is on, any user can set their own per-user value, so treat HKLM = 1 as the finding that matters even when HKCU looks clean.

The impact is worst on hosts where many people sign in: Remote Desktop Session Hosts, shared lab machines, jump boxes and VDI pools. AlwaysInstallElevated is on the same local privilege escalation checklist as unquoted service paths and weak service ACLs and SeImpersonate token abuse, so fix them together.

How to confirm it on the host

Check the machine value from any prompt:

reg query "HKLMSOFTWAREPoliciesMicrosoftWindowsInstaller" /v AlwaysInstallElevated

AlwaysInstallElevated REG_DWORD 0x1 means enabled. 0x0 means disabled. “ERROR: The system was unable to find the specified registry key or value” means not configured, which is secure but fails audits that require an explicit 0 (see below).

HKCU is per user, and in an elevated prompt it points to the administrator’s own hive. To check every user currently signed in, run this as administrator:

Get-ChildItem Registry::HKEY_USERS |
  Where-Object { $_.PSChildName -match '^S-1-5-21-[d-]+$' } |
  ForEach-Object {
    $p = "Registry::HKEY_USERS$($_.PSChildName)SOFTWAREPoliciesMicrosoftWindowsInstaller"
    [pscustomobject]@{
      SID   = $_.PSChildName
      Value = (Get-ItemProperty -Path $p -Name AlwaysInstallElevated -ErrorAction SilentlyContinue).AlwaysInstallElevated
    }
  }

An empty Value means not set for that user. Then find out where the setting comes from. On the host, generate a Resultant Set of Policy report and look under Administrative Templates > Windows Components/Windows Installer for the winning GPO:

gpresult /h "$env:TEMPgpresult.html" /f

Across the domain (GroupPolicy module from RSAT), list every GPO that mentions the setting, whether as an Administrative Template or a Group Policy Preferences registry item:

Get-GPO -All | Where-Object {
  (Get-GPOReport -Guid $_.Id -ReportType Xml) -match 'Always install with elevated privileges|AlwaysInstallElevated'
} | Select-Object DisplayName

The list includes GPOs that set it to Disabled, so open each one. If the policy was enabled, also review recent MSI installs:

Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'MsiInstaller' } -MaxEvents 50 |
  Select-Object TimeCreated, UserId, Message

How to fix it

Domain-joined hosts: Group Policy

1. If a GPO enables the setting, change that GPO rather than stacking an overriding one on top.
2. Set Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Installer > Always install with elevated privileges to Disabled.
3. Set User Configuration > Policies > Administrative Templates > Windows Components > Windows Installer > Always install with elevated privileges to Disabled. User settings apply to the OU of the user account, not the computer, unless you use loopback processing, so link it where your users live.
4. Remove any Group Policy Preferences registry item that writes AlwaysInstallElevated = 1.
5. Run gpupdate /force on a test machine and confirm with the checks above.

Choose Disabled rather than Not Configured. Disabled writes an explicit 0. Not Configured removes the value, which is secure, but the DISA STIG check (and any audit written the same way) treats a missing value as a finding.

Intune-managed devices

In a Settings catalog profile, set Microsoft App Store > MSI Always install with elevated privileges to Disabled, and do the same for its User-scoped counterpart. If you use custom OMA-URI profiles instead, the Policy CSP nodes (Windows 10 version 1803 and later) take an integer, 0 for Disabled:

./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/MSIAlwaysInstallWithElevatedPrivileges
./User/Vendor/MSFT/Policy/Config/ApplicationManagement/MSIAlwaysInstallWithElevatedPrivileges

Standalone hosts: registry

On a workgroup machine, gpedit.msc exposes the same two settings under Local Computer Policy. From the command line, set the machine value from an elevated prompt:

reg add "HKLMSOFTWAREPoliciesMicrosoftWindowsInstaller" /v AlwaysInstallElevated /t REG_DWORD /d 0 /f

Then set every loaded user hive to 0 (users who are not signed in are covered by the local User Configuration policy, or on their next domain policy refresh):

Get-ChildItem Registry::HKEY_USERS |
  Where-Object { $_.PSChildName -match '^S-1-5-21-[d-]+$' } |
  ForEach-Object {
    $p = "Registry::HKEY_USERS$($_.PSChildName)SOFTWAREPoliciesMicrosoftWindowsInstaller"
    if (Test-Path $p) { Set-ItemProperty -Path $p -Name AlwaysInstallElevated -Value 0 -Type DWord }
  }

Replace whatever needed it

The setting usually exists so users can install software without an admin. Deploy that software through ConfigMgr, Intune (Win32 apps with install behavior set to System) or Group Policy Software Installation instead. Microsoft’s documentation confirms that even with this policy off, Windows Installer still elevates managed applications that an administrator has assigned or published.

How to verify the fix and rescan

Rerun the reg query and the HKEY_USERS check: both should show 0. Confirm the winning GPO in a fresh gpresult report. For many hosts at once:

Invoke-Command -ComputerName (Get-Content .hosts.txt) -ScriptBlock {
  (Get-ItemProperty 'HKLM:SOFTWAREPoliciesMicrosoftWindowsInstaller' -Name AlwaysInstallElevated -ErrorAction SilentlyContinue).AlwaysInstallElevated
}

No reboot is needed. For Tenable, rerun the credentialed compliance scan with the same audit file. Wazuh evaluates SCA policies every 12 hours by default and immediately when the agent starts, so Restart-Service WazuhSvc gives you a result without waiting.

What can break and how to roll back

CIS lists the impact as none because Disabled is the Windows default. What breaks is anything that relied on the elevation:

• Standard users installing per-machine MSI packages themselves now get a UAC credential prompt or a failure.
• Scripts or updaters that run msiexec in a standard user’s context and write to Program Files or HKLM stop working.

Per-user packages and administrator-managed deployments are unaffected. Rolling back means setting the GPO or registry value back to Enabled (1), which reopens a SYSTEM-level escalation for every user on those hosts. If something breaks, deploy the affected package through a system-context tool rather than rolling back. If you must re-enable it temporarily, scope the GPO to the smallest possible set of machines and record it as a formal exception.

Common false positive reasons

• Only HKCU is set to 1. Not exploitable on its own, because both values must be 1, but the User Configuration audit item still fails. Clear it anyway.
• The value is missing. The host is secure by default, but audits that require an explicit 0, such as the DISA STIG check, report a failure. Set the policy to Disabled.
• The finding returns after a fix. A domain GPO or GPP registry item is rewriting the value. Use gpresult to find it.
• Two tickets for one setting. 18.10.81.2 and 18.10.82.2 are the same control in different benchmark versions.
• The scan could not read the registry. A credential or permission failure produces an error, not a real pass or fail.

FAQ

Is the host exploitable if only one of the two values is 1?

Microsoft says both must be 1 for unmanaged packages to run elevated. However, it also notes that a user can set the per-user value once the machine value is enabled, so HKLM = 1 alone should be treated as exploitable.

Should I delete the value or set it to 0?

Set it to 0 by choosing Disabled. Both close the hole, and Wazuh accepts either, but some audits fail on a missing value.

Will this stop GPO, ConfigMgr or Intune software deployments?

No. Managed applications still install elevated, and system-context deployment tools run as SYSTEM regardless of this policy.

Do I need to reboot?

No. Apply the policy with gpupdate or the next refresh, then rescan.

Tracking this finding across many hosts

This setting almost always comes from one GPO or one image, so it tends to show up on many hosts at once and is best tracked as a single root cause. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners (Nessus results through an uploaded .nessus export) and merges duplicates per scanner. Its AI can write a host-specific remediation script, such as the registry change above, that runs only after human approval, is deployed by its agents on Windows endpoints, and is followed by a re-test to verify closure.

Sources

• Microsoft Learn: AlwaysInstallElevated (Windows Installer)
• Microsoft Learn: ApplicationManagement Policy CSP (MSIAlwaysInstallWithElevatedPrivileges)
• Tenable: CIS audit item 18.10.82.2, Always install with elevated privileges
• Tenable: DISA STIG audit item WN22-CC-000430
• Wazuh: CIS Windows Server 2022 SCA policy (cis_win2022.yml)