Microsoft EPM vs Windows 11 Administrator Protection: Enhancing your Least-Privilege architecture

85% of privileged credentials go unused for 90+ days.
That’s not access – it’s an attack surface.
Least-privilege isn’t just smart, it’s survival.

Modern Windows platforms place a strong emphasis on privilege management and security. Allowing users to operate with excessive privileges, such as full administrator rights, poses significant risks. Attackers frequently exploit elevated permissions to install malware, steal sensitive data, or disable security features. In response, Windows has evolved security features to ensure users run with only the privileges they need.

Windows’ built-in User Account Control (UAC), introduced in Windows Vista (!), was an early step to mitigate unauthorized system changes by prompting for approval or credentials when elevation is required. UAC enables users (even administrators) to run day-to-day tasks with standard rights and only elevate to admin rights when a system change is attempted. However, UAC alone is considered a “defense-in-depth” measure and not a full security boundary. To further strengthen least-privilege enforcement, Microsoft has introduced Endpoint Privilege Management (EPM) for enterprise endpoints and a new Administrator Protection feature in Windows 11. This article provides a technical overview of Microsoft EPM and Windows 11 Administrator Protection, explaining how they differ, and how each relates to UAC in protecting systems.

Please note that your individual requirements may differ from those of others, and recommendations provided in this article may not be universally applicable. This article is intended to clarify the distinctions and commonalities among various products and features, rather than serve as a comprehensive security solution. Let’s dive in!

A very simple decision tree could look like this:

In the following sections, we delve into the features and implementation of EPM and Windows 11’s Administrator Protection, compare their capabilities and use cases, and examine how each one interacts with or enhances UAC. This information will help IT professionals understand which tools to use for enforcing least privilege in different scenarios.

Microsoft Endpoint Privilege Management

Microsoft Endpoint Privilege Management (EPM) is a cloud-managed solution that enables Windows users to run with standard (non-admin) accounts and still perform certain tasks requiring administrator rights. A separately licensed part of Microsoft Intune, EPM was designed to help enterprises adhere to zero-trust and least-privilege principles without sacrificing user productivity. With EPM, common privileged operations like software installation, device driver updates, or running diagnostic tools can be done by standard users in a secure, controlled manner. This means IT departments can “remove all admin rights” from endpoints (greatly reducing risk) while empowering users to complete their work without constantly calling the helpdesk.

Features and Implementation

EPM is deeply integrated with Microsoft Intune. To use it, an organization enables the EPM add-on in Intune (requires an appropriate license such as the Intune Suite) and deploys EPM policies to Windows devices. The endpoints must be Entra ID joined or hybrid-joined (please don’t do hybrid join…) and enrolled in Intune; a small EPM agent gets installed on each managed device to enforce the policies locally. Once active, EPM adds a new “Run with elevated access” option to the Windows context menu (right-click menu) for executables on that device. Instead of the usual “Run as administrator” (which would trigger a UAC prompt asking for credentials that a standard user hopefully doesn’t have), users select “Run with elevated access”. The EPM agent then checks the elevation rules to determine if and how to elevate that program.

EPM Policies are defined in two parts: an Elevation Settings Policy and one or more Elevation Rules Policies.

• The Elevation Settings Policy globally enables EPM on the device and sets default behaviors (for any app that doesn’t have a specific rule). For example, an admin can set the default elevation response to “deny all”, “allow with user confirmation”, or “require support approval” if an application isn’t explicitly covered by a rule. They can also require additional validation for user-confirmed elevations, such as prompting the user for a business justification or forcing a re-authentication before allowing the app to run elevated. These measures ensure the user consciously acknowledges the elevated action.
• An Elevation Rule Policy contains granular rules linking specific applications or processes to an allowed elevation action. Each rule defines a detection (identifying an app by attributes like file name, path, digital signature, or hash) and an elevation action (what to do when that app is run). EPM supports several types of elevation actions: Automatic Elevation: The software is elevated silently and automatically. If a rule is set to “Automatic” for a given app, EPM will elevate it to run with admin rights without any user prompt. (This is convenient but should be used sparingly; broad automatic rules can introduce security risks if misused). User Confirmed Elevation: EPM requires the end-user to explicitly confirm the elevation. The user will right-click and choose “Run with elevated access”, then may be asked to acknowledge a prompt or provide additional info (like entering a justification or re-authenticating) before the app runs as admin. This extra step builds user awareness that they are about to run something with high privileges. Support Approved Elevation: This is a workflow where the user’s elevation request must be approved by an administrator in Intune before proceeding. The user triggers the request via the EPM prompt; an IT admin reviews and approves it (for example, through the Intune portal), and only then can the user rerun the application with elevated rights. This mode is useful for infrequent or high-risk actions – it enforces oversight. Deny: EPM can outright block certain applications from running with elevation. If an app is on a deny list, even if the user somehow has other admin capabilities, the EPM agent will prevent it from elevating. This is a safety mechanism to ensure known dangerous or unapproved programs cannot be given admin rights.

In addition to these, EPM allows policy control over any child processes spawned by an elevated application. Administrators can decide if child processes inherit the elevation or not, providing granular containment (for example, if an elevated installer launches another executable, you can require that to match a rule as well).

From an implementation standpoint, when a user tries to run something with EPM, the agent on the device evaluates the rules. If a match is found and allowed (auto or user-confirmed), the EPM service on the endpoint will “proxy” the launch with administrator privileges on behalf of the user. Under the hood, the EPM agent runs with system-level rights (since it’s deployed via Intune) and can initiate the elevated process without the user themselves being an admin. In effect, the application process gains full admin rights, but the user’s account remains a standard user. The elevated process runs in the user’s session (but not with the user’s credentials), just as if an admin had typed in credentials for UAC, except no credentials are needed because policy allowed it. If no EPM rule permits the app, then the user’s attempt would fall back to normal UAC behavior (which typically means a credential prompt that the user cannot pass).

EPM provides reporting and auditing via Intune, so admins can monitor all elevations (successful or attempted) across the organization. It distinguishes “managed elevations” (those handled by EPM policies) from “unmanaged elevations” (cases where a user actually had admin rights and used a normal Run as Administrator) to help track compliance. Typically, in a well-managed environment, unmanaged elevations would be near zero because regular users won’t have admin rights.

Enterprise Use Case: Consider an organization where employees are standard users on their Windows devices (no local admin rights). Without EPM, these users would hit a wall whenever a task needs admin privileges, e.g. manually installing software or manually updating a driver requiring IT intervention or giving the users admin rights (which undermines security). With EPM, IT can define rules such as: “Allow Software X installer to run elevated (user confirmed)”, “Require approval for elevating powershell.exe”, “Deny elevation for unknown apps”. End-users can self-serve many admin tasks: they right-click the installer or tool, select “Run with elevated access”, perhaps enter a justification, and proceed. If it’s an unapproved app, EPM will block it or guide them to request approval, rather than a generic UAC “access denied”, reducing frustration and the temptation to circumvent security.

Benefits and Security Impact

Microsoft EPM’s primary benefit is enabling broad adoption of least-privilege accounts without crippling usability. By running as standard users 99% of the time, the risk from malware or accidental changes is drastically reduced, as malware can’t simply install itself or tamper with system settings without permissions. Yet, users remain productive since IT-sanctioned tasks that need elevation are still within reach. This controlled elevation mechanism aligns with Zero Trust principles, as it minimizes standing privileges on endpoints.

Other key advantages of EPM include:

• Granular Control: IT admins have fine-grained say over what can be elevated. They can tailor policies to different groups or devices. For example, developers might get a few more authorized tools elevated than regular staff. Everything is configurable centrally in Intune.
• Auditability: Every elevation event can be logged and reviewed. Admins can see which user elevated what application and when, aiding in accountability and forensic analysis.
• Flexibility (User Confirm/Approval): The user-confirmation and support-approval workflows introduce friction for higher-risk actions, ensuring oversight. Requiring a justification or secondary auth for certain tools can deter misuse and provide additional evidence if an account is compromised (the attacker likely wouldn’t know the user’s credentials to re-auth).
• No Credential Sharing: Users never need to know an admin password for approved tasks. This prevents the very common “shared local admin password” problem or users using personal admin accounts, both risky practices. Instead, elevation is handled by the system under the hood.

At the same time, there are challenges and limitations to note:

• Intune Requirement: EPM is only available in Intune-managed environments. You need Entra ID joined machines and the Intune infrastructure in place (plus the EPM licensing) to use it. Organizations not using Intune or still running on-prem domain setups cannot leverage EPM.
• Policy Complexity: Defining the “right” set of rules requires careful planning. If rules are too permissive (for instance, using wildcards that match more than intended), malicious software might exploit them to gain elevation. Conversely, if rules are too strict or incomplete, users might be blocked from doing their jobs (leading to frustration or pressure to grant admin rights back). Microsoft’s guidance is to use strong identifiers (like file hashes or certificate signing) in rules and avoid broad matches by filename alone. Maintaining these rules is an ongoing effort, especially as software updates (hashes change) or new needs arise.
• Windows-Only & Recent OS Dependency: EPM only works on supported 64-bit versions of Windows 10 and 11 (both Intel & ARM). Very legacy systems or other OS (macOS/Linux) aren’t covered. In mixed environments, EPM would be just one piece of a bigger privilege management strategy.
• User Training: End-users may need a bit of training to understand the new “Run with elevated access” option and the process for requesting elevation. This is a different workflow than the familiar UAC prompt. Clear communication is needed so they know how to get their admin tasks done under the new system. Fortunately, the experience is straightforward once explained.
• Complex elevations: Allowing granular elevation of complex apps such as the Settings app where an Administrator would like to allow elevation of some settings but not others are not supported in EPM today.

Security Tip: When deploying EPM, Microsoft recommends setting the default elevation action to “Prompt (Support Approval or Deny)” rather than automatically allowing user-confirmed elevations for unknown apps. In practice, this means if an application isn’t in the allow list, the user would be prevented or would have to request IT approval, instead of just being able to run it with a simple confirmation. This ensures a rogue or unrecognized program can’t slip by with an opportunistic user click. Additionally, always include a specific file path or hash in rules (not just an app name) to avoid rule spoofing.

In summary, EPM transforms the Windows admin privilege model for enterprise users: rather than making everyone an administrator or constantly responding to UAC prompts with an IT override, users stay standard and the system grants temporary admin power to specific tasks when policy allows. It’s a proactive approach to least privilege, aimed at balancing security with usability in managed environments.

Windows 11 Administrator Protection

Administrator Protection is a new security feature introduced for Windows 11 (available in recent builds, and expected to become standard in new Windows 11 releases). Its goal is to fundamentally change how administrator accounts operate on a Windows 11 machine, by applying the principle of least privilege even to users who are administrators. In essence, when Administrator Protection is enabled, being a member of the Administrators group no longer means you have full admin power all the time. Instead, admin rights are wielded in a just-in-time fashion and only with explicit user authentication for each elevation. This dramatically reduces the risk that malware or user mistakes can leverage admin privileges to harm the system.

How It Works

Under Administrator Protection, when an admin-user logs into Windows 11, the system does not grant full administrator access tokens by default. Traditionally, a Windows admin account has two tokens: a limited user token and a full admin token (with UAC controlling when the latter is used). With Administrator Protection enabled, the user essentially starts with only a deprivileged user token (as if they were a standard user in practice). Whenever the user attempts an action that requires admin rights (for example, installing software or changing a system setting), Windows will prompt the user to re-authenticate via Windows Hello for Business (or another secure method) to confirm the action. Upon successful verification, the OS will behind the scenes use a special hidden account to generate an isolated admin token for that specific process. The process is then launched with this admin token, giving it the needed elevated privileges. Crucially, once that process or task completes, the admin token is destroyed. The user’s session returns to the deprivileged state, and no continuous admin session remains open.

Technically, Windows creates a System Managed Administrator Account (SMAA) (a hidden system account) that acts as the context for the elevated process. The elevated process runs under this separate account’s security context, not directly under the user’s own account. This means even though the user initiated it, the elevated process is isolated from the user’s standard context. Any time another admin-level action is performed, the whole cycle repeats: prompt for auth, create new temporary token via the system-managed account, run the process, then drop and destroy the token. As a result, administrator privileges do not persist beyond the immediate task. There is no admin-level code running under the user’s identity except for the processes they specifically authorized.

Some important characteristics and effects of Administrator Protection:

• Windows Hello for Business (WHfB) Verification: By default, the elevation prompt is tied into WHfB for authentication. This means the user may be asked for a fingerprint, face scan, or PIN (or password if WHfB is not configured) each time they perform an admin action. This two-factor style confirmation ensures that it’s really the legitimate user present and consenting. It’s more secure than the traditional UAC “Yes/No” click, which malware could simulate, or a passing-by user could abuse; WHfB involves something the malware typically can’t provide (biometric or PIN).
• No Silent Elevation: The feature enforces that every admin operation is interactive. Unlike older Windows behavior where certain trusted system actions might auto-elevate without prompting (or where users could lower UAC settings), with Administrator Protection there are no automatic elevations. Even built-in tools or Windows components cannot bypass the prompt. This ensures the user is always aware of and in control of what’s happening with admin rights at any given moment.
• Isolated Admin Session: Because the elevated process runs under a separate profile (the temporary hidden admin account), there is a true security boundary between normal processes and elevated ones. Standard user processes (even ones running as the same logged-in user) cannot inject code or tamper with the admin process, because from the OS perspective it’s a different user. In the past, UAC elevation kept the same user but just toggled tokens, which left some room for UAC bypass attacks (where malware already running as the user might piggyback on an elevated process). Administrator Protection closes that gap – the architecture more cleanly separates the two.
• Ephemeral Admin Context: The admin token’s short lifespan also means any malware would have to strike in the narrow window while an admin process is running and somehow inject itself at that moment and the user would have had to approve that process. This greatly diminishes the likelihood of successful privilege escalation attacks. If malware tries to trigger an admin action on its own, the user will get the prompt without having initiated it, which should raise red flags. Furthermore, token theft (stealing an authentication token from memory) becomes much harder, because there isn’t a long-lived admin token in the user session to steal, it’s created and destroyed quickly each time.

For example, with Administrator Protection on, suppose an admin user attempts to open a Command Prompt as administrator. They will be prompted to authenticate (say, touch their fingerprint reader). Windows then spawns the elevated Command Prompt under the system-managed admin account context. If that Command Prompt is closed and the user later tries to open another admin application (like a registry editor), they will be prompted to authenticate again, and a new separate admin token is generated for that instance. If the user runs the whoami command in an elevated session, they can actually see that the user context is something like ADMIN_<SID> rather than their own username, confirming that isolation.

Integration & Deployment: In current Windows 11 builds (as of early 2025), Administrator Protection is an optional feature that is disabled by default (to avoid surprising users). Administrators can enable it using the LocalPoliciesSecurityOptions CSP, preferably using a Settings Catalog policy in Intune or through another MDM tool that supports the CSP. It can also be enabled via the Windows Security app UI on the Account Protection page. Enabling it requires a reboot to take effect. It is available on all editions of Windows 11 (Home, Pro, Enterprise, etc.) for broad adoption. This means even non-corporate (home) users who are local admins can benefit by turning it on manually through Windows Security. Enterprises can enable it on managed machines via Intune policy or Group Policy across their fleet.

One thing to note is that when Administrator Protection is enabled, the traditional UAC settings are basically overridden for admin accounts. In fact, this feature is essentially an augmentation of UAC’s Admin Approval Mode. In Windows, Admin Approval Mode is the mechanism by which admin accounts run with filtered tokens and get prompted. Previously, Admin Approval Mode used the standard UAC consent dialog. With this feature on, Admin Approval Mode instead uses the new WHfB-based prompt (considered part of Windows Security center) for approval. In effect, it replaces the UAC prompt with a more secure workflow. The underlying concept (ask the user before elevating) remains, but it’s executed with stronger guarantees.

Security Benefits and Differences from Earlier Windows

Windows 11’s Administrator Protection brings several important security benefits:

• Eliminates “Always-On” Admin Rights: It treats Administrator accounts almost like standard accounts until the moment of need. This means that many malware techniques that assumed the user had an accessible admin token no longer work. For instance, some malware would simply prompt a user via fake UAC or invoke auto-elevating system processes; those would fail or be forced through a WHfB prompt that malware can’t satisfy.
• Prevents Stealthy Elevation: The requirement for WHfB or credential input ensures no process can silently gain elevation without the user’s knowledge. Even if the user is an admin, they will always get an interactive prompt they must approve with a gesture or credential. This effectively blocks auto-elevation mechanisms that were previously allowed for certain trusted system components (which attackers sometimes exploited by hijacking those components). Microsoft specifically highlights that auto-elevating actions are removed – every elevation is explicit.
• Hardens Against UAC Bypasses: Prior to this feature, UAC prompts (while useful) could be bypassed in some scenarios by advanced malware (for example, by injecting code into an approved process or manipulating certain system settings to fool a privileged program). Administrator Protection introduces an actual security boundary between non-elevated and elevated processes. The elevated process runs under a different user context (SMAA), so techniques like shatter attacks, DLL injection from the user context, or hooking user interface elements of the admin process are far less feasible. Microsoft describes UAC as a policy and not a security boundary, whereas Administrator Protection “creates a genuine security boundary between elevated and non-elevated contexts.” In other words, the system will treat any attempt by a standard process to interact with that isolated admin process as a cross-user security violation.
• Mitigates Token Theft and Lateral Movement: Without Administrator Protection, if an attacker manages to run code as a user with admin rights (say through phishing or an exploit), they might extract the admin token from memory or use that context to do further damage. With Administrator Protection enabled, there is no readily available admin token to steal in the user session; an attacker would have to trick the user into performing an admin action and somehow intercept that one-time token – an extremely narrow window. This thwarts many token theft and impersonation attacks that are key for malware to persist or move laterally in a network. In fact, this feature was motivated by the spike in token theft incidents, and it directly breaks the attack kill chain for malware that relies on silently elevating privileges.
• User Awareness and Control: From a human perspective, it forces administrators to be mindful. An admin can’t absentmindedly run a script that makes destructive changes without at least noticing the WHfB prompt. Each privileged action is a deliberate choice, which can reduce accidental mistakes (like changing the wrong system setting). It puts a moment of friction that says “you are about to do something with high privileges” – a useful check even for savvy admins.

While extremely beneficial, Administrator Protection does introduce some changes that admins should be prepared for:

• Per-Action Authentication: Admin users will need to authenticate (e.g. enter PIN or scan fingerprint) repeatedly, every time they do something that needs elevation. This might be seen as a minor inconvenience if many elevated operations are performed in sequence. It’s the classic security-usability trade-off: more prompts for vastly improved security. In practice, each prompt is quick, and the benefits outweigh the inconvenience for sensitive environments.
• Profile Separation Effects: Because elevated processes run under a different user profile (the SMAA), they don’t share the same environment as the user’s normal processes. This can have side effects: for example, if you run Notepad elevated to edit a system file, it will use the default settings of the SMAA profile (maybe Light theme instead of your preferred Dark theme) which might differ from your normal Notepad look and feel. Documents or files created in an elevated session might default to different directories (since “My Documents” for the SMAA is not the visible user’s documents). And certain in-memory things don’t carry over – as an example given by Microsoft, if you change a setting in an app while running it unelevated, that change isn’t reflected if you run the same app elevated, because they’re effectively different user settings. Administrators will have to be aware of this split. It’s generally a minor adjustment (most tasks that need elevation, like installers or control panel changes, are one-off and not reliant on user profile data), but it’s a difference from previous behavior.
• Application Compatibility: Most software will work fine with this model, but a few legacy or poorly designed applications might assume they can auto-launch an elevated component or that they have write access to admin-only areas once the user is admin. Such apps might need updates or special handling. That said, since UAC has been around for years, well-behaved apps typically already cope with running without admin and then elevating a part of their workflow via the UAC prompt – those should still work, just with the new prompt. It’s more the case that any in-memory assumptions (like expecting to share data between normal and elevated instances) could break. Microsoft’s guidance to developers is to design applications to run with least privilege and only request elevation for specific tasks, which aligns perfectly with this feature. You could also see this as (yet another) opportunity to make sure your super important app, developed by an intern in 1998 isn’t the weakest link in the security chain, even though the app still works.
• Not a Substitute for Malicious Prompt Awareness: If malware pops up what looks like a legitimate elevation request and the user approves it with their fingerprint without realizing, the malware will run elevated (just as it could if a user blindly approved a UAC prompt). Administrator Protection doesn’t stop intentional but ill-advised user approvals. It’s primarily about stopping behind-the-scenes or forced elevations. So user education is still important, admins should only approve prompts they initiated. The good news is that the prompt now is tied to Windows Security and likely provides info about the app requesting elevation, with color-coded cues if an app is unsigned or untrusted, helping users make informed decisions.
• Proxied Internet access: When the application or process executes using the SMAA, it is likely to lack Internet access if an authenticating proxy is in place. Consequently, running an installer that requires downloading payload from the Internet may fail due to the restricted access of the process.

Overall, Windows 11’s Administrator Protection is a major leap in securing administrative accounts. Microsoft’s security team even calls it “the most significant architectural change in Windows [security] in a generation”. It brings a level of security formerly found in specialized privilege management tools or UNIX-like sudo models directly into the OS for everyday admins.

Comparison between EPM and Administrator Protection

Microsoft EPM and Administrator Protection both serve to enforce least privilege, but they tackle different scenarios and use very different approaches. Like the simple decision chart in the beginning of this article illustrated, EPM is an Intune-managed solution primarily for standard users, whereas Administrator Protection is an OS feature for users who are already admins. The following table summarizes the key differences:

In summary, EPM and Windows 11’s Administrator Protection operate at different layers but both enforce the idea that admin rights should be tightly controlled and only granted when necessary. EPM is a policy-driven approach for standard users – ideal for organizations to remove admin rights broadly – whereas Administrator Protection is a technical control for the scenario where admin rights exist but are constrained on a per-use basis. An easy way to distinguish them: EPM empowers non-admins to do admin-required tasks; Admin Protection restrains actual admins from running amok (even unintentionally). They are complementary in the sense that an enterprise could use EPM to ensure most users have no admin rights, and also enable Administrator Protection for accounts that do have admin privileges (such as IT admins or certain power users), achieving layered security.

Relation to User Account Control (UAC)

Although UAC has been mentioned several times throughout this article, there has historically been some confusion regarding how EPM and Admin Protection are related to it. The following section provides a brief overview specifically addressing UAC.

User Account Control (UAC) is the baseline technology in Windows (since Vista!) that both of these solutions build upon or enhance. UAC’s core function is to prompt for consent or credentials whenever a task needs administrative privileges, thereby preventing silent elevation of privileges. It introduced the concept of running all apps in a standard user context by default, even for administrators, and only elevating with permission.

Under UAC:

• If you are a standard user and try to do something admin-like, you get a credential prompt (asking for an admin username/password). Without an admin credential, you’re blocked.
• If you are an administrator and UAC is enabled, you get a consent prompt (“Allow this app to make changes?”) which you can approve or deny. If you approve, your full admin token is used to run that action.

UAC was a response to the security issues from everyone running as Administrator all the time in early Windows versions. It significantly improved security in Windows by making least privilege the default for user activities. However, by itself it’s not perfect. Users became conditioned to click “Yes” on prompts, and malware found ways to manipulate or piggyback on trusted processes to bypass UAC. This is where EPM and Administrator Protection come in.

EPM and UAC

EPM does not replace UAC; rather, it works alongside UAC to handle situations UAC alone cannot. In a traditional environment without EPM, IT admins faced a dilemma: either make users local admins (and rely on UAC prompts to deter them or malware from dangerous actions), or keep them standard users (and have them call IT every time UAC blocks something they legitimately need). EPM offers a third way: keep users as standard (UAC will always block their admin attempts by default), but use EPM’s rules to pro-actively allow specific admin actions to go through without requiring the user to input admin credentials each time.

When EPM is in use, an ideal configuration might be to set the Windows UAC policy for standard users to “Prompt for consent for non-admins” or even “Automatically deny elevation requests”. This might sound counterintuitive, but the logic is that the EPM agent will catch the elevation attempt (when the user uses “Run with elevated access”) and handle it according to policy. If it’s allowed, the user won’t hit a normal UAC block at all – EPM will elevate it via system context. If it’s not allowed, the user would just get a message from EPM or see the attempt fail (which is effectively what “deny elevation requests” would do anyway). By possibly suppressing the standard UAC prompt, you avoid double prompts or confusion. Microsoft notes this can “reduce confusion when an application requires elevation and create a better end user experience” once EPM is managing elevations.

For administrators on a device, EPM by design doesn’t interfere with UAC for them. If someone is a local admin, EPM isn’t really meant for them (since its whole point is to run users without admin rights). However, it is technically possible to define EPM rules that apply even if a user is an admin, but this is rarely done and needs careful consideration. In most cases, organizations using EPM will simply not make end-users administrators at all. Any admin user (like an IT admin account) on the machine would just operate under normal UAC rules, or if it’s Windows 11, under Administrator Protection if that’s turned on.

In summary, EPM leverages UAC’s framework: a standard user still can’t elevate unless something intervenes. EPM is that “something” – it provides a managed way to intervene in the UAC elevation flow, essentially automating the approval for certain tasks (with policy enforcement and logging around it). UAC provides the enforcement mechanism, and EPM provides the intelligence on when to allow an elevation. Used together, they ensure that a standard user can’t elevate anything arbitrarily (thanks to UAC) and that they can elevate approved things seamlessly (thanks to EPM). The outcome is a much more usable environment that still adheres to least privilege. Without EPM, many orgs end up weakening UAC (by adding users to admin group or turning UAC to “never notify”) to get work done, which is risky. EPM + UAC prevents that scenario by offering a safe alternative path.

Administrator Protection and UAC

Administrator Protection in Windows 11 is essentially a reinforcement of UAC for admin accounts. In fact, Administrator Protection could be seen as “UAC 2.0” (not a Microsoft term…) specifically for administrators. It builds on the same concept of Admin Approval Mode but makes it far more secure. Under the hood, when Administrator Protection is enabled, the policy “User Account Control: Admin Approval Mode for the built-in Administrator account” (and related policies) are modified to require this new style of approval and token generation.

When Admin Protection is on, the UAC consent dialog is replaced by the Windows Security authentication dialog. Functionally, they serve a similar purpose (getting user approval for elevation), but the Windows Security dialog demands actual credentials or biometric proof, making it stronger. Also, Admin Protection ensures that after approval, the elevated process runs in a separate context, not just as a raised token of the same user. Traditional UAC simply elevated your existing session token for that process, which left some continuity that could be abused. The new method completely segregates it.

It’s worth noting that if Administrator Protection is not enabled, Windows 11 behaves like previous versions with standard UAC. So this feature is essentially an opt-in augmentation to UAC. When enabled, it eliminates some of UAC’s weaker aspects:

• For example, UAC had a concept of “auto-elevate” for trusted Windows executables (like installers signed by Microsoft). In Windows 11, these are no longer automatically elevated under Admin Protection; everything asks for approval.
• Another example: previously an admin could potentially run a scheduled task or a one-time process with highest privileges without a prompt. With Admin Protection on, even those actions would require an interactive login by the user at the time of execution, otherwise they won’t run elevated.

Using Administrator Protection with UAC simply means enabling that feature – there’s no separate UAC setting beyond turning it on. It enhances UAC such that it’s far less likely malware can bypass it. When both EPM and Administrator Protection are deployed in an organization (for different sets of users), UAC is essentially on everywhere (since it underpins both). Standard users have UAC enabled (they can’t elevate except via EPM), and admin users have this upgraded UAC which forces re-auth for each elevation. In both cases, UAC dialogs, either the EPM-managed experience or the WHfB prompt, ensure a human is in the loop for elevation.

To put it succinctly: UAC is the underlying security gatekeeper for elevation in Windows, while EPM and Administrator Protection are two solutions that decide how and when that gate opens. EPM opens the gate automatically but only for pre-vetted actions (keeping it shut for others), and Administrator Protection keeps the gate locked unless the user provides a key (credential) each time, even if they are the gate’s owner. Both make the gate harder for unwanted guests (malware) to sneak through compared to vanilla UAC: EPM because it won’t even present the gate unless criteria are met, and Admin Protection because it adds an extra lock (WHfB) and isolates what’s behind the gate into its own space.

Conclusion

Privilege management is a critical aspect of endpoint security, and Microsoft now offers robust tools to address it from multiple angles. Endpoint Privilege Management (EPM) and Windows 11’s Administrator Protection are complementary solutions that reflect a modern approach to the principle of least privilege. EPM allows organizations to stop giving users local admin rights by providing a safe, managed way for standard users to perform admin tasks. Administrator Protection, on the other hand, recognizes that some accounts must be admins and significantly reinforces those accounts’ security by eliminating persistent admin access. Both build upon and improve the longstanding UAC mechanism – EPM by making UAC’s prompts more user-friendly and policy-driven in an enterprise, and Administrator Protection by making UAC’s approvals more secure and ephemeral.

For IT professionals, the emergence of these tools means that implementing a least-privilege strategy is more achievable than ever. In an ideal enterprise setup:

• All regular end-users run as standard users (non-admin) on their PCs, with EPM enabling any necessary software installs or system changes in a controlled manner. This way, no user is running with admin rights by default, vastly reducing the risk of malware gaining high-level privileges.
• Only a small subset of accounts have administrative privileges, and for those that do (e.g., IT support technicians, developers requiring admin access, etc.), Windows 11 Administrator Protection is enabled. This ensures even those admins are protected from stealthy elevation attacks and operate with just-in-time privileges. Every admin action they take will require positive confirmation, preventing abuse of their standing access.
• UAC remains enabled on all systems as a safety net, but its behavior is tuned: standard users’ UAC is paired with EPM for smooth whitelisting of approved actions, and admin users’ UAC is hardened via Administrator Protection so that a password or biometric is always required.

This combination yields a strong security posture: malware or threat actors now have a very difficult path. Compromising a regular user gives them limited access (and EPM won’t elevate arbitrary programs), and compromising an admin user still doesn’t immediately grant admin control without additional hurdles. Meanwhile, users can do their jobs with minimal IT intervention, and IT retains oversight of what’s happening on endpoints.

Finally, it’s important to keep recommended practices in mind when deploying these technologies:

• For EPM, invest time in learning what applications and operations your users legitimately need, and build your elevation rules accordingly. Start with a pilot group and gradually expand, refining the rules as you observe the elevation reports. Make use of features like business justification and secondary authentication for higher risk actions to add accountability. Keep software up to date (both client and Intune) to benefit from the latest capabilities and patches.
• For Administrator Protection, ensure your users (admins) are enrolled in WHfB or have strong credentials set up. Communicate to them about the new prompts and why they’re beneficial, so that they don’t view it as just an annoyance but as a security improvement. Also, test essential admin workflows (like scripting, automation tasks) to see if any adjustments are needed in light of the new token model. Generally, the change is positive and doesn’t break functionalities – it just changes how one interacts with elevation.

In conclusion, Microsoft Endpoint Privilege Management and Windows 11’s Administrator Protection both significantly strengthen Windows security by addressing the issue of excessive privileges. EPM provides an enterprise-ready way to implement least privilege across the user base, and Administrator Protection offers a crucial safety net for those who do have elevated rights. Together with UAC, they form a layered defense that is far more effective than relying on user diligence alone. By leveraging these technologies, organizations can reduce their attack surface and better defend against privilege escalation attacks, all while empowering users and administrators to perform their tasks in a secure but user-friendly manner.