Removing local administrator rights is one of the most effective endpoint controls, and one of the most often abandoned because users cannot do their jobs without them. Endpoint privilege management (EPM) tools close that gap: users run as standard users and the tool elevates specific applications, installers or tasks under policy, with every elevation logged. Products differ sharply in how they elevate, what they can match on, how they handle macOS and Linux, and how much rule maintenance they demand. This vendor-neutral buyer's guide is for security, desktop engineering and IAM teams choosing an EPM product or deciding whether built-in operating system features are enough. For the control itself, see the Endpoint Privilege Management Guide.
Key takeaways
- Elevation method matters more than feature count. A tool that elevates a single process through an isolated account is very different from one that temporarily adds the user to the local Administrators group.
- Rule quality decides success. Matching on publisher certificate plus file hash or path, with argument and child process controls, is what stops an approved installer becoming a general admin shell.
- EPM and LAPS solve different problems. EPM removes standing user rights; a local administrator password solution manages the remaining built-in admin account. You usually need both.
- Audit mode is not optional. The products worth buying show you every elevation users currently perform before you remove any rights.
- Test bypasses, not demos. A proof of concept should try child process escapes, UAC bypass techniques and agent tampering, not just a successful installer elevation.
Define requirements
Start with who holds admin rights today and why. Microsoft's own Intune EPM deployment guidance follows a sequence worth copying whatever you buy: audit current elevations, group users into personas with common needs, build rules per persona from the data, monitor, then remove rights. Typical personas and what each needs:
- Information workers: occasional installers, printer and VPN drivers, a few line-of-business tools. Target: no local admin, rule-based or user-confirmed elevation.
- Developers and engineers: package managers, compilers, container tooling, network settings, frequent new binaries. Target: tighter scope, often user-confirmed elevation with justification, sometimes a separate managed workstation.
- IT support: broad admin tasks on many devices. Target: separate admin accounts, just-in-time elevation and session logging. See the JIT Access Guide.
- Servers and shared devices: service and scheduled task accounts, kiosks, lab machines. Decide whether EPM is in scope or whether server privileged access stays with PAM. See the PAM Buyer's Guide.
Record the platforms (Windows versions, macOS, Linux distributions), the management stack (Intune, Configuration Manager, Group Policy, Jamf, or other), whether devices are Entra joined, hybrid joined or AD joined, and the audit evidence you must produce. The control objectives are least privilege and logging of privileged functions: NIST SP 800-53 AC-6 with enhancements AC-6(2) non-privileged access for non-security functions, AC-6(9) log use of privileged functions and AC-6(10) prohibit non-privileged users from executing privileged functions, plus CM-11 user-installed software. In CIS Controls v8.1 the relevant areas are Control 5 (Account Management) and Control 6 (Access Control Management), notably dedicated administrator accounts and role-based access.
Built-in options set the baseline you are paying to exceed. Windows LAPS is free on supported Windows versions and rotates and backs up the local administrator password to Microsoft Entra ID or Active Directory (a hybrid device backs up to one, not both); the legacy Microsoft LAPS product is deprecated as of Windows 11 23H2. Microsoft Intune EPM is a licensed add-on covering Windows only. See the Local Administrator Password Solution (LAPS) Guide.
Capability areas
| Capability area | What good looks like | Why it matters |
|---|---|---|
| Discovery and audit | Inventory of local admin group members on every device; report of all elevations, including unmanaged "Run as administrator" use, before enforcement | Rules built from evidence, not guesses; proves rights can be removed |
| Elevation mechanism | Per-process elevation through an isolated or virtual account; user never added to local Administrators | Prevents the elevated session being reused for anything else |
| Elevation modes | Automatic, user confirmed (with reauthentication and justification), support approved, deny | Lets risk drive friction rather than one setting for everyone |
| Rule matching | Publisher certificate, file hash, path, file name, product version, command-line arguments; .exe, .msi, scripts (PowerShell), Control Panel and system settings | Loose path-only rules are trivially abused by dropping a renamed binary |
| Child process control | Block or restrict processes spawned by an elevated application | Stops an installer or tool opening an elevated command shell |
| Application control integration | Allow, block or audit execution for standard users, or clean integration with WDAC/AppLocker or an allowlisting tool | Elevation without execution control leaves malware running as the user |
| Admin account management | Removal of users from local Administrators, protection of the built-in account, integration with LAPS or own rotation | Removes standing rights rather than adding a layer on top of them |
| Cross-platform | Windows, macOS (admin group and authorisation rights), Linux (sudo policy) with feature parity stated per platform | Developer estates are rarely Windows only |
| Logging and integration | Elevation events with user, device, file hash, rule and justification exported to SIEM; ITSM integration for approvals | Evidence for AC-6(9) and input for detection |
| Agent resilience | Tamper protection, behaviour when offline or policy service unavailable, safe default for unmatched elevations | Attackers target security agents directly |
Evaluation criteria
| Criterion | Weight (suggested) | How to test |
|---|---|---|
| Elevation isolation | High | Elevate an app and check from another session whether the user's token or group membership changed |
| Rule precision | High | Create a publisher plus hash rule; try a renamed or older vulnerable version of the same binary |
| Bypass resistance | High | Attempt child process escape from an elevated installer and known UAC bypass behaviour (ATT&CK T1548.002) |
| Audit and rule building | High | Run two weeks in audit; measure how many rules the product proposes and how many are usable |
| Platform coverage | Medium to high | Run the same scenarios on each in-scope OS version, not just Windows |
| Offline and failure behaviour | Medium | Disconnect a laptop for a week; stop the policy service; confirm the default response |
| Administration effort | Medium | Count hours to maintain rules for a pilot group of 50 users over a month |
| Logging quality | Medium | Confirm SIEM receives user, device, hash, rule, justification and result for every elevation |
| User experience | Medium | Time from request to approved elevation for support approved requests |
| Vendor security | Medium | Signing of policy, protection of the management console with phishing-resistant MFA, agent update integrity |
Map what each candidate covers against the attack techniques you care about: T1078.003 Local Accounts, T1068 Exploitation for Privilege Escalation, T1003.001 LSASS Memory (which needs admin rights) and T1136.001 Local Account creation. In MITRE D3FEND terms the product mainly delivers User Account Permissions (D3-UAP) and supports Local Account Monitoring (D3-LAM); execution control is Executable Allowlisting (D3-EAL), which some products include and others leave to a separate tool. See the Application Allowlisting Guide.
Questions to ask vendors
- Exactly how is a process elevated? Is the user ever added to the local Administrators group, even temporarily, and what account does the elevated process run as?
- Which attributes can a rule match on, and can rules restrict command-line arguments and child processes? Show a rule that elevates an installer but blocks it launching cmd.exe or powershell.exe.
- What is the default response when no rule matches, and can it differ per persona?
- How do you discover existing local admin members and unmanaged elevations before enforcement?
- What is supported on macOS and Linux today, as opposed to on the roadmap? How do you handle sudo and macOS authorisation rights?
- What happens offline, during agent upgrade and if the agent is stopped? How is tampering detected and reported?
- Which elevation events reach our SIEM, in what format, and with what latency?
- How do support approved requests integrate with our ITSM tool, and can approvals be time limited?
- How do you manage or coexist with Windows LAPS for the built-in administrator account?
- How is the management console protected, and what could an attacker with console access push to every endpoint?
For a structured RFP process around these questions, see the Security Vendor Evaluation and RFP Guide.
Red flags
- "Elevation" implemented by adding the user to local Administrators for a time window.
- Rules that match on path or file name only, with no publisher or hash option.
- No control over child processes of an elevated application.
- No audit mode, or audit data that cannot be turned into rules without manual work for every entry.
- macOS or Linux "support" that is inventory only.
- Default allow behaviour when the agent cannot reach its policy service, with no way to change it.
- A management console that can push arbitrary scripts to every endpoint without approval or strong authentication; it is a remote management tool and should be secured like one. See the RMM Tool Security Guide.
Proof of concept
- Choose three personas: an information worker group, a developer group and IT support, about 20 to 50 devices each, across every OS you need.
- Set success criteria first: percentage of users removed from local Administrators, elevation requests per user per week, median support approval time, help desk tickets caused, and zero successful bypasses in the test scenarios.
- Run audit mode for two to four weeks and review the elevation report with each persona's owner.
- Build rules from the data, preferring publisher plus hash or version constraints, and enable enforcement for one ring at a time.
- Test bypasses: child process escape, a renamed binary on an approved path, a vulnerable signed driver installer, stopping the agent, and an elevation attempt while offline.
- Verify logging end to end in the SIEM and build one detection for repeated denied elevations or unmanaged elevations.
- Test rollback: confirm you can restore admin rights to a device or user quickly through the product and through break-glass (for example a LAPS-managed account) if the product fails.
Track afterwards: share of endpoints with no standing user admin rights, number of unmanaged elevations, rule count per persona, and support approved requests resolved within your target time.
How NHI Mgmt Group can help
We provide independent market analysis, RFP strategy and evaluation support for privileged access and identity programmes. Browse vendors in our NHI and AI products directory or contact us about independent evaluation support.
Related NHI Mgmt Group resources: Endpoint Privilege Management Guide · Local Administrator Password Solution (LAPS) Guide · PAM Buyer's Guide · EDR and XDR Buyer's Guide · Privileged Access Management Guide