The implementation article told you what to decide. This is the build sheet: the pilot deployment of Endpoint Privilege Management in sequence, every setting named, every value given, and a validation path that ends with one elevation request travelling the full loop. It assumes you have read the implementation article and verified licensing, and it deliberately repeats nothing from it.
Step 1: The Pilot Group
Create the pilot’s target group before the policy, and make the targeting choice deliberately, because two defensible models exist. EPM policies can be assigned to user groups or device groups. Assigning the elevation settings policy to a device group is the cleaner default: the policy’s job is to provision an agent and set a machine-wide posture, device targeting makes the footprint deterministic – you can name exactly which machines run EPM – and shared or multi-user hardware behaves predictably because the machine, not whoever signs in, carries the configuration. This is also the model Microsoft’s own support guidance describes: activate the feature on the devices, and license the people. That licensing obligation is separate from targeting and does not go away. EPM is licensed per user – the Intune Suite, the standalone add-on, and Microsoft 365 E5 are all user subscription licenses – and every user who elevates through EPM must hold one regardless of how the policy arrived on their machine. The user-group alternative is legitimate on a strictly one-to-one estate, where it keeps the policy scope and the license scope as the same list of names; if you take that path, know that the agent still lands on whatever machines those users sign into. For the pilot: a device group holding the pilot personas’ machines – something like SEC-EPM-Pilot-Devices, assigned membership, deliberate additions rather than devices wandering in by rule – plus EPM licenses on those personas’ accounts. The end state this grows toward is worth naming now: a curated dynamic group of all eligible corporate Windows devices – eligible meaning the dynamic rule excludes what EPM cannot serve, such as Azure Virtual Desktop, 32-bit hardware, and unsupported builds – rather than the literal built-in All Devices group, which sweeps in ineligible machines and buries your per-policy report in not-applicable noise. The user-versus-device split returns with real consequence at the rules layer, where device-assigned rules define the machine baseline and user-assigned rules carry personal exceptions.
Step 2: The Elevation Settings Policy
In the admin center, the EPM node lives under Endpoint security. Create a new policy there, choosing Elevation settings policy as the profile type – not Elevation rules policy, which comes later and does nothing without this one. Name it so its scope is legible in a list, on the pattern EPM-Settings-Pilot. These are the settings and the values for the pilot posture:
| Setting | Pilot value | Why |
|---|---|---|
| Endpoint Privilege Management | Enabled | This is the switch that provisions the EPM client. Nothing exists on the device without it. Note the reverse, too: setting it to Disabled later deprovisions the components after seven days. |
| Default elevation response | Require support approval | Every file without a rule (which at pilot start is every file) becomes a request instead of a denial or a self-approval. This is the setting that makes the pilot a discovery instrument. Note that leaving this Not Configured is not neutral: the client’s built-in fallback behaves as Deny all requests. |
| Send elevation data for reporting | Yes | Without it the device reports nothing and the reports you will operate from stay empty. |
| Reporting scope | Diagnostic data and all endpoint elevations | The full scope is what captures unmanaged elevations – what people elevate outside EPM. The narrower scopes are for steady state, not discovery. |
One settings policy per persona is the standing pattern; the pilot needs exactly one. Resist configuring anything else at this stage – no rules, no reusable settings. The whole point of the pilot posture is that the environment tells you what to build next.
Step 3: Assignment
Assign the policy to the pilot group and nothing else. No exclusions are needed yet, no filters earn their complexity at this scale, and scope tags apply only if your RBAC design already uses them. The policy travels on the normal Intune sync cadence, so allow the usual interval – or nudge a test device with a manual sync – before judging anything in the next step.
Step 4: Device-Side Validation
Validation is three checks on a pilot device, in this order:
- The policy reports as succeeded for the device in the admin center. A status of not applicable is diagnostic, not noise: it is what unsupported hardware reports, and it usually means a 32-bit build or an OS below the supported floor.
- The client exists: the Microsoft EPM Agent Service is present and running, and the agent’s directory sits under Program Files as
Microsoft EPM Agent. If the policy succeeded and the agent is absent, give it time and a reboot before suspecting the network path – and then suspect the network path, because SSL inspection between the device and the EPM endpoints is the classic silent killer here. - The user experience is live: right-clicking an executable as a standard user now offers Run with elevated access. If the verb is missing, the agent is not yet enforcing, and the first two checks will tell you why.
Step 5: One Request, End to End
Do not declare the pilot open until one elevation request has travelled the entire loop deliberately, with you at both ends:
- As a standard user on a pilot device, right-click a harmless installer, choose Run with elevated access, enter a business justification, and submit. The confirmation dialog is the entire user-side experience; brief your pilot users that silence afterward is normal.
- As the approver, open the Elevation requests tab in the EPM node. The request will be there and nothing will have told you so – internalize that now, because the absence of notifications is the single most important operational fact in this entire system. Approve it, and write a real reason: it enters the audit record.
- Back on the device, run the file again with elevated access. It elevates without a new request – the approval covers that user and that file for twenty-four hours from the moment you clicked approve.
- Close the loop in reporting: the elevation appears in the Elevation report as a managed, support-approved elevation. Report data can lag the event, so treat latency as normal rather than failure.
What you have now is a functioning request pipeline and an empty rule set, which is exactly the starting state the piloting article’s discovery period wants. The next build sheet constructs the approval workflow properly – the scoped role that lets helpdesk approve requests without holding Intune-wide rights – because a queue this important should not depend on who happens to have Global Admin.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2.3] Rolling Out and Operating EPM: Rings, Removal, and the Long Game
Next: [12.2.5] Build Sheet: The Approval Workflow ›
