Endpoint Admin Removal Before There Is an Inventory

All three steps fail on sequencing. Blocking application control with no inventory means the allowlist is empty on day one, so legitimate software stops - that is the two-day outage repeating, but longer. Removing local admin before the CAD tool has a working elevation path breaks 60% of engineering. Applying elevation to 'any UAC prompt' is equivalent to keeping local admin and adding a layer of logging, so it delivers no risk reduction at all.

Sequenced alternative for 90 days:

1. Weeks 1-2: close agent coverage, then run agents in report-only/audit mode. Export the application inventory that builds itself. Deploy the Mac agent to a small pilot in parallel - the Mac estate needs separate policy work and should not gate the Windows timeline.
2. Weeks 2-4: build policy sets by department, not one global set. Create a narrowly scoped elevation rule for the CAD tool and pilot it with one engineering group of 100-200 users. Publish the service desk workflow for elevation requests.
3. Weeks 4-6: review audit data, drive unmatched executions down, then enable application control in block mode group by group, starting with low-risk populations. Keep Windows coverage at 100% before any blocking.
4. Weeks 6-10: remove local admin from pilot groups once elevation works, expanding on evidence that requests are being served.
5. Preserve a break-glass local admin credential rotated and vaulted, with its use alerted.

The principle: measure first, block second, remove privilege last. Each stage produces evidence that makes the next stage safe, which is exactly what the CISO needs to show progress without a second outage.

For the CAD tool, the control is least-privilege elevation, not application control. The tool needs to write to Program Files and HKLM, which requires admin rights, but only for that executable. So build an elevation policy scoped to the executable with publisher and path as the primary criteria, adding a hash only if the binary is unsigned or the publisher is untrustworthy. Prefer publisher plus path over hash alone because hash rules break on every patch and generate a wave of service desk tickets - the exact failure mode you are trying to avoid. Critically, do not let child processes inherit elevation: if the elevated CAD application can spawn a script and the script inherits admin, the whole control is decorative. Also ensure the elevation is per-execution and not persistent.

For the updater case, the risk is source and provenance, not the user's privilege level. Create a rule that blocks execution of binaries from user-writable download and temp locations unless they are signed by a trusted publisher and meet a version or reputation condition, and add a rule that blocks script interpreters and Office applications spawning from those same locations. That addresses the March incident directly: a signed-but-outdated updater running from a downloads folder.

Finally, define the exception path. Engineering will find applications nobody documented. The exception must expire automatically, be approved by a named owner, and appear on a weekly report - an exception with no expiry becomes permanent local admin by another name.

Activity metrics such as 'policies created' are easy to produce and prove nothing. The CISO needs coverage, exposure, and control-effectiveness measures.

Coverage and exposure:

• Agent coverage by platform: 78% to 100% Windows; Macs at zero, so report Mac as an open risk with a dated plan rather than omitting it.
• Percentage of users with standing local admin, baseline versus current, with the target stated explicitly (for example under 5%). This is the direct measure of the March incident's precondition.
• Number of unexpired exceptions and their age, broken out by department. A rising exception count invalidates the admin-removal number.

Control effectiveness:

• Elevation events per user per week, and the top elevated applications - this shows whether elevation is being used narrowly or has replaced standing admin.
• Blocked executions by rule and by application, with the top blockers reviewed: high block counts on legitimate software mean the allowlist is wrong, not that the control is working.
• Blocked events matching ransomware-relevant patterns (unsigned binaries from downloads or temp, script interpreters spawned by Office).
• Application control coverage: percentage of executions matched by policy, as a leading indicator of blocking-readiness.

Operational impact, because this is the political risk:

• Software-install tickets per month against the 700 baseline.
• Mean time to resolve an elevation request.
• Number of incidents attributable to a policy-induced outage.

Present exposure first, effectiveness second, operational impact third. That ordering makes the 90-day story about reduced blast radius, not about how many policies were written.