AlwaysInstallElevated

What this policy setting does

AlwaysInstallElevated is a Windows Installer policy that changes the trust boundary for MSI execution. When it is enabled in both the machine and user policy locations, an unprivileged user can cause an installer package to run with elevated rights, which turns ordinary software installation into a potential privilege boundary break.

The important security idea is not that MSI files are inherently dangerous, but that this policy can make installation behave like administrative execution. That matters because Windows Installer is often treated as a routine enterprise mechanism, so attackers and testers alike look for it when they want a low-friction way to cross from standard user context into elevated context.

Why it is dangerous

Its danger comes from privilege escalation, persistence, and control bypass. If the setting is left enabled, any user who can reach the relevant registry policy path may be able to launch an MSI that performs actions normally reserved for administrators. That can expose local system changes, software deployment abuse, and a pathway to broader host compromise.

This is one of those Windows settings where a simple configuration mistake has outsize impact. The policy does not need an exploit in the traditional sense to create risk, because the weakness is the trust decision itself. For defenders, that means the exposure is often administrative, not just technical: the setting exists, both policy keys are enabled, and the host is effectively permitting elevated installation from a non-administrative context.

How organisations check exposure

Exposure checks should start with endpoint inventory and policy review. Organisations need to know which systems have the setting enabled, whether it is configured by local policy, domain policy, or another management layer, and whether standard users can interact with the affected hosts. It is also worth validating the control on gold images and managed builds, not just on a single reference workstation.

For detection and validation, defenders should pair configuration review with host telemetry and ATT&CK-style hunting for privilege escalation behaviour. The Windows Privilege Escalation Techniques Guide is a useful reference point because this policy sits alongside other Windows elevation paths, and it helps place the setting in the wider context of escalation detection and response.

Remediation and preventive control

The safest position is to keep the policy disabled unless there is a tightly justified operational requirement. Where a business process truly depends on elevated installation, organisations should prefer centrally managed software deployment rather than allowing users to trigger privilege elevation through MSI execution. This reduces the chance that the setting becomes a hidden escalation path on otherwise well-managed endpoints.

Because the risk is configuration-driven, remediation is usually straightforward but governance-sensitive. Teams should align local hardening, group policy, and endpoint build standards so that a single exception does not quietly reintroduce the problem. As a baseline hardening reference, defenders can use the NIST Cybersecurity Framework 2.0 to frame the control as a protective configuration issue, and the NIST AI Risk Management Framework is not relevant here, so it is not used.

Related resources from NHI Mgmt Group

• How do you detect AlwaysInstallElevated abuse for privilege escalation on Windows?