EPM Audit Mode Reveals 12,000 Elevation Events
A manufacturer has 3,500 Windows 10/11 endpoints and 800 macOS devices. Users have historically been local administrators. After a ransomware incident, the company deploys Endpoint Privilege Manager in audit-only mode for 30 days. Telemetry shows 12,000 elevation events. Of those, 8,400 come from three line-of-business applications: an ERP client, a CAD updater, and a label-printer driver. Another 2,100 come from users launching cmd.exe or PowerShell as administrator. The remaining 1,500 come from 40 IT technicians installing and updating software. The helpdesk has 40 staff, no dedicated endpoint security team, and a 60-day deadline to remove local admin. The business units say any blockage of the ERP client or the label printer will stop shipping. The CAD updater changes its executable weekly, and the vendor will not provide a stable certificate.
1. How would you prioritize the first EPM policies, and why is a blanket block on all elevation a poor first move?
Read the worked answer
A blanket block is a poor first move because it converts 12,000 observed events into an unknown number of production incidents, and the helpdesk has no capacity to absorb them. The first policies should target the highest-volume, most stable, and least risky behaviors.
Start with the three line-of-business applications. The ERP client and label-printer driver are stable enough to allow by publisher or file hash, which removes most of the noise without user friction. For the CAD updater, use a publisher rule if any signed component exists, or a parent-process and command-line rule, and test it in audit mode before enforcement. Then address cmd.exe and PowerShell: allow elevation only for the IT technician group, with justification and session recording, and block or request-approval for ordinary users. Finally, use application control to allow known good software and block known ransomware behaviors.
The sequencing is deliberate: stabilize business-critical apps, reduce the riskiest interactive elevation, then tighten. The goal is not zero elevation events; it is zero unmanaged elevation for users who do not need it.
2. The CAD updater changes its executable weekly and the vendor will not provide a stable certificate. What policy design would you use, and what risk remains?
Read the worked answer
Do not use a path-only rule such as allowing everything in the vendor folder; that is trivially abused by dropping a malicious binary into the same directory. Instead, combine several attributes that are stable even when the executable changes: the parent process that launches the updater, the command line, the signer if any component is signed, and the file reputation or hash of the current version. If the updater is unsigned, use a publisher-less rule with a narrow parent-process and command-line match, and re-baseline the hash after each vendor release.
An alternative is to run the updater under a managed service account or a scheduled task with elevated rights, so the user never elevates interactively. That removes the endpoint elevation event entirely.
The residual risk is that a malicious process could mimic the parent and command line. That is why the rule should be scoped to the specific host group and monitored. If the vendor cannot provide a stable signing identity, the account should be documented as an exception with a review date, not treated as a permanent allow.
3. The 40 IT technicians need to install and update software. How should their access be handled differently from ordinary users, and how would you measure success at day 60?
Read the worked answer
Technicians need a different policy because their job is to change endpoints. Give them a role-based elevation policy tied to their admin group, require a business justification for each elevation, and record the session or capture the process tree. Where possible, use just-in-time elevation with a time limit rather than permanent local admin. Separate software installation from general administrative tools so a technician cannot use an install request to open an unrestricted shell.
Success at day 60 should be measured with a small set of indicators: percentage of endpoints with local admin removed, number of elevation requests per user per week, percentage of elevation events covered by a policy rather than a prompt, helpdesk tickets caused by EPM, and blocked or flagged ransomware behaviors. A falling ticket count with stable shipping output is a better sign than a low elevation count alone. The program should also report exceptions, because an unreviewed exception list becomes the new local admin.