The EPM architecture article argued that elevation should be a governed, logged, per-task decision. This companion is the build, and the build is smaller than people expect: one policy provisions everything, and one dropdown inside it defines your entire posture. The work is not in the clicking. It is in understanding what that dropdown commits you to.
Before the Policy: Licensing and Prerequisites
EPM arrives three ways: the Intune Suite, the standalone add-on, or the July 2026 Microsoft 365 packaging update that folds it into M365 E5. The trap from the Suite anchor article still applies and still catches people: the E5 that includes EPM is Microsoft 365 E5, not EM+S E5, and it is not in Business Premium at all. Check what the tenant actually holds before designing anything. On the device side, EPM is 64-bit only, including Arm64, and while Windows 10 devices can still receive policy, Windows 10 left support in October 2025 and Microsoft no longer guarantees functionality there – treat EPM as a Windows 11 control with stragglers, not the reverse. The agent also needs clean line of sight to its service endpoints without SSL inspection in the path, which is the same demand the Cloud PC path makes and the same place TLS-inspecting proxies quietly break things. Government tenants are covered through GCC High.
The Elevation Settings Policy
Everything lives under Endpoint security in the admin center, in its own Endpoint Privilege Management node, and the order of operations matters in a way the interface does not enforce: the EPM client does not exist on any device until an elevation settings policy lands on it. Intune provisions the agent – the Microsoft EPM Agent Service, living under Program Files – only when a settings policy expresses the intent to enable EPM. Build elevation rules first and you have built policy for an agent that is not there. The settings policy comes first, always, and there should be one per device persona rather than a pile of overlapping ones.
Two settings in it deserve deliberate choices. Send elevation data for reporting stays at Yes, and during implementation the reporting scope should be the full option: diagnostic data and all endpoint elevations. That scope is what captures unmanaged elevations – the things people elevate outside EPM – and it is the discovery instrument the entire pilot depends on. The narrower scopes exist for steady state and privacy postures, not for a deployment trying to learn what its users actually do. And note the exit behavior while you are here: setting the policy to Disabled deprovisions the client components after seven days, which is the clean teardown path if a pilot needs unwinding.
The default elevation response is your entire security posture expressed in one dropdown.
The Decision: Default Elevation Response
The default elevation response governs every file that has no elevation rule – which on day one is every file. Deny is the textbook answer and the practical mistake: it recreates the exact deadlock EPM exists to break, users hit a wall, the helpdesk queue refills, and the estate learns to route around the control. At the other end, defaulting unknown files to user confirmation hands the decision to the person with the least context and the most incentive to click yes. The operating model that works is support approved as the default: any elevation without a rule becomes a request, the user attaches a business justification, and the request lands in the admin center for a human decision. Every unknown becomes a signal instead of a failure, and the signals are what you will build your rule set from in the pilot article.
One property of the platform should weigh on this decision and every rule you ever write: when EPM elevates a process, that process runs with full administrative capability through a virtual account. There is no partial elevation. That is why the default response is never set to anything automatic, and why the pilot treats every promotion to a rule as a scoping decision rather than a convenience.
What Users See, and How You Validate
For the user, EPM is one new verb: right-click, Run with elevated access. Under a support-approved default, that action opens a justification dialog, confirms the request was sent, and the user waits – which is exactly why the request queue cadence in the next article is an operational commitment, not a nice-to-have. Validation on a pilot device is equally plain: the EPM agent service present and running after the settings policy applies, the policy reporting as applied in the admin center rather than not applicable (which is what unsupported OS builds report), and one deliberate elevation request submitted end to end. The settings policy is deliberately boring. The pilot is where the system starts earning its keep, and that is the next article.
The settings policy and pilot group described here, laid out as a concrete build: [12.2.4] Build Sheet: The Elevation Settings Policy and the Pilot.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2] Endpoint Privilege Management: Retiring Standing Local Admin
Next: [12.2.2] Piloting EPM: Building Rules From Requests ›
