I recently had a user request administrator credentials just to change their default PDF reader, which made me consider using application allowlisting instead. The problem is that some applications change their executable names or install into new version-specific folders after updates. That means a rule based only on the executable path or filename may need to be recreated with every release. How do you handle this in practice? Do you use publisher-based rules, scripts, software deployment tools, third-party products, or manual updates?
5 Answers
Build deployment packages that configure the application and its defaults for the user. If the PDF reader is approved, the package can install it, set it as the default through the supported operating-system mechanisms, and handle updates without exposing an administrator prompt. This is generally cleaner than trying to let users elevate individual installers.
Avoid relying only on the executable name or path. Where possible, create rules based on the publisher’s code-signing certificate or other trusted file attributes. Tools such as AppLocker can support publisher-based rules, which are usually more resilient when an application gets a new version. Also, test updates with a small user-acceptance group before deploying them broadly.
Some organizations take a denylist approach rather than trying to approve every application. That can reduce administrative overhead, but it provides less control and may be unsuitable for environments with strict compliance or software licensing requirements. Whichever model you choose, staged testing and centralized deployment are important.
If you need more detailed application control, products such as ThreatLocker can manage allowlisting based on more than just a filename. They take some effort to tune and maintain, but they can reduce the number of exceptions caused by changing paths and versioned executables.
Use a managed software catalog instead of granting users administrator access. With Configuration Manager, Intune, or a similar deployment platform, IT can publish approved applications and specific versions. Users install them from the company portal without admin rights, while IT controls updates, licensing, and which products are allowed.
A Company Portal-style catalog can provide much of the same experience. The main difference is that someone still needs to maintain the packages and update the catalog when new versions are approved.
This is especially useful for products that install each major release side by side. The paths may change, but the publisher signature can remain consistent.