Most EPM pilots are run as a test of the agent, which is a waste of a pilot, because the agent works. The pilot is a discovery phase: a few weeks in which your users’ actual elevation behavior writes the first draft of your rule set, and your job is to read it. Guess the rules up front and you will guess wrong twice – once on what people need, once on what they don’t.
Ring Zero and the Discovery Period
The pilot group should be representative rather than convenient: a slice of the personas who actually elevate things – engineering, finance with its inevitable vendor tools, whoever owns the label printers – not just IT, whose elevation behavior resembles nobody’s. Their devices – the pilot device group from the implementation build – get the elevation settings policy and nothing else. No rules. Support approved as the default response, full reporting scope. Then you wait, and the platform does the work: every elevation attempt either arrives as a request in the admin center or lands in the reporting pipeline as an unmanaged elevation. The EPM Overview dashboard summarizes the last 48 hours of that activity, including which users are still elevating entirely outside EPM, and the Elevation report by user aggregates it per person – which is precisely the view that tells you which applications need rules, including the child process rules you would never have predicted.
Triaging the Request Queue
Requests surface on the Elevation requests tab of the EPM node, and the first operational fact to internalize is that nothing tells you they are there. Intune sends no notification for pending elevation requests; the queue is checked or it is ignored, and an ignored queue is how a pilot dies, because a user who waits a day for approval stops requesting and starts working around you. Set a cadence – during the pilot, multiple checks a day – and scope who does the checking with the dedicated RBAC permission for elevation requests, which exists so that approving elevations does not require Intune-wide power. Each decision takes a reason, and the reason enters the audit record, so write them as if someone will read them later, because someone will.
Know exactly what an approval grants: that user, that file, twenty-four hours from the moment of approval. No custom window, no early revocation. That scope is tight enough that approving generously during a pilot costs little, and the pattern data is worth more than the caution. Approve the genuine one-offs and let them expire. What you are actually watching for is repetition.
Approve the exception once. The third request for the same file is not an exception, it is a rule you haven’t written yet.
Promoting Requests Into Rules
The promotion mechanism is built into the reporting: the Elevation report offers to create a rule directly from an observed elevation’s file details, into a new or existing elevation rules policy. Use it – it eliminates transcription errors on hashes – but treat every promotion as three deliberate decisions rather than a convenience click. First, the anchor. Certificate rules survive application updates and are the default choice for signed software, held as reusable settings so one certificate serves many rules; the caution is vendors who sign everything with one certificate, where a naive cert rule authorizes their entire catalog. Tighten certificate rules with the file name, and add a minimum version where it matters. File hash is exact and dies on every update – an acceptable price for a one-time installer, a maintenance treadmill for anything that updates monthly. File path rules can be defeated by dropping a hostile binary at the blessed path; treat them as a last resort.
Second, the elevation type. User confirmed is the workhorse for tools someone uses routinely and legitimately; the user still consciously elevates, but nobody waits for an admin. Automatic is reserved for the short list of vetted, tightly anchored daily-driver tools where any friction is pure cost. Support approved stays on the powerful and the dangerous – the sysadmin utilities, the things that rewrite systems – where a human in the loop is the point. And deny rules close the loop from the other side: files that must never elevate get an explicit deny, which beats any allow rule for the same file. Third, child process behavior. Windows delegates the parent’s context to children by default, so an elevated installer’s children are elevated too; that is what installers need and what admin tools should be denied. Tightening child behavior breaks some applications that expect the default, so every rule that changes it gets tested end to end before it ships.
When the Pilot Is Done
The exit signal is the request queue going quiet for the pilot population: the recurring needs have become rules, the rules are stable across an update cycle or two, and what remains in the queue is genuine one-offs. Before expanding, understand one merge behavior that will otherwise surprise you at scale – rules deploy to users or to devices, they merge on the client, and where both match the same file, the user-assigned rule wins. Structure the rule set with that in mind: device-assigned rules for what the machine’s role needs, user-assigned rules for what the person’s role adds. The rollout article takes it from here.
Building the rules this pilot produces, from the report and from scratch: [12.2.6] Build Sheet: Elevation Rules.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2.1] Implementing EPM: The Settings Policy and the Decision That Shapes Everything
Next: [12.2.3] Rolling Out and Operating EPM: Rings, Removal, and the Long Game ›
