Why Some Windows Installers Ask for Admin Permission and Others Don't

UAC asks about privileges, not about installing​

UAC doesn't treat "installing software" as one category that always needs approval. When a process is created, Windows runs AppCompat, Fusion and installer-detection checks to assess whether the app requires elevation. Microsoft's overview explains the baseline: UAC lets users sign in with a standard user account, and Explorer-launched programs inherit standard permissions. Administrator accounts work the same way. They run with a standard token until something asks for the full administrative one.

If an installer can finish its job using only the access you already have, Windows has nothing to prompt about. Installers that must change protected parts of the system are the ones that trigger the dark-screen dialog. Typical examples:

• Writing to C:\Program Files
• Installing drivers
• Setting up system services
• Changing system-wide settings

Installing software is one of the actions that needs more than standard-user rights. Protected system locations are typically writable only by an administrator, so standard users lack the access to install programs there.

Why per-user installs skip the prompt​

A per-user install puts the app in locations your account already owns. A common one is %LOCALAPPDATA%\Programs, which maps to C:\Users\YourName\AppData\Local\Programs. It isn't universal, because the exact location depends on the app. Files, shortcuts and your personal registry settings can all be written with ordinary permissions.

The same split exists in Windows Installer (MSI) packages. A per-machine MSI install requires elevated privileges and writes to per-machine locations. A per-user install doesn't prompt for credentials and redirects files and registry entries to per-user locations. Microsoft's ALLUSERS documentation adds that a package written to the single-package-authoring guidelines lets users with user access install into the per-user context without UAC credentials. Package authors can also suppress the prompt when elevation isn't required.

You can check your own machine:

1. Press Win + R.
2. Enter %LOCALAPPDATA%\Programs and press Enter.
3. Look at which familiar apps live there.

Don't read the result as a complete inventory. Some per-user software installs elsewhere in your profile.

VS Code: the clearest side-by-side example​

VS Code offers both models. According to Microsoft's current setup documentation (last dated 11/4/2026 on the page), the options are:

The documentation recommends the User setup for most people. It needs no administrator permission and gives the smoothest background-update experience. The editor itself is the same either way. What you're choosing is scope and update behavior.

There's one quirk. Per the VS Code documentation, updates are disabled when VS Code runs as Administrator from a User setup installation. If you launch it elevated out of habit, auto-update stops working.

For shared machines or managed fleets, the System setup is the one that makes the editor available to every account. That is a legitimate reason to accept the prompt.

Store and MSIX apps: Windows does the privileged work​

Packaged apps work differently from classic installers. Microsoft's MSIX documentation says app packages are installed per user rather than system-wide. By default they land under C:\Program Files\WindowsApps\<package_full_name>. Microsoft also says package files are read-only after deployment and heavily locked down by the OS. The app doesn't copy files into a protected folder itself. Windows deploys and registers the package, which is why the process can finish without a prompt.

Caveats from Microsoft's documentation:

• Services need admin rights. Microsoft says packaging services in MSIX requires administrator privileges at install, since a service may start in the background and change the machine. That capability applies to Windows 10 client version 2004 (build 10.0.19041.0) and later.
• Delivery channel isn't deployment format. The MakeUseOf piece notes that the Microsoft Store also lists traditional EXE and MSI apps. Those can install in their own way. Don't assume "from the Store" means "MSIX, no prompt."
• Per-machine requirements can still bite. A package that needs machine-wide changes can still require elevation.

What the installer's manifest and Windows heuristics do​

Microsoft's developer guidance says most desktop apps should run at the asInvoker level. Elevation should be requested only for write access to protected locations such as %ProgramFiles%, or for system-wide changes. The other manifest levels are highestAvailable and requireAdministrator. The latter always triggers a UAC consent or credentials prompt.

Microsoft also flags a trap. An application with no manifest is treated as asInvoker on modern Windows. It may still be subject to installer-detection heuristics that cause unexpected elevation prompts. So an installer can prompt even when its authors didn't intend it to.

Installer detection is also configurable. According to Microsoft's UAC settings documentation, the "Detect application installations and prompt for elevation" policy, when enabled, prompts for administrative credentials when an installation package is detected that requires elevation. Windows reads this as a guess about intent, not a verdict. Detection applies only in certain conditions, and Microsoft's architecture page says it only applies to interactive processes running as a standard user with UAC enabled. Don't assume every install behaves the same on every PC. Policy, deployment tooling and installation context all change the outcome.

Enterprise wrinkle: mixed installs and the August 2025 hardening​

Admins should know that the line between a silent per-user step and an elevated one isn't fixed. A WindowsForum thread covering the August 2025 Windows Installer hardening describes the issue this way. The update fixed a Windows Installer weak-authentication vulnerability (CVE-2025-50173) and also changed which operations can run silently under a standard user versus needing elevation. The thread says that in some flows, the installer now reclassifies previously user-safe actions as machine-scope, which triggers UAC elevation. Per-user repair and "advertised" first-run actions are the most exposed. Treat that as community analysis, not a Microsoft statement.

The practical advice from that discussion applies broadly: ask vendors for installers that avoid fragile per-user repair semantics, such as fully per-machine installs.

A related quirk turned up in a recent GitHub issue about a Windows Installer package for a small utility. It installed into %LOCALAPPDATA%\Programs without elevation but registered its uninstall data in HKLM. That mismatch confused detection when the package was deployed centrally through Intune. It's one project's report, not a general rule, but it shows why hybrid installers cause trouble in managed environments.

No prompt does not mean safe​

This is the point readers should remember. UAC is a privilege-control layer, not a malware scanner. Microsoft describes its purpose as helping mitigate the impact of a malicious program. It does not describe it as judging intent. Malicious code running as you can still read your documents, harvest browser data or encrypt your files, all without administrator rights. A silent install tells you the installer stayed within your permissions. It says nothing about whether the software deserves trust.

The reverse also holds. A UAC prompt only asks whether you approve an elevation request. It doesn't vouch for the publisher. Before clicking Yes, ask:

• Do I trust the source and publisher?
• Does this software plausibly need machine-wide access, such as a driver, a service or all-user availability?
• Is there a User or per-user option that does the same job with less privilege?

Microsoft's guidance warns that unnecessary elevation trains users to dismiss UAC prompts without reading them. That's a good reason not to turn UAC down. Lowering the slider to make prompts go away removes a layer of protection and doesn't improve your judgment about any installer.

Quick reference​

• No prompt usually means the installer only touches user-writable folders and your own registry hive, or Windows is deploying a package for you.
• A prompt usually means a protected location, a service, a driver or a machine-wide setting.
• Where a choice exists (like VS Code's User versus System setup), pick per-user unless you need all-user availability.
• Neither outcome is a safety rating. Judge the source, not the dialog.

The bottom line is that a quiet install and a dimmed-screen install differ in which resources they need, and how much you trust the software is a separate question.