Removing Local Admin Rights: The Governance Control That Blocks Lateral Movement

Endpoint Privilege Management: Removing Local Admin Without Losing Productivity

Local administrator rights on Windows endpoints represent one of the most persistent and dangerous security risks in enterprise IT. A user with local admin can install any software, disable security tools, modify system configuration, and - critically - provide a foothold for malware to escalate privileges and move laterally across the network. Every ransomware playbook begins with privilege escalation, and local admin rights hand attackers that escalation on a silver platter.

The challenge is well understood. The solution has historically been painful: remove local admin, endure a tsunami of helpdesk tickets from users who cannot install printers, update applications, or perform legitimate tasks that require elevation. Microsoft Endpoint Privilege Management (EPM), available as part of the Intune Suite, resolves this tension by allowing granular, audited elevation without granting persistent administrator rights.

The Risk of Local Admin Rights

The data is unambiguous. Microsoft's own security research consistently shows that removing local admin rights mitigates over 90% of critical Windows vulnerabilities. When a user operates as a standard user:

• Malware that arrives via email or web browser runs with standard user permissions and cannot install persistence mechanisms, disable Defender, or access system directories
• Credential harvesting tools (Mimikatz, etc.) cannot access LSASS memory without elevation
• Configuration changes to the firewall, services, or security settings are blocked
• Software installation requires explicit authorisation, preventing shadow IT

The business pressure to grant local admin typically comes from a small number of use cases: software installation, printer driver installation, VPN client updates, and developer tooling. EPM addresses each of these without compromising the security posture.

Configuring Intune EPM

EPM is configured through Microsoft Intune admin centre > Endpoint security > Endpoint Privilege Management. The configuration involves two components: elevation settings policies and elevation rules policies.

Elevation Settings Policy:

This policy defines the default behaviour when a user encounters a UAC prompt. Navigate to Endpoint Privilege Management > Policies > Create policy > Windows 10 and later > Elevation settings:

• Default elevation response: Deny all requests. This is the baseline - no elevation without an explicit rule.
• Validation: Configure whether elevation requires business justification, IT support approval, or is automatic based on rules.
• Send elevation data to Microsoft Intune: Yes. This enables the reporting that makes EPM auditable.
• Reporting scope: All elevated and denied requests. Both are important - denied requests reveal what users need, enabling you to create targeted rules.

Elevation Rules Policy:

This is where the granular control lives. Navigate to Endpoint Privilege Management > Policies > Create policy > Windows 10 and later > Elevation rules. Each rule defines a specific application or class of applications that can be elevated, and the conditions under which elevation occurs.

Elevation Rule Types

Automatic elevation: The application runs with administrator privileges silently, without user interaction. Use this for trusted, signed applications that always require elevation - for example, your VPN client updater or a specific IT management tool.

• File name: The executable name (e.g., "AdobeAcrobatDCUpdate.exe")
• File hash: The SHA-256 hash of the specific executable version. This is the most secure option as it pins to an exact binary.
• Certificate: The code-signing certificate. This allows any version signed by the same publisher to elevate, which is more flexible but less restrictive.
• File path: The directory containing the executable. Use cautiously - if an attacker can write to that path, they can achieve elevation.

User-confirmed elevation: The user is prompted to confirm they want to elevate, and optionally provide a business justification. The application then runs with administrator privileges. This is the most common pattern for end-user applications.

• Configure the justification requirement: "Required" for applications where you want an audit trail of why elevation occurred, "Not required" for low-risk applications where you simply want the user to confirm intent.

Support-approved elevation: The user submits an elevation request, which is routed to IT support for approval. The user cannot proceed until an administrator approves the request. This is appropriate for rarely used applications or high-risk scenarios.

• The approval workflow is managed through the Intune admin centre, where support staff can review the request, see the application details, and approve or deny.

Building a Practical Rule Set

Start by deploying EPM in audit mode for 2-4 weeks. Configure the elevation settings policy with default elevation response set to "Deny all requests" but with reporting enabled. During this period, users will see UAC prompts as normal (because EPM is observing, not blocking), but every elevation will be logged.

After the audit period, navigate to Endpoint Privilege Management > Reports > Elevation report. This report shows every application that requested elevation, the user, the device, the file hash, the publisher, and the frequency. Sort by frequency to identify the most common elevation requests.

Typical rule set for a corporate environment:

| Application | Rule Type | Identification | Justification | |---|---|---|---| | Adobe Acrobat updater | Automatic | Certificate (Adobe Inc.) | Not required | | Zoom installer/updater | Automatic | Certificate (Zoom Video Communications) | Not required | | Printer driver installations | User-confirmed | File path (C:\Windows\System32\drvinst.exe) | Required | | Visual Studio (developers) | User-confirmed | Certificate (Microsoft Corporation) | Not required | | Custom LOB applications | User-confirmed | File hash (per version) | Required | | Unknown/uncategorised | Support-approved | N/A (default deny) | Required |

File Hash and Certificate Rules in Detail

File hash rules are the most secure because they identify a specific binary. If the application is updated, the hash changes and the rule no longer applies, requiring the administrator to update the rule with the new hash. This provides strong change control but requires maintenance.

To obtain the file hash, either:

• Check the EPM elevation report, which includes the SHA-256 hash of every application that requested elevation
• Run PowerShell: Get-FileHash -Path "C:\path\to\app.exe" -Algorithm SHA256

Certificate rules identify applications by their code-signing certificate. Any version of the application signed by the same certificate will match the rule. This is more maintainable (no need to update hashes per version) but less restrictive (a compromised signing certificate could be used to sign malicious code). For reputable publishers (Microsoft, Adobe, Google), certificate rules are appropriate.

Managed installer rules allow applications deployed by Intune itself to elevate automatically. If Intune deploys an application as a Win32 app, the installer is tagged as a managed installer and EPM can automatically allow elevation for the installation process. This is the cleanest pattern for IT-deployed software.

Reporting and Audit Trail

EPM generates comprehensive audit data accessible through Endpoint Privilege Management > Reports:

• Elevation report: Every elevation request, including approved, denied, and timed-out requests. Shows user, device, application, file hash, publisher, elevation type, and justification text.
• Managed applications report: Applications that have been elevated through EPM rules, with frequency data.
• Policy report: Compliance status showing which devices have received EPM policies.

For ISO 27001 evidence (A.8.2 Privileged Access Rights, A.8.5 Secure Authentication), export the elevation report monthly. This demonstrates:

• No users have standing local admin rights
• All elevation occurs through controlled, audited mechanisms
• Business justification is captured for sensitive operations
• Denied requests prove that unauthorised elevation attempts are blocked

Migration Strategy

Removing local admin rights is a change management exercise as much as a technical one. The recommended migration path:

1. Week 1-4: Deploy EPM in audit mode. Collect elevation data.
2. Week 5: Analyse elevation reports. Build the initial rule set covering the top 80% of elevation requests.
3. Week 6: Deploy rules to a pilot group (IT department first). Remove local admin rights for the pilot group.
4. Week 7-8: Refine rules based on pilot feedback. Add rules for edge cases.
5. Week 9-12: Roll out to the broader organisation in waves, removing local admin rights per wave.
6. Ongoing: Review denied elevation reports weekly. Add new rules as legitimate needs arise. Remove rules when applications are decommissioned.

The end state is an environment where no user has persistent local administrator rights, all elevation is governed by explicit rules, every elevation is logged with user attribution and justification, and the IT security team has complete visibility into privileged operations across the estate.