When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design

In Windows-related consultations, certain topics keep arriving tangled together.

• When does “Run as administrator” actually become necessary?
• I am an administrator account - why does UAC still appear?
• Does installation always require an administrator?
• We want to place the app in Program Files - does that mean elevation even at run time?
• What does the difference between HKCU and HKLM actually affect in practice?
• How should we build an app where “only some operations” need administrator privileges?

This question is not decided simply by “whether the person is an administrator.” In reality, it is largely decided by where you write, who the change affects, and which protected part of the OS you touch.

flowchart TB
    accTitle: What decides whether administrator privileges are required
    accDescr: A diagram showing that whether administrator privileges are required is not decided by whether the person is an administrator, but largely by where the app writes, who the change affects, and which protected part of the OS it touches.
    a0["Whether the person is an administrator"] -.-> a1["Does not decide it on its own"]
    b0["The questions that actually matter"] --> b1["Where does it write"]
    b0 --> b2["Who does the change affect"]
    b1 --> b3["Which protected part of the OS does it touch"]

Figure 1: What decides the answer is not the user’s title but the write destination, the scope of impact, and the protected target.

In this article, we organize the situations where administrator privileges are required on Windows, starting from the premises of UAC, and lay out for practitioners how far standard user rights go and where elevation begins. The content is based on Microsoft’s official information verifiable as of March 2026.¹²³⁴⁵

1. The Conclusion First

The practical conclusions, up front.

• Whether administrator privileges are needed on Windows is decided less by “how impressive the operation is” and more by “whether it affects the OS or the whole machine.”¹⁴
• Processing confined to your own profile - for example using %AppData%, %LocalAppData%, HKCU, Documents - normally needs no administrator privileges.⁶⁷
• Conversely, processing that touches the whole machine, all users, or protected areas - for example Program Files, Windows, System32, machine-wide settings in HKLM or HKCR, Windows services, kernel drivers, the firewall, highest-privilege tasks - tends to require administrator privileges.⁴⁶⁸⁹¹⁰
• The crucial distinction here: the user belonging to the Administrators group and the app currently running with an administrator access token are not the same thing. With UAC enabled, even an administrator user’s ordinary processes run with standard-user-equivalent rights, elevating only when needed.²⁶
• Installation does not automatically mean administrator. With per-user installation, premised on installing under %LocalAppData%, designs exist that distribute and update without administrator privileges.¹¹¹²
• An “app that mysteriously needs administrator rights every time” is in reality usually either writing runtime data into a protected area, or declaring requireAdministrator / highestAvailable in its manifest.⁴¹³
• As for the direction of travel, Windows is leaning toward explicit elevation only at the moment it is needed. Administrator protection (preview) in Windows 11 shows that trend quite clearly.⁵

In short, the most practical view is that “does it need administrator privileges” is decided not by the user’s title, but by the boundary the app touches.

flowchart TB
    accTitle: Elevation is decided by the scope of impact
    accDescr: A diagram showing that whether administrator privileges are required is decided not by how impressive the operation is but by whether it affects the OS or the whole machine, that processing confined to your own profile does not need it, and that processing touching the whole machine, all users, or protected areas tends to need it.
    j1{"Does it affect the OS or the whole machine"}
    j1 -->|"Confined to your own profile"| r1["Usually fine without administrator privileges"]
    j1 -->|"Touches the whole machine, all users, or protected areas"| r2["Tends to require administrator privileges"]
    r0["How impressive the operation is"] -.-> r3["Is not the criterion"]

Figure 2: The dividing line is not how advanced the operation is, but how far the change reaches.

Knowledge map for this article

This article organizes the situations where administrator privileges are required on Windows around whether the operation writes to a protected area that affects the OS or the machine as a whole. Where UAC is enabled, even a process started by an administrator user runs with standard user rights by default, and elevation is requested only at the moment an operation touches a protected area such as Program Files or HKLM. Installation does not necessarily require an administrator, and a per-user installation can be distributed and updated without administrator rights, but administrator rights tend to become necessary once the app writes runtime data into a protected area or matches the conditions for installer detection. The models for isolating administrator work are the Administrator Broker Model, a service, a highest-privilege task, and an elevated COM object, and Administrator protection (preview) in Windows 11 takes the direction of elevating only at the moment it is needed one step further.

flowchart LR
    accTitle: When administrator privileges are required on Windows
    accDescr: Diagram showing how the criterion of whether an operation writes to a protected area of the OS drives the UAC elevation prompt, the choice between a per-user and a per-machine installation, the relationship with installer detection and virtualization, and the choice among the four privilege isolation models.
    admin_rights["Administrator Privileges"]
    uac["UAC (User Account Control)"]
    protected_system_location["Protected System Locations"]
    integrity_level["Integrity Level"]
    installer_detection["Installer Detection"]
    file_registry_virtualization["File/Registry Virtualization (VirtualStore)"]
    requested_execution_level["requestedExecutionLevel (Manifest)"]
    runtime_data_storage["Runtime Data Storage Location"]
    user_profile_storage_location["User Profile Storage Location"]
    per_machine_install["Per-Machine Installation"]
    per_user_install["Per-User Installation"]
    administrator_broker_model["Administrator Broker Model"]
    sporadic_admin_operation["Infrequent Administrator Operation"]
    os_service_model["Operating System Service Model"]
    continuous_unattended_admin_operation["Continuous unattended admin operations"]
    elevated_task_model["Elevated Task Model"]
    short_scheduled_admin_task["Short Routine Administrative Job"]
    admin_com_object_model["Administrator COM Object Model"]
    existing_com_integration["Existing COM-Based Integration"]
    administrator_protection["Administrator Protection (Preview)"]
    windows_service["Windows Service"]
    windows_firewall["Windows Defender Firewall"]
    protected_system_location -->|"requires"| admin_rights
    uac -->|"uses"| integrity_level
    uac -.->|"requires"| admin_rights
    installer_detection -.->|"may cause"| uac
    file_registry_virtualization -->|"incompatible with"| requested_execution_level
    protected_system_location -->|"not recommended for"| runtime_data_storage
    user_profile_storage_location -->|"recommended for"| runtime_data_storage
    per_machine_install -->|"requires"| protected_system_location
    per_user_install -->|"requires"| user_profile_storage_location
    per_machine_install -->|"requires"| admin_rights
    administrator_broker_model -->|"recommended for"| sporadic_admin_operation
    os_service_model -->|"recommended for"| continuous_unattended_admin_operation
    elevated_task_model -->|"recommended for"| short_scheduled_admin_task
    admin_com_object_model -->|"recommended for"| existing_com_integration
    administrator_protection -.->|"successor to"| uac
    installer_detection -->|"incompatible with"| requested_execution_level
    windows_service -.->|"requires"| admin_rights
    windows_firewall -.->|"requires"| admin_rights
    elevated_task_model -->|"requires"| admin_rights
    administrator_broker_model -.->|"requires"| admin_rights
    os_service_model -->|"requires"| admin_rights
    admin_com_object_model -->|"requires"| admin_rights

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (22 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What Does “Needs Administrator Privileges” Even Mean?

The first thing to untangle here is thinking about the user and the process separately.

Windows UAC is a security feature for preventing unauthorized changes to the OS. Microsoft Learn explains that UAC notifies you when changes requiring administrator-level permissions are about to be made.¹

Furthermore, the official UAC explanation states that apps requiring an administrator access token prompt the end user for consent, and that child processes inherit the parent process’s access token, with parent and child running at the same integrity level.²

Two things follow from this.

2.1 Even an “administrator user” is not running as an administrator all the time

Microsoft Learn explains that with UAC enabled, even processes launched by members of the Administrators group run with standard user rights unless specifically elevated.⁶

That is because two access tokens are created when an administrator user logs on, and only the restricted one is used most of the time. As a diagram, it looks like this.²

flowchart TD
    L["An administrator user logs on"] --> S["Windows prepares two tokens"]
    S --> F["Filtered token<br/>standard-user equivalent"]
    S --> A["Full administrator token<br/>used only when elevated"]
    F --> N["Everyday app launches<br/>File Explorer included"]
    N --> C["Child processes inherit the parent token<br/>so children are standard-user equivalent too"]
    N --> Q{"Did it try to touch a<br/>protected area or a service"}
    Q -- "No" --> OK["It just runs"]
    Q -- "Yes" --> P["UAC consent prompt"]
    P --> A
    A --> E["Only an elevated process<br/>can change protected areas"]

Figure 3: When an administrator user logs on, two tokens are created, and everyday work runs on the standard-user-equivalent one.

“I am an administrator user, yet UAC appears every time” happens because an operation that only the full administrator token can perform arrives at a process started with the filtered token. Since the token is fixed at launch, it also follows that the only way to add privileges later is to start a new process.

In other words:

• Your Windows account is an administrator
• But the app you just double-clicked is unelevated
• So UAC appears only at the moment of an operation that needs administrator privileges

This is normal.

“I am an administrator - why am I still short on permissions?” is entirely natural behavior on Windows.

2.2 You cannot make “just this one operation” suddenly administrator within the same process

UAC is not function-level magic - it is about which token the process is running under. Since parent and child processes inherit tokens, the design of “inside an unelevated UI process, make some methods administrator only at the moment a button is pressed” is not possible.²

If you need it, you have to use

• a separate EXE
• a service
• a highest-privilege task
• elevated COM

that is, a separate execution unit.¹⁴

Design without knowing this premise and you usually end up with the somewhat painful request: “we’d like just this button to run as administrator.”

flowchart TB
    accTitle: You cannot elevate only part of a process
    accDescr: A diagram showing that UAC is about which token a process runs under and that child processes inherit the parent token, so some methods inside an unelevated UI process cannot be made administrator, and that the work must instead be split into a separate execution unit such as a separate EXE, a service, a highest-privilege task, or elevated COM.
    p1["Unelevated UI process"] -.-> p2["Cannot make only some methods administrator"]
    p1 --> p3["Move it to a separate execution unit if needed"]
    p3 --> q1["Split out a separate EXE"]
    p3 --> q2["Use a service"]
    q1 --> q3["Use a highest-privilege task"]
    q2 --> q4["Use elevated COM"]

Figure 4: Elevation is per process, so the work that needs it belongs in a separate execution unit.

These two points are also fertile ground for misunderstanding, so section 9, “Common Misconceptions,” revisits them in Q&A form. When explaining this internally, section 9 is shorter and easier to quote.

3. What Decides It - How to Tell, First

The clearest way to tell is along these three lines.

1. Where are you writing?
2. Who does the change affect?
3. Are you touching something the OS protects?

3.1 The main areas where writing requires elevation

Since everything that follows builds on it, here is a list of the areas where “trying to write here means elevation.” Almost every case from section 4 onward maps to one row of this table.

Only the last row is a clear “not required,” C:\ProgramData is conditional, and everything else sits on the elevation side. Put the other way round, whether you can move the app’s write destinations onto that last row and %ProgramData% decides nearly all of the elevation question.⁴⁶⁷

flowchart TB
    accTitle: Elevation depends on where you can move the writes
    accDescr: A diagram showing that if an app can move its write destinations under the user profile and ProgramData it moves closer to a design with no elevation, and that if it keeps writing to protected areas it stays on the elevation side.
    w1["Identify where the app writes"] --> j1{"Can the writes move to the user profile and ProgramData"}
    j1 -->|"They can"| r1["Closer to a design with no elevation"]
    j1 -->|"They stay in protected areas"| r2["Stays on the side that needs elevation"]

Figure 5: What mostly decides elevation is how far you can move the write destinations.

3.2 A decision table by what you want to do

Turning that around so you can look it up from the “what you want to do” side gives the following. The verdicts are standardized as Required / Depends / Not required.

Summed up very bluntly:

• Changes for yourself tend to work as a standard user
• Changes for everyone tend to involve an administrator
• Touching the OS’s safety boundaries requires an administrator

Just checking these three first makes “why is UAC appearing” far easier to explain.

flowchart TB
    accTitle: Tell by asking who the change is for
    accDescr: A diagram showing the blunt but practical rule that changes for yourself tend to work as a standard user, changes for everyone tend to involve an administrator, and touching the safety boundaries of the OS requires an administrator.
    q1{"Who is the change for"}
    q1 -->|"For yourself"| r1["Tends to work as a standard user"]
    q1 -->|"For everyone"| r2["Tends to involve an administrator"]
    q1 -->|"The safety boundaries of the OS"| r3["Requires an administrator"]

Figure 6: Just asking who the change is for makes it far easier to explain why UAC appears.

4. Typical Cases Where Administrator Privileges Are Likely Required

4.1 Installation, updates, and uninstallation for all users

Microsoft Learn’s UAC architecture explanation says that many installers write to system directories and registry keys, that standard users lack sufficient access, and that Windows detects installation programs and requests elevation.³

The key point: the installer is not “privileged because it is an installer” - elevation is needed because the write destination is a protected area.

The typical cases:

• Deploying into Program Files
• Writing machine-wide information into HKLM
• Performing COM registration or integration for all users
• Installing services or drivers
• Owning a machine-wide update path

These are the cases where administrator privileges tend to be required.³⁸

flowchart TB
    accTitle: Why installers ask for elevation
    accDescr: A diagram showing that elevation is required not because an installer is privileged but because it writes to system directories and registry keys such as Program Files and HKLM, for which a standard user lacks sufficient access, so Windows detects the installation program and requests elevation.
    i1["Many installers"] --> i2["Write to system directories and registry keys"]
    i2 --> i3["A standard user lacks sufficient access"]
    i3 --> i4["Windows detects this and requests elevation"]
    i1 -.-> i5["Not because an installer is privileged"]

Figure 7: Elevation is needed because the installer’s write destination is a protected area.

4.2 Writing runtime data into Program Files or HKLM

This one is also extremely common. Microsoft’s UAC design guide explains that unnecessary elevation should be eliminated, and that much older software requires administrator privileges unnecessarily because it writes to HKLM / HKCR or the Program Files / Windows system folders.⁴

Furthermore, the explanation of standard users states explicitly that they cannot write to the Program Files folder or HKEY_LOCAL_MACHINE, nor perform system-changing operations.⁶

In other words, data that changes at run time - things like

• configuration files
• logs
• caches
• per-user state
• recent-history lists

kept in the installation folder or HKLM is, on its own, enough to turn the app into “this app won’t run unless started as administrator.”

And this happens, not uncommonly, not because the app is genuinely an administrator tool, but simply because the choice of storage location is wrong.

flowchart TB
    accTitle: What happens when runtime data goes into a protected area
    accDescr: A diagram showing that putting runtime data such as settings, logs, caches, and history into the installation folder or HKLM easily turns the app into one that only runs when started as administrator, and that the cause is usually the choice of storage location rather than the app genuinely being an administrator tool.
    d1["Runtime data such as settings, logs, caches, and history"] --> d2["Put into the installation folder or HKLM"]
    d2 --> d3["Becomes an app that only runs when started as administrator"]
    d3 -.-> d4["Usually caused by nothing but the choice of storage location"]

Figure 8: The real cause of “administrator required every time” is usually where the runtime data lives.

4.3 Registering or reconfiguring Windows services

Services are managed by the OS, so naturally they cannot be touched lightly.

The official documentation on Service Control Manager access rights explains that calling CreateService requires SC_MANAGER_CREATE_SERVICE, and that only processes with Administrator privileges can open a handle usable with CreateService.⁸

It also states that SERVICE_CHANGE_CONFIG, required for ChangeServiceConfig / ChangeServiceConfig2, should be granted only to administrators, because it allows changing the EXE the system executes.⁸

So operations like

• registering a service
• changing a service’s executable or startup type
• deleting a service
• changing a service’s security descriptor

assume administrator privileges.

flowchart TB
    accTitle: Service operations and administrator privileges
    accDescr: A diagram showing that calling CreateService requires SC_MANAGER_CREATE_SERVICE and that only a process with Administrator privileges can open such a handle, and that SERVICE_CHANGE_CONFIG needed for reconfiguration should be granted only to administrators because it allows changing the EXE the system executes.
    s1["Registering a service"] --> s2["Requires SC_MANAGER_CREATE_SERVICE"]
    s2 --> s3["Only an administrator process can open the handle"]
    t1["Reconfiguring a service"] --> t2["Requires SERVICE_CHANGE_CONFIG"]
    t2 --> t3["Documented as granted to administrators only"]

Figure 9: Services are managed by the OS, so both registration and reconfiguration assume administrator privileges.

4.4 Installing kernel drivers

Microsoft Learn explains that standard users cannot perform system-changing tasks such as installing kernel-mode drivers.⁶

This is a very clear boundary. Drivers run on the kernel side, so they cannot be treated on par with ordinary “saving a user app’s settings.”

• Installing a device driver
• Adding a virtual or filter driver
• Changing components involved in boot or I/O

It is safe to assume operations like these require administrator privileges.

flowchart TB
    accTitle: Kernel drivers as the clearest boundary
    accDescr: A diagram showing that drivers run on the kernel side and therefore cannot be treated on par with saving an ordinary user app's settings, and that system-changing tasks such as installing a kernel-mode driver cannot be performed by a standard user.
    k1["Installing a driver"] --> k2["Puts a component that runs in the kernel into the system"]
    k2 --> k3["A system-changing task"]
    k3 --> k4["Cannot be performed by a standard user"]
    k1 -.-> k5["Not on par with saving a user app's settings"]

Figure 10: Anything that touches the kernel sits on the administrator side of the clearest boundary there is.

4.5 Configuring the firewall or high-privilege tasks

The firewall is also part of the OS’s security boundary. Microsoft Learn’s firewall configuration instructions state explicitly that operating Windows Firewall with Advanced Security on a single device requires administrative rights on that device.⁹

As for the Task Scheduler, TASK_RUNLEVEL_LUA is defined as least privilege and TASK_RUNLEVEL_HIGHEST as running with the highest privileges, and the schtasks documentation states that scheduling / viewing / changing all tasks on the local computer requires membership in the Administrators group.¹⁰

In summary, configurations such as

• adding or changing Windows Firewall rules
• registering specific processing as a highest-privilege task
• running jobs as another user or as SYSTEM

sit on the side that requires administrator privileges.

flowchart TB
    accTitle: Firewall rules and high-privilege tasks
    accDescr: A diagram showing that changing firewall rules requires administrative rights on that device and that registering or running a task at the highest privileges also assumes membership in the Administrators group, placing both on the side that requires administrator privileges.
    f1["Change a firewall rule"] --> f2["Requires administrative rights on that device"]
    g1["Register and run a task at the highest privileges"] --> g2["Both registration and execution assume elevation"]
    f2 --> h1["On the administrator side as part of the security boundary of the OS"]
    g2 --> h1

Figure 11: Firewall rules and high-privilege tasks are both security boundaries of the OS, so both sit on the administrator side.

5. Typical Cases That Often Do Not Need Administrator Privileges

It is tempting to see Windows as “demanding administrator at every turn,” but in reality there are surprisingly many parts that can be designed not to need administrator privileges.

5.1 Your own settings, cache, and logs

Microsoft Learn explains that, rather than relying on virtualization for compatibility, apps should store data in per-user locations, or in computer locations within %alluserprofile% with correctly set ACLs.⁷

In practice, this split keeps things tidy:

• User-specific: %AppData%, %LocalAppData%, HKCU
• Shared but updated at run time: %ProgramData% + ACL design
• The executable itself: protected areas such as Program Files

With this separation in place, you can have administrator-installed app binaries with everyday usage unelevated.

flowchart TB
    accTitle: The three-way split of data
    accDescr: A diagram showing that separating user-specific data into AppData and HKCU, shared data that changes at run time into ProgramData with a designed ACL, and the executable itself into protected areas such as Program Files lets installation require an administrator while everyday use stays unelevated.
    z0["What the app handles"] --> z1["User-specific data"]
    z0 --> z2["Shared data that changes at run time"]
    z0 --> z3["The executable itself"]
    z1 --> y1["AppData / HKCU"]
    z2 --> y2["ProgramData plus a designed ACL"]
    z3 --> y3["Protected areas such as Program Files"]
    y2 -.-> y4["Everyday use can stay unelevated"]

Figure 12: With this three-way split, elevation is needed only at the moment of installation.

5.2 Per-user installation and updates

Per-user deployment examples appear routinely in Microsoft’s official documentation.

For example, the Remote Desktop client documentation explains that per-user installation installs under each user profile’s LocalAppData, and users can update without administrator rights.¹¹

The OneDrive documentation states that it is per-user by default, that per-machine installation runs the command with /allusers and consequently raises a UAC prompt, and further that per-user goes under %localappdata% while per-machine goes under Program Files.¹²

What this tells us: the word “installation” alone does not decide whether administrator privileges are needed.

• If each user installs into their own area, no administrator may be needed
• If installing into an area shared by all users, an administrator tends to be needed

What matters is deciding per-user or per-machine first.

flowchart TB
    accTitle: The word installation does not decide the answer
    accDescr: A diagram showing that a per-user installation in which each user installs into their own area may need no administrator while a per-machine installation into an area shared by all users tends to need one, so the word installation on its own does not decide whether administrator privileges are required.
    i0{"Which kind of installation"}
    i0 -->|"per-user"| i1["Each user installs into their own area"]
    i0 -->|"per-machine"| i2["Installs into an area shared by all users"]
    i1 --> i3["May need no administrator"]
    i2 --> i4["Tends to need an administrator"]

Figure 13: Installation does not automatically mean administrator; per-user versus per-machine decides it.

5.3 Ordinary UI operations and business logic

Conversely, processing like the following requires no administrator privileges in itself.

• Opening documents and images
• Editing files under your own profile
• Performing HTTP or database communication
• Executing business logic
• Displaying results on screen
• Reading and writing your own settings

If “run the whole app as administrator” is nevertheless required, the cause is usually not the app’s core functionality but some peripheral operation touching a protected area.

flowchart TB
    accTitle: The cause is the peripheral work, not the core features
    accDescr: A diagram showing that opening documents, running business logic, and reading and writing your own settings need no administrator privileges in themselves, so when the whole app still demands administrator execution the cause is usually some peripheral operation touching a protected area.
    m1["Opening documents, communicating, running business logic"] --> m2["Needs no administrator privileges in itself"]
    m3["The whole app still demands administrator execution"] --> m4["Some peripheral operation touches a protected area"]
    m4 -.-> m5["The cause is not the core features"]

Figure 14: If the core work is ordinary yet administrator is required, suspect where the peripheral work writes.

6. Why Does the App Say “Run Me as Administrator”?

6.1 The manifest declares requireAdministrator

In the application manifest, requestedExecutionLevel declares the required privilege level. Microsoft Learn defines these three.¹³

• asInvoker: runs with the same privileges as the launching process
• highestAvailable: runs with the highest privileges available
• requireAdministrator: runs with administrator privileges

If an app is set to requireAdministrator, elevation is assumed at every launch. Even with highestAvailable, elevation can come into play depending on the environment.¹³

So the most straightforward answer to “why does UAC appear every time” is: because the app declares it that way.

flowchart TB
    accTitle: The three requestedExecutionLevel declarations
    accDescr: A diagram showing that the requestedExecutionLevel in an application manifest has three values, asInvoker, highestAvailable, and requireAdministrator, that requireAdministrator assumes elevation at every launch, and that highestAvailable can also involve elevation depending on the environment.
    a1["requestedExecutionLevel in the manifest"] --> b1["asInvoker"]
    a1 --> b2["highestAvailable"]
    a1 --> b3["requireAdministrator"]
    b1 --> c1["Same privileges as the launcher"]
    b2 --> c2["Elevation depending on the environment"]
    b3 --> c3["Elevation assumed at every launch"]

Figure 15: The most straightforward reason UAC appears every time is the manifest declaration.

6.2 It is caught by Windows’ installer detection

The UAC architecture explanation says Windows has installer detection technology, and that many installation programs write to protected system locations and therefore need elevation.³

Moreover, this is not simply about being named setup.exe - Windows makes a somewhat heuristic judgment of “this looks like an installer.” The official documentation lists conditions such as:³

• 32-bit executables
• No requestedExecutionLevel attribute
• An interactive process launched by a standard user with UAC enabled
• File names including words like install, setup, update, and so on

So SetupLauncher.exe or Updater.exe suddenly requesting elevation is not strange at all, by Windows’ own design.

flowchart TB
    accTitle: The conditions that trigger installer detection
    accDescr: A diagram showing that Windows installer detection heuristically decides that an executable looks like an installer when it is a 32-bit executable with no requestedExecutionLevel attribute, run interactively by a standard user with UAC enabled, and named with a word such as install, setup, or update, and then requests elevation.
    c1["32-bit executable"] --> e1["Judged to look like an installer"]
    c2["No requestedExecutionLevel attribute"] --> e1
    c3["File name contains install / setup / update and the like"] --> e1
    e1 --> e2["Elevation is requested"]

Figure 16: A combination of name and attributes alone is enough to be treated as an installer and asked to elevate.

6.3 A legacy app that “happened to work” thanks to virtualization

This part is very easy to misunderstand.

Microsoft Learn explains that UAC provides file and registry virtualization for non-compliant apps that attempt to write to protected areas. At the same time, it states explicitly that this is a short-term compatibility measure, not a long-term solution.³⁷

Furthermore, virtualization has limits:

• It does not apply to elevated apps
• It applies only to 32-bit apps
• It is disabled when a manifest with requestedExecutionLevel is present
• Apps should properly be fixed to write to the correct locations

Those are the conditions.³⁷

In other words, an old 32-bit app may have “appeared to write into Program Files without administrator rights” - but that may simply mean it was being silently redirected to the VirtualStore, not writing correctly.

For this reason, at moments like

• moving to 64-bit
• adding a manifest
• changing the build setup
• progressing toward UAC compliance

a “storage location design mistake” that never surfaced before can suddenly become visible.

flowchart TB
    accTitle: How happened to work under virtualization surfaces later
    accDescr: A diagram showing that a non-compliant 32-bit app writing to a protected area is redirected to the VirtualStore and appears to work, that this is only a short-term compatibility measure, and that moving to 64-bit or adding a manifest stops virtualization from applying so the storage design mistake suddenly surfaces.
    v1["A non-compliant 32-bit app writes to a protected area"] --> v2["Virtualization redirects it to the VirtualStore"]
    v2 --> v3["Appears to work although the write is not correct"]
    v3 --> v4["Going 64-bit or adding a manifest stops virtualization from applying"]
    v4 --> v5["The storage design mistake surfaces suddenly"]

Figure 17: Virtualization is a stopgap, so the design mistake becomes visible the moment the environment changes.

6.4 The places touched at run time are simply wrong

In practice, this ends up being the most common cause.

• Saving settings next to the EXE
• Writing logs into the installation folder
• Creating temporary files under Program Files
• Writing per-user state into HKLM

Build the app this way and you get the awkward shape of an app whose body is an ordinary UI, yet whose launch requires administrator privileges.⁴⁶

The case of “administrator because the storage location is wrong,” rather than “administrator because the operation is advanced,” is genuinely common.

6.5 How to find out which one applies to your app

Sections 6.1 through 6.4 are the shapes the cause can take, but an actual investigation has to establish which one applies to your app. These two steps are enough, in this order.

Step 1: Look at requestedExecutionLevel in the manifest

First, check whether the app declares elevation for itself. The manifest embedded in an EXE can be extracted with mt.exe from the Windows SDK.

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1 is the resource ID of the manifest embedded in an executable. Look in the extracted XML for a line like this.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

If it says requireAdministrator, section 6.1 is your confirmed cause. If it says asInvoker, the declaration is not the source, so move on to step 2. There may also be no embedded manifest at all. That too is important information: a 32-bit executable with no requestedExecutionLevel can be hit by both installer detection from 6.2 and virtualization from 6.3.³

Step 2: Check whether copies have appeared in VirtualStore

Next, check whether the files you think you wrote to a protected area were actually virtualized. The redirection target is fixed.

dir /s /a "%LocalAppData%\VirtualStore"

If your app’s configuration files or logs are sitting there, then the app was not writing to Program Files at all; it was being redirected to a per-user copy. For example, a write to C:\Program Files\Contoso\Settings.ini is redirected to %LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini.³

The registry side works the same way: a write to HKEY_LOCAL_MACHINE\Software is redirected to HKEY_USERS\<the user's SID>_Classes\VirtualStore\Machine\Software. From the current user’s point of view, opening HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software in Registry Editor shows the same thing.⁷

These two checks make it clear whether “administrator privileges required” comes from the declaration or the storage location. If it is the storage location, fixing where the data lives, as in 7.3, is the real answer; adding elevation is not a fix.

flowchart TB
    accTitle: Two steps to confirm the cause
    accDescr: A diagram showing that you first extract the manifest embedded in the EXE with mt.exe and read requestedExecutionLevel, confirming the declaration as the cause if it says requireAdministrator, and that if it says asInvoker you check whether copies of your app have appeared in the VirtualStore, in which case the storage location is the cause and fixing where the data lives is the real answer.
    s1["Step 1: read requestedExecutionLevel in the manifest"] --> j1{"What is declared"}
    j1 -->|"requireAdministrator"| r1["The declaration is the confirmed cause"]
    j1 -->|"asInvoker or no declaration"| s2["Step 2: check for copies in the VirtualStore"]
    s2 -->|"Copies are there"| r2["The storage location is the cause"]
    r2 --> r3["Fixing where the data lives is the real answer (adding elevation is not)"]

Figure 18: Declaration or storage location: two checks separate the cause cleanly.

7. How to Design Away Unnecessary Elevation

7.1 The baseline is asInvoker

Unless the whole app genuinely is a system administration tool, the baseline is running the ordinary UI app unelevated. In manifest terms, asInvoker is the declaration “run with the same privileges as the launcher.”¹³

Run everything - everyday screen operations, business logic, per-user settings - as administrator, and the problems multiply:

• the attack surface widens
• operations become hard to explain
• UAC appears every time
• you lose sight of “which operations actually need administrator rights”

Microsoft’s UAC design guide likewise explains that unnecessary elevation should be eliminated, and administrator privileges reserved for the tasks that genuinely need them.⁴

flowchart TB
    accTitle: The problems that multiply when everything runs as administrator
    accDescr: A diagram showing that running everyday screen operations and business logic as administrator widens the attack surface, makes operations hard to explain, raises UAC every time, and hides which operations actually need administrator, so the baseline is running the ordinary UI app unelevated.
    a1["Run everything as administrator"] --> b1["The attack surface widens"]
    a1 --> b2["UAC appears every time"]
    b1 --> b3["Operations become hard to explain"]
    b2 --> b4["The operations that genuinely need it become invisible"]
    b3 --> c1["Keep the baseline unelevated with asInvoker"]
    b4 --> c1

Figure 19: The baseline is asInvoker, with elevation reserved for the tasks that genuinely need it.

7.2 Split only the administrator-requiring processing into a separate execution unit

Microsoft Learn explicitly presents models in which an app with administrator-requiring operations still runs as a standard user app, separating only the necessary parts.¹⁴

The four representative ones:

• Administrator Broker Model Standard-user UI app + administrator helper EXE
• Operating System Service Model Standard-user UI + resident service
• Elevated Task Model Standard-user UI + highest-privilege scheduled task
• Administrator COM Object Model Standard-user UI + elevated COM

The rough division of labor:

• Occasional administrator operations: helper EXE
• Constant / unattended / frequent: service
• Short routine jobs: highest task
• Existing COM assumed: elevated COM

Making this design concrete for Windows apps is covered in detail in the separate article How to Concretely Isolate “Only the Operations That Need Administrator Privileges” in a Windows App.

flowchart TB
    accTitle: Choosing among the four separation models
    accDescr: A diagram showing how to choose among the models that keep the app running as a standard user while separating the administrator work, using a helper EXE from the Administrator Broker Model for occasional operations, a service for constant unattended frequent work, a highest-privilege task for short routine jobs, and elevated COM when existing COM is assumed.
    q1{"What is the nature of the administrator work"}
    q1 -->|"Only occasionally"| m1["helper EXE (Broker Model)"]
    q1 -->|"Constant, unattended, frequent"| m2["Service"]
    m1 --> m3["Highest-privilege task for short routine jobs"]
    m2 --> m4["Elevated COM when existing COM is assumed"]

Figure 20: There are four separation models, chosen by how often and in what shape the administrator work happens.

7.3 Put runtime data in the right place

The principle for storage locations is quite simple.

• User-specific data: HKCU or %AppData%
• Local-only cache: %LocalAppData%
• Shared but changing at run time: %ProgramData% + ACLs
• The executable itself: Program Files

Microsoft Learn likewise explains that apps should store in per-user locations, or in %alluserprofile% (in practice ProgramData) with correctly set ACLs.⁷

With this in order, it becomes much easier to have only the installer elevate, while the running app stays unelevated.

flowchart TB
    accTitle: Fixing the storage locations narrows elevation down
    accDescr: A diagram showing that organizing storage by the principle of user-specific data in HKCU or AppData, local-only cache in LocalAppData, shared data that changes at run time in ProgramData with ACLs, and the executable itself in Program Files makes it easy to have only the installer elevate while the running app stays unelevated.
    p1["Organize runtime storage locations by the principle"] --> p2["Elevation is needed only to place the executable"]
    p2 --> p3["Only the installer elevates"]
    p2 --> p4["The running app stays unelevated"]

Figure 21: Getting the storage locations right is the groundwork for confining elevation to the moment of installation.

7.4 Decide per-user vs. per-machine first

This is the part that gets overlooked surprisingly often.

• Should each user be able to install the app themselves?
• Should it go into one location shared by all users?
• Who is responsible for updates?
• Is running the executable from a user profile acceptable?

Leave this judgment vague, and later things get messy:

• administrator for installation only
• administrator for execution too
• administrator for updates too
• only some parts in user context

The per-user / per-machine difference is not merely a distribution-method question - it is the privilege design itself.

flowchart TB
    accTitle: Decide per-user or per-machine first
    accDescr: A diagram showing that deciding up front whether each user installs the app themselves, whether it goes into one location shared by all users, and who is responsible for updates keeps the privileges for installation, execution, and updates aligned, and that the per-user versus per-machine difference is the privilege design itself rather than a distribution method.
    d1["Decide per-user or per-machine first"] -->|"When it is decided"| d2["Privileges for installation, execution, and updates line up"]
    d1 -.->|"When it stays vague"| d3["A mess of administrator here and user context there"]
    d2 --> d4["The privilege design itself, not a distribution method"]

Figure 22: The per-user / per-machine call is a privilege design decision to make at the start.

8. Which Way Is Windows Heading?

As of March 2026, Windows 11 has a feature called Administrator protection (preview). Microsoft Learn describes it as maintaining a deprivileged state in normal operation, granting admin rights just-in-time only when needed.⁵

Microsoft further explains that it requires explicit authentication before operations that need administrator privileges, such as installing software, changing system settings like the clock or the registry, and accessing sensitive data.⁵

The feature itself is still in preview, and general rollout is staged.⁵

It is worth being clear about what preview means in practice. A feature labeled preview can change in behavior and settings before general availability, and it may not even be possible to enable it in every environment. So for now, the following uses are best avoided.

• Rolling it out company-wide as the standard production configuration
• Assuming it is enabled and skipping elevation design on the app side
• Making it a mandatory requirement for running in a customer environment

The realistic position is to check its behavior in a test environment and align the design with the assumption that things will move this way in future. Put the other way round, if you make asInvoker the baseline now and keep elevation to a minimum, general availability of this feature will not catch you off guard.

flowchart TB
    accTitle: A realistic position on a preview feature
    accDescr: A diagram showing that because a preview feature can change in behavior and settings before general availability, it should not be rolled out as the standard production configuration, assumed when skipping elevation design, or made a mandatory customer requirement, and that the realistic position is to check its behavior in a test environment while aligning the design with the direction it points to.
    p1["Administrator protection is in preview"] -.-> p2["Avoid company-wide production rollout or making it mandatory"]
    p1 --> p3["Check its behavior in a test environment"]
    p3 --> p4["Align the design with the direction it points to"]
    p4 --> p5["Keeping elevation minimal with asInvoker means no surprises later"]

Figure 23: Do not build on a preview feature; just point the design the same way.

The direction, though, is quite clear.

• Do not hold an administrator token at all times
• Elevate only at the moment of need
• Isolate elevated sessions
• Make “when, which app, and why it became administrator” more explicit

In other words, it is fair to expect that the “just run everything as administrator” design will mesh worse and worse with Windows going forward.

flowchart TB
    accTitle: The direction Windows is heading
    accDescr: A diagram showing that Windows is moving toward not holding an administrator token at all times, elevating only at the moment of need, isolating elevated sessions, and making it explicit when and why which app became administrator, so a design that runs everything as administrator will mesh worse and worse.
    w1["Do not hold an administrator token at all times"] --> w2["Elevate only at the moment of need"]
    w2 --> w3["Isolate elevated sessions"]
    w3 --> w4["Make it explicit when, which app, and why it is administrator"]
    w4 -.-> w5["Running everything as administrator meshes worse over time"]

Figure 24: The direction is clear: elevation is moving toward explicit, only at the moment of need.

9. Common Misconceptions

9.1 “I am an administrator user, so UAC should not appear”

It appears. With UAC enabled, even members of the Administrators group run ordinary processes unelevated, elevating only when needed.⁶²

9.2 “Installation always means administrator”

Not always. Designs exist that distribute without administrator privileges, such as per-user installation into %LocalAppData%.¹¹¹²

9.3 “We place the app in Program Files, so we may as well save the settings there”

No. The executable’s location and the storage location for data that changes at run time should be separated. Microsoft itself cites runtime writes to Program Files and HKLM as the classic example of unnecessary elevation.⁴⁷

9.4 “Just run it as administrator and all the design problems disappear”

They do not. It may work temporarily, but the attack surface, operability, distribution, and supportability all tend to deteriorate. Moreover, you cannot conveniently elevate just one part of the same process.²¹⁴

9.5 “It used to work, so it must still be correct”

Not necessarily. If a legacy 32-bit app only “happened to work” thanks to virtualization, the problem surfaces when you move to 64-bit or add a manifest. Virtualization is a stopgap for compatibility, not a long-term solution.³⁷

10. Summary

Whether Windows administrator privileges are needed comes down, in a phrase, to “where you are going to change what.”

• Changes for yourself: standard user usually suffices
• Changes for all users or the whole machine: an administrator is likely needed
• Touching the OS’s protected areas or security boundaries: administrator privileges are required

And what really matters in practice is separating the operations that genuinely need administrator privileges from the operations that merely ended up needing an administrator because of where they store data.

In Windows app development especially, these lines are highly effective.

• Make the UI unelevated by default
• Cut administrator processing into a separate EXE / service / task
• Move runtime data to the AppData / HKCU / ProgramData side
• Decide per-user / per-machine at the start

flowchart TB
    accTitle: The lines that work in Windows app development
    accDescr: A diagram showing the practical lines to draw in Windows app development, keeping the UI unelevated by default, cutting administrator work into a separate EXE, service, or task, moving runtime data to AppData, HKCU, or ProgramData, and deciding per-user versus per-machine at the start.
    g1["Keep the UI unelevated by default"] --> g2["Cut administrator work into a separate EXE / service / task"]
    g2 --> g3["Move runtime data to AppData / HKCU / ProgramData"]
    g3 --> g4["Decide per-user / per-machine at the start"]

Figure 25: Draw these four lines first and UAC, distribution, and design all become much clearer.

“Does it need administrator privileges” is not a question of how grand the app is. It is a question of which boundary of the OS it touches.

Carry this view from the start, and the behavior of UAC, the choice of installation method, and the app design all become dramatically clearer.

11. Related Articles

• How to Concretely Isolate “Only the Operations That Need Administrator Privileges” in a Windows App
• A Minimum Security Checklist for Windows App Development
• Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater

12. References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Why does Windows tell me the requested operation requires elevation?

Because the app is trying to touch a boundary that affects the OS or the whole machine. The typical cases are writing to protected areas such as Program Files, Windows, System32, or HKLM, registering or reconfiguring a Windows service, installing a kernel driver, and changing firewall rules. Elevation is also requested when the app manifest declares requireAdministrator, or when the file name contains a word such as install / setup / update and Windows installer detection picks it up. Very often this happens not because the operation is advanced, but simply because the settings or logs are being saved into a protected area.

Why does UAC appear even though I am on an administrator account?

Because with UAC enabled, even a process launched by a member of the Administrators group runs with standard user rights unless it is specifically elevated. Your Windows account may be an administrator, but the app you just launched is running unelevated, so UAC appearing only at the moment of an operation that needs administrator privileges is entirely normal behavior on Windows. The user belonging to the Administrators group and the app running with an administrator access token have to be treated as two separate things.

Does installing an app always require administrator rights?

Not always. A per-user installation that goes under %LocalAppData% can be designed to distribute and update without administrator privileges. As real examples, the per-user installation of the Remote Desktop client goes under each user profile's LocalAppData and can be updated without administrator rights, and OneDrive is a per-user installation by default. What tends to require an administrator is the all-users (per-machine) installation that writes to Program Files or HKLM. Per-user versus per-machine is not a distribution-method question but the privilege design itself, so it should be decided first.

Can I run just part of an app with administrator rights?

Within a single process you cannot make some methods administrator only at the moment a button is pressed. UAC is about which token a process is running under, and child processes inherit the parent's token. If you need it, separate the work into a different execution unit. The four representative models are the Administrator Broker Model, which pairs a standard-user UI with an administrator helper EXE, the Operating System Service Model, which uses a resident service, the Elevated Task Model, which uses a highest-privilege scheduled task, and the Administrator COM Object Model, which uses elevated COM.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.