EPM deployed but local admin retained is an elaborate way of keeping the problem. The rollout has two halves that must move together: expanding the rings, and actually removing standing administrator rights as each ring proves out. Skip the second half and you have bought a Suite license to decorate the thing you were supposed to eliminate.
Expanding the Rings
Each new ring inherits the pilot’s rule set and repeats the pilot’s shape in miniature: support approved stays the default, the request queue runs hot for a week or two as the new population’s tools surface, and the recurring requests get promoted into rules exactly as before. Watch request volume as your scaling signal – it tells you whether the approval capacity you staffed matches the population you just added, and whether the ring you planned next is bigger than the queue can absorb. Ring order follows tolerance and risk the way it does everywhere else in this series: enthusiasts and IT-adjacent teams first, the general population in slabs, executives and their special snowflake software late, with their rules already discovered by proxy.
The second half of each ring is the one that gets skipped: as EPM proves out for a population, that population’s standing local admin rights come off. Remove users from the local Administrators group through your account protection policy, keep the break-glass local admin governed by LAPS as covered in the Windows security phase, and let EPM be the only elevation path a standard user has. This is the goal line. Everything else in these three articles is machinery for reaching it without breaking people.
The elevation report going quiet is not success. Standing admin rights going away is success.
The Operating Cadence
In steady state, EPM runs on two habits. The first is the request queue as a standing task – still no notifications, so it belongs in a shift routine, not in goodwill. Approval latency is the metric that decides whether users keep trusting the mechanism; a queue answered in minutes builds the habit of asking, a queue answered in days teaches people to find another way. The second habit is the reports as the operating surface. The elevation report and its by-application, by-publisher, and by-user views tell you what is elevating and under what authority; the by-user view remains the early-warning system for a person whose elevation pattern has changed shape. Rule hygiene rides the same cadence: one-time installer rules get retired after the install, automatic rules get re-justified on a schedule rather than accumulating, certificate rules get deduplicated through reusable settings, and the hundred-rule ceiling per policy pushes you toward per-persona rule policies before sprawl makes the decision for you.
The Failure Modes
Four patterns kill EPM deployments, and none of them is technical. Rule sprawl is the first: every request promoted, every rule automatic, until the estate has quietly reinvented standing admin with extra steps – the discipline is that automatic stays rare and every promotion is a scoping decision, because an EPM-elevated process holds full administrative capability, not a discount version. Approval latency is the second, covered above; staff it or lose it. The third is the unsigned line-of-business app, which can’t take a certificate rule and turns every update into a hash-rule chore; the durable fix is getting the internal tooling signed, and the honest interim is a hash rule with an owner whose job includes updating it. The fourth is the network: the agent’s endpoints do not tolerate SSL inspection, and an EPM that worked in the pilot then failed in the branch office usually means the branch proxy is reading traffic it shouldn’t.
The architecture article argued that elevation should be a governed exception. These three builds are what governed means in practice: a default that turns unknowns into requests, a pilot that turns requests into rules, and an operation that keeps the exception from quietly becoming the norm again. The dropdown was never the hard part. The discipline is.
Standing up the approval workflow this operation runs on, from the scoped role to the cadence: [12.2.5] Build Sheet: The Approval Workflow.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2.2] Piloting EPM: Building Rules From Requests
Next: [12.2.4] Build Sheet: The Elevation Settings Policy and the Pilot ›
