preloader
UNYK

Windows 11 Administrator Protection, Intune EPM, and the Legacy Apps They Still Can’t Fix

windows-11-administrator-protection-intune-epm-legacy-apps

Windows 11 Administrator Protection, Intune EPM, and the Legacy Apps They Still Can’t Fix

If you work in endpoint security or Windows management, your feed has probably been full of updates about Windows 11 Administrator Protection and Intune Endpoint Privilege Management (EPM). They’re important shifts. Administrator Protection changes how admin elevation works on Windows 11, and Intune EPM gives you a rule-based way to broker elevation instead of handing out permanent admin rights. Both move us closer to a default of standard users + controlled elevation. But they still don’t magically fix the biggest real-world blocker to least privilege in many environments: Legacy Windows applications that only behave if the user is effectively a local admin. In this post we’ll look at what these new capabilities do, what they don’t solve, and how a focused tool like Elevator fits alongside them as a “last-mile” solution for those stubborn, admin-only apps.

What Microsoft just gave you: Administrator Protection and Intune EPM

Windows 11 Administrator Protection in a sentence

Windows 11’s new Administrator Protection (rolling out with recent 25H2 updates) replaces traditional, always-present admin tokens with a System Managed Admin Account that only activates during elevation.
  • Instead of keeping an admin token “always on,” Windows spins up an isolated admin context just for the elevated action.
  • When the task completes, that privileged context goes dormant again.
  • The goal: make it much harder for attackers to steal or abuse lingering admin tokens while still letting admins do their jobs.
This is a big improvement over older UAC behavior and aligns with the idea that admin access should be temporary and explicit, not a permanent property of a user account.

Intune Endpoint Privilege Management (EPM)

Intune Endpoint Privilege Management (EPM) is Microsoft’s rule-based elevation engine for Intune-managed devices:
  • You define elevation rules (file, path, hash, publisher, arguments, etc.) for specific executables, installers, or scripts.
  • Standard users can then have those processes elevated via a virtual account or, more recently, via the Elevate as current user option when compatibility demands it.
  • You can choose automatic elevation, user-confirmed elevation (with MFA and justification), support-approved elevation, or deny rules.
  • EPM logs managed vs unmanaged elevations and surfaces them in reports and dashboards so you can see who is still running things “as admin” and where to tighten policy next.
Put simply: Intune EPM is a powerful way to remove standing local admin rights while still letting users run approved tasks with admin-level capability on managed devices.

The catch: none of this rewrites your legacy Windows apps

Administrator Protection and Intune EPM are great building blocks, but they share an important limitation: They don’t change how your applications are written. If you have legacy Windows applications that:
  • Write logs or config into C:\Program Files\… instead of user-writable paths,
  • Store settings under HKLM\Software\… instead of per-user locations,
  • Register COM components, services, or scheduled tasks at every launch,
  • Depend on MSI custom actions that assume they’re running with full system rights,
…then those assumptions still collide with a modern least-privilege model, no matter how good your elevation framework is. We unpack this in more detail in our earlier post Why Legacy Windows Apps Still Need Admin Rights (And What To Do About It), but the short version is simple: Most organizations still have a small set of “it only works as admin” apps that keep local admin alive far longer than it should be.

Where the new Microsoft features help—and where they stop

Administrator Protection: better elevation, same broken app assumptions

Administrator Protection is great at one thing: making elevation safer on endpoints that already have admin-capable accounts. It reduces the risk of stolen tokens and makes it harder for attackers to live off long-lived admin sessions. But if a user is a local admin today simply because a line-of-business app refuses to run as standard user, Administrator Protection doesn’t remove that requirement. The app still expects to touch protected parts of the file system and registry. You’ve improved the mechanics of elevation, not the underlying design of the application.

Intune EPM: powerful, but not always the right fit

Intune EPM is extremely capable—especially in large, Intune-centric estates. But there are some practical constraints:
  • Licensing and scope. EPM is an Intune add-on. If you don’t already have Intune everywhere, or you’re a smaller shop with a handful of problem apps, the cost and rollout effort may feel heavy compared to the specific problem you’re trying to solve.
  • Rule design overhead. Getting EPM right means designing and maintaining elevation rules with enough granularity (file, hash, publisher, arguments, child process behavior) to be safe. That’s absolutely worth doing for many organizations—but it’s still time and expertise.
  • Mixed environments. Many environments blend GPO, ConfigMgr, RDSH/VDI, and third-party tools. Not every endpoint that needs elevation for a legacy app is neatly Intune-managed.
Again, EPM is a strong option. But there’s still a gap for teams that just need a fast, focused way to retire local admin because of a small set of legacy apps.

Elevator as the “last-mile” fix for legacy admin-only apps

This is exactly the job we built Elevator for. Elevator allows non-admin users to run specific Windows applications with admin rights, without putting those users into the local Administrators group. You choose the applications; Elevator handles the elevation. In practice, that looks like:
  • Per-app elevation: You define a short, explicit list of executables that should be elevated automatically for standard users.
  • No new UI for users: They click the same shortcut they’ve always used; the app starts with the rights it needs.
  • Windows-focused deployment: You deploy Elevator via Intune, ConfigMgr, GPO, or your existing tooling—no new infrastructure.
  • Auditability: Elevation is a controlled, logged event instead of a permanent admin assignment.
In other words, Elevator gives you a simple way to say: “Users stay standard. Only these few legacy apps get the elevated rights they still need.” If you’re already using Intune EPM, Elevator can sit alongside it as a narrowly scoped, Windows-only helper for a subset of stubborn applications. If you’re not ready for EPM, Elevator on its own gives you a very quick way to remove local admin for many users without waiting on a larger project.

A practical 3-step plan for the next 30 days

If you want a blog-post-sized starting point, here’s a concrete 30-day play:

1. Identify the small set of apps blocking local admin removal

  • Pull a list of users who are local admins today and ask a simple question: “Which applications break if we remove admin?”
  • Cross-reference that with your ticket history and software inventory.
  • Expect a short list: often a handful of line-of-business apps, configuration tools, or installers.
For a deeper discussion of this discovery phase, see Removing Local Admin Rights Without Disrupting Business (Part 1).

2. Decide: fix, replace, or broker elevation

  • Fix: If the vendor can move writes to proper locations and stop re-registering services/COM at runtime, great—push for that.
  • Replace: Sometimes the honest answer is “we need a new app,” but that’s a longer project.
  • Broker elevation: For everything you can’t fix immediately, use a tool to elevate the app without elevating the user.
This “broker elevation around the app” path is what we covered in When Windows Updates Break UAC: Controlled Elevation vs. Local Admin and it’s where both Intune EPM and Elevator shine.

3. Pilot with a friendly group and remove local admin

  • Pick 10–20 machines where you can work closely with users.
  • Deploy Elevator and configure rules for 2–3 of your worst legacy apps.
  • Remove local admin from those users and run for a few weeks.
  • Measure: ticket volume, user satisfaction, and any unexpected elevation needs.
If the pilot shows that users are productive and tickets are manageable, you have evidence to scale up—whether that means rolling Elevator wider, adding Intune EPM rules, or both.

The bottom line

Administrator Protection and Intune EPM are genuine steps forward for least privilege on Windows. They make elevation safer, more auditable, and more aligned with modern security expectations. But they don’t rewrite the legacy Windows applications that still assume “everyone is admin.” Those apps are the reason many organizations are stuck with far more local admin than they’d like. To really turn the corner, you need both:
  • Modern platform features like Administrator Protection and Intune EPM, and
  • A focused way to handle the last-mile problem of legacy admin-only applications—exactly what Elevator is designed to do.
If you’d like to see how this looks in your own environment, you can learn more on the Elevator for Windows page or start a free trial and test controlled elevation with a few of your own legacy apps.
Share the Post:

Related Posts