Great solution! Anyway, some feedback from our testing:
1) If you create policies for cmd or powershell (I know, it´s not intended to do so), these command lines cannot be invoked from Windows Terminal app anymore, even when Terminal app is started unelevated.
2) If you create policies for mmc, the computer management links won´t work anymore (empty mmc dashboard), even if started unelevated.
3) With a policy for tools like Notepad++, calling these tools via file context menu is no longer possible (see comments above).
4) Windows hello just seems to be implemented inconsistently. Some of our users can only authenticate with password, others via PIN, others via biometrics. No systematic recognizable for us ...
5) With an elevated app it´s not possible to access network shares (elevation starts in separated local user context)
6) It would be great, if you could start Windows internal system functions like network adapter configuration via EPM (see comments above). The elevation of third-party tools like "simple ip config" is not really feasible for us. We also don´t want our users to have such permissions permanently eg via membership in the local network configuration operators group.
7) It would be great, if EPM could allow users to install any esp. Microsoft store apps with elevated permissions without the need to manage these apps in a software deployment solution.
😎 We also would appreciate an approval workflow for elevations like its implemented in the access packages workflows.
We are looking forward to see new EPM features in the near future!