I've tried to harden my Windows 10 by using an unprivileged account, which I know reduces the attack surface a lot. I'm running Ableton (a music program) which is running after UAC has given admin privileges, and Ableton calls plugins, which are basically a bunch of DLLs which should be run also with admin privileges, but since they are not EXEs, the UAC is not prompted and the program breaks all the time. In the end, Ableton and its plugin ecosystem need to be run with admin privileges.

If I go with an admin account that prompts me for passwords, will forcing UAC to ask for a password instead of the usual "yes" and "no" options offer better security?

  • 2
    Better security would be demanding more from the developers & vendor. Frankly, this is soooo Windows 98. Sep 30, 2023 at 11:20
  • 1
    "offer better security" -- security against what? In the end, you are still running these progams and DLLs. What do you want to be secure from?
    – schroeder
    Sep 30, 2023 at 12:18
  • 1
    ... How is Ableton calling into DLLs without the DLLs inheriting Ableton's (elevated) privileges? Technically there are two ways to do this - RPC (such as DCOM) where the RPC server is unprivileged, or impersonation (dropping the elevated privileges intentionally), but these are both very unlikely. Normally, DLLs are loaded directly into a process, and code in them runs with exactly the same privileges as the rest of the process. You may have a different problem than you think you do.
    – CBHacking
    Oct 1, 2023 at 0:00

1 Answer 1


There are two ways that you can force UAC to ask for a password. They both increase security over automatic elevation, but to different degrees, and with different tradeoffs.

  1. Stay a member of the Administrators group, but configure UAC to ask for a password rather than just for consent.
    This is a fairly straightforward change, although it's hard to find (it's configurable via group policy, or locally via the Local Security Policy editor or by changing a registry value). It simply means that, when the UAC dialog appears, you need to enter your own password/PIN rather than just clicking "Allow". This is similar to how some other operating systems work, for example sudo (including graphical wrappers for it) on MacOS or Linux usually requires this. This also prevents some forms of automatic elevation, which can be exploited by an attacker to bypass UAC in its default configuration. It has the advantage that the program still runs as you, rather than as somebody else, so it still uses your user profile and so on. However, that can be a bad thing, since if the program is (for example) loading DLLs from your user profile, a malicious program could modify those DLLs and wait for an elevated program to load them, thus giving the malicious program the ability to run code in an elevated context. It also doesn't secure against other vulnerable behaviors, such as "look up whether a user is in the Administrators group and allow them if so, rather than checking whether the OS considers them able to do things that Administrators are allowed to do".
  2. Create some other administrative user, and remove yourself from the Administrators group.
    This is the traditional approach, where if you want to run a program with more privileges, you provide the login credentials for a more privileged user. It's been possible in Windows since the dawn of NT, and in other multi-user operating systems before it (for example, the Unix/Linux su command), but UAC makes the process somewhat more user-friendly (for example, detecting when you want to open a file such that the opener-program will need more privileges, and asking if you want to run it as a more privileged user). This is more secure than "normal" ways of using UAC because in addition to requiring a password that might stymie an attacker trying to take over the system, there's no question of "bypassing" UAC. The full user security boundary is in effect; you aren't a member of the Administrators group and can't act as one, not without an administrator's credentials. However, this makes running software more inconvenient, because the software is running as a different user. It'll use a different user profile directory and "current user" registry hive, connect to remote machines as a different user from you, and so on. Sometimes this is desirable, and it certainly has security benefits (such as avoiding the question of whether plugin residing in your Downloads directory have been tampered with!) but also means that things might just not work correctly; unless those plugins were moved to the admin user's directory, the app might just not see them!

Ultimately, whether either of these is worth it depends on your threat model, and your willingness to deal with hassles. Most people never do either of these things, or indeed turn off the UAC "feature" to automatically elevate for in-box system controls (which can be hijacked by malicious software to bypass UAC). How sophisticated of malware are you worried about? How often do you need admin, and are you willing to enter a password that often? Are you willing to manage a separate account that is used only for admin stuff, in exchange for a little extra security? Ultimately, those are questions which depend on you, and have no universal answer.

  • Thanks for the detailed response. Scenario 1 is what I was just looking for. I still got a question: regarding those UAC bypasses that rely on automatic elevation, do they have to do with the GUI? For example, asking for password in UAC could prevent an exploit that moved the mouse to click the "allow" button, if the password wasn't asked for, but I'm not sure if an exploit do that.
    – JulianGR
    Oct 3, 2023 at 14:45
  • 1
    Non-elevated processes already can't send mouse input to the UAC approval window (consent.exe). The most common UAC bypasses exploit the default configuration where many built-in system tools automatically elevate; they essentially launch one of those tools and hitch a ride on that auto-elevation; those can be mitigated simply by selecting "Always prompt" in the UAC config GUI. However, there is at least one more-advanced bypass that takes advantage of the fact that you're still a member of Administrators (even though this isn't checked for positive access checks). I've not seen it in the wild
    – CBHacking
    Oct 4, 2023 at 10:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .