EPM elevation settings policy seems to be overriding elevation rule policy

Question

Hi,

I hope somebody has a solution to this or at least a tip: we are testing EPM in our environment and one of the elevation settings policies is require support approval. This is supposed to enforce request on all applications where no elevation rule exists (according to the documentation). We created couple of elevation rules for couple of apps - require business justification and Windows authentication, this is applied to the same user as the settings policy. Child processes in the rule have been set allow all child processes to run elevated.

Based on the information provided by Microsoft, the rule should take precedent over the settings policy. Yet, when we try to run the apps with elevation, the require support approval is still enforced. It's been hours since the rule was applied.

Have I missed anything or is there a documentation somewhere that says, 'the stricter policy always wins'?

Answer 1

Hi, you’re still seeing “Require support approval” because the elevation rule isn’t matching the file, so the device falls back to the default policy. Specifically, the certificate condition in your rule is failing — likely because the cert isn’t the actual leaf signing cert of the EXE, or the chain can’t be validated (missing intermediates, expired cert, revocation failure). You confirmed this by seeing the rule work once the cert was removed. To fix it, re-capture the correct publisher certificate from a known-good EXE (via EPM reports or PowerShell), add it to a reusable settings group, and sync the policy. Event Viewer (IDs 110 = match, 112 = fallback) can confirm if the fix worked. Remember, EPM doesn’t do “most restrictive wins”: rules always take precedence over settings. Once the rule matches, “Require support approval” won’t appear anymore.