Rules are the product the pilot exists to produce, and there are exactly two ways to build one: promote it from an observed elevation in the report, or construct it from scratch off evidence you gathered yourself. This build sheet covers both, the three decisions every rule forces, and the policy structure that keeps a growing rule set from becoming the sprawl the operating article warned about.
Path 1: Promote From the Report
The Elevation report is the fast path. Open the elevation you flagged during queue triage, and the report offers to create a rule from that file’s details – into a new elevation rules policy or an existing one, with the elevation type and child process behavior chosen as part of the flow. Prefer this path whenever the file has already elevated somewhere, for one unglamorous reason: it carries the file attributes across without a human retyping a SHA256 hash, and a mistyped hash fails silently as a rule that simply never matches. Send the rule into the persona-scoped policy it belongs to rather than accepting a fresh policy per rule; policy structure is Step 4 and it matters more than it looks.
Path 2: Build From Scratch
For a file that has not yet elevated – the new vendor tool you know is coming – gather the evidence yourself on a machine that has the file. Microsoft ships a purpose-built option: the EpmTools PowerShell module’s Get-FileAttributes cmdlet retrieves the file attributes and extracts the publisher and CA certificates in one pass. The generic cmdlets do the same job anywhere without installing a module:
# The hash anchor
Get-FileHash .\VendorTool.exe -Algorithm SHA256
# The certificate anchor
$sig = Get-AuthenticodeSignature .\VendorTool.exe
$sig.SignerCertificate | Export-Certificate -FilePath .\VendorPublisher.cerThe exported certificate goes into EPM’s reusable settings, where the admin center reads the file and populates the certificate value itself; from then on, one uploaded certificate serves every rule that anchors on that publisher, and updating the certificate in the reusable group once updates every rule that references it. The hash goes directly into a rule when a hash is genuinely the right anchor, which is less often than it feels. Rules can also carry a file argument allowlist – elevation proceeds with no arguments or only the listed ones, and is blocked if anything else appears on the command line. Arguments are case sensitive, and they are visible configuration, so never put a secret in one. If Get-AuthenticodeSignature comes back empty, you have learned something more important than any rule: the file is unsigned, and the durable fix is getting it signed, not building a hash treadmill around it.
Step 3: The Three Decisions Every Rule Forces
| Decision | Options | Guidance |
|---|---|---|
| Anchor | Certificate, file hash, file path, file version metadata | Certificate plus file name is the default for signed software – it survives updates and stays specific. Add a minimum version where downgrade matters. Hash is exact and dies on every update: right for a one-time installer, a treadmill for anything patched monthly. Path is spoofable by anything that can write to the blessed location; last resort only. Beware vendors who sign their whole catalog with one certificate – a bare cert rule authorizes all of it. |
| Elevation type | Automatic, User confirmed, Support approved, Elevate as current user | User confirmed is the workhorse: a deliberate act, no waiting, and the rule can demand extra validation – a Windows authentication prompt, a business justification, or both. Automatic is the short vetted list where friction is pure cost – and it is the type that rebuilds standing admin if it spreads, so it stays rare. Support approved remains on the powerful and the dangerous, keeping a human in the loop. Elevate as current user is the special case: it runs the process under the signed-in user’s own account rather than the isolated virtual account, which is exactly what apps that need profile paths or environment variables require and a downgrade in isolation for everything else – reserve it for apps that genuinely break without the profile. Remember what every type produces: full administrative capability for the elevated process. |
| Child process behavior | Require rule to elevate (default), Allow child processes to run elevated, or Deny all | The default, require rule to elevate, makes every child process satisfy its own rule before it elevates and honors deny rules along the way, so it is the safe posture and the one to leave in place unless you have a specific reason not to. Allow child processes to run elevated is the opposite: every child of the elevated parent runs elevated and rule evaluation is skipped entirely, deny rules included, which is what a self-updating installer that spawns its own elevated steps genuinely needs and exactly what a command shell or script engine must never be given. Deny all blocks every child from elevating at all. Loosening this setting is the quiet way one rule reopens the door you closed, so change it deliberately and test end to end before it ships. |
Worked Examples
The routine vendor tool a department runs weekly: certificate anchor tightened with the file name, user confirmed, and because its updater legitimately spawns child processes that have to elevate with it, child behavior set to allow child processes to run elevated, a loosening you grant deliberately and only to software you trust. The powerful admin utility – the disk tool, the sysinternals class of thing: certificate plus file name again, but support approved, and child behavior left at the restrictive default so anything it spawns must satisfy its own rule, because a tool like that launching an elevated shell is precisely the scenario that default exists to contain. The script engine itself – elevated PowerShell for the IT persona is the canonical case: user-assigned to the IT group so the right follows the person, but support approved and child processes held to their own rules, never user confirmed, because an elevated shell can launch anything and user-scoping alone does not make a dangerous binary safe. The one-time installer for a project: hash anchor, user confirmed, and a calendar entry to retire the rule after the deployment window, because a dead hash rule is clutter that reads like coverage. And the file that must never elevate: an explicit deny rule, which outranks any allow rule for the same file, ignores child process options entirely, and surfaces its denials in the elevation report where they belong.
One addition worth knowing is that the rules model no longer stops at files. Endpoint Privilege Management now supports system-level network configuration as a rules-based policy, which lets a standard user change an IP address, gateway, or DNS entry without local admin and without a support call. It is the same principle applied to a built-in system task rather than a binary: authorize the specific action, not the person, and leave the standing right removed.
Step 4: Policy Structure and Assignment
Rules live in elevation rules policies, each holding up to one hundred rules, and the ceiling is a feature: it forces the per-persona structure before sprawl chooses it for you. Name them for their audience – EPM-Rules-Engineering, EPM-Rules-Finance – and split the baseline from the exceptions: device-assigned policies for what a machine’s role needs regardless of who signs in, user-assigned policies for what a person’s role adds wherever they sit. When both kinds match the same file, the user-assigned rule wins; that precedence is why the split works, and why a user-scoped exception can ride on top of a device baseline without editing it. Every rule in every policy exists because a request or a report entry justified it – which is the whole system, end to end: the settings policy made unknowns into requests, the approval workflow made requests into decisions, and this build sheet makes decisions into policy. What remains is the operating discipline, and that article already exists.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2.5] Build Sheet: The Approval Workflow
Next: [12.3] Microsoft Cloud PKI: A Managed Certificate Authority for Your Endpoints ›
