Frequently Asked Questions (FAQ)

Application Control secures endpoints by governing which applications can run and their permissions . It starts by discovering and categorizing all installed applications using agent-based scanning. Administrators then create allowlists or blocklists based on defined criteria like vendor or file hash, which are then deployed to specific user or device groups under either Audit or Strict Modes. The policies are enforced by a kernel mode driver that filters newly created processes, allowing only authorized applications to run and blocking others.

To implement Application Control effectively, it is recommended to create computer groups based on specific enterprise requirements and group applications by department or functionality to simplify management. Gaining granular visibility through auditing applications in Audit Mode helps in making informed decisions about access control. Once allowlists are defined, enforcing a Strict Mode zero-trust model minimizes the attack surface by only allowing pre-approved applications. Additionally, enabling users to request access to unmanaged, business-critical applications maintains productivity while upholding security.

To block an application, administrators initiate the creation of an Application Blocklist by navigating to Application Control → Application Groups and selecting Create Blocklist. Once in this module, applications are added to the blocklist by applying filters based on criteria such as vendor, product name, file hash, or folder path . Once deployed, any application on this blocklist will be restricted from executing on target machines.

The Application Control module is included in the Security Edition and can be accessed after purchasing the Security license. For the trial version of application control, kindly contact applicationcontrolplus-support@manageengine.com . It is also available in the Professional, UEM, and Enterprise editions as an add-on.

The process of creating a list of applications and allowing only those to run is called as application allowlist . Application Control enables allowlist creation on the basis of policies like vendor, product name, file hash and executables with valid digital signatures. IT admins can easily manage the lists created as applications will automatically get added to them, as and when they are discovered, if they comply with the policies set.

The process of creating a list of applications and prohibiting only those from running is called as application blocklisting . Application Control enables blocklist creation on the basis of policies like vendor, product name, file hash and executables with valid digital signatures. IT admins can easily manage the lists created as applications will automatically get added to them, as and when they are discovered, if they comply with the policies set.

All the applications that are clustered together to build either a allowlist or a blocklist, will be considered as an application group. These groups will be automatically built based on the rules you set for each of them.

In cases of less stringent application control requirements, both certified and uncertified applications from specific vendors are displayed. Admins can selectively add chosen vendors applications to the allowlist/blocklist, minimizing access issues and streamlining management. This feature enables broad parameter-based list creation, enhancing administrative control.

If you want to allowlist/blocklist only certain products from the same vendor, this type of policy can be opted for instead of the vendor rule.

Applications are made of multiple executable files, with vendors assigning a digital certificate to each executable to vouch for its authenticity. Application Control Plus displays these verified executable files to you, from which you can select the EXE files to be allowisted/blocklisted. This policy is critical when it comes to maintaining a secure network, as a file will not be allowed to execute if its digital certificate has been tampered with. Even EXEs added to applications in the form of updates will not be allowed to run if they aren't allowlisted.

This is the most secure policy, as it's based on the hash value of the executable file. All EXEs of the running processes, including those that don't have a valid digital certificate, will be displayed. You can choose all the files that you wish to allowlist/blocklist; after that, even the smallest change to the file, such as a revision of the file's version, will change its hash value, meaning the file will be removed from the list. This policy is perfect if you want to run only extremely specific executables.

In case you want to add an application which hasn't been run yet to a allowlist/blocklist, you can opt to manually add the files.

Application Control does an all-inclusive job when it comes to application allowlisting and blocklisting. Built-in with leading Endpoint Privilege Management capabilities, it ensures that it protects organizations from most application-related threats. Endpoint Central's Block Executable feature on the contrary is rudimentary and is aimed to help organizations with maintaining their levels of productivity.

Application Control instantly discovers and displays all running applications and categorizes them based on their vendor, product name, folder path and digital certificates. Applications running specific to a group of users can also be filtered and viewed. Necessary apps can simply be selected and added into allowlists/blocklists from the list displayed. The Block Executable feature has no options to filter and categorize applications, the IT administrator must manually enter the name of the application and executable that he wishes to block.

Allowlists and Blocklists can be created on both broad and granular levels by leveraging the predefined set of rules that Application Control has to provide. Rules based on Vendor, Product Name and Folder Path can be opted for when organizations are just beginning with their control process, as they are flexible with the changes that occur during patching. The Verified Executable and File Hash rule can be chosen by experienced networks that prefer complete security. The Block Executable feature, however, allows blocklisting based only on two rules, Path and Hash. With no added capabilities to manage patching changes, IT administrators will have to manually update these lists after every patching cycle.

After selecting the rule of your choice, navigate to the Filters tab on the right. You can check if the Vendors/Product/EXE is verified or not by using the Publisher Credibility filter.

Allowlisting with the Product rule will take precedence over the blocklist. Refer here for the order of application conflict precedence. In this case, the specific product will be allowlisted while the other products of the blocklisted vendor will be blocked.

Adding a single rule that is satisfied by the application is sufficient.

Yes, by allowlisting a Vendor you will allowlist all Products from them.

This rule can be used to allowlist/blocklist all files from a particular folder or folder path.

To restrict Windows components like PowerShell or Command Prompt, you can create a blocklist using either the Folder Path rule or the File Hash rule. This allows you to block execution by specifying the application's installation path or its file hash.

Note: Since Application Control does not natively recognize Windows components such as PowerShell and Command Prompt, these applications will not be visible in the console.

No, application groups created for the macOS platform are exclusively applicable to macOS endpoints. Only those application groups will be deployed in the macOS endpoints.

Applications with dynamic or frequently changing file paths cannot be reliably allowlisted using path-based rules. Instead, use the following rule types:

1. Vendor-based rules: Allowlist applications signed by a specific software vendor.
2. Product name rules: Allowlist based on the application's product name.
3. Verified executables: Allowlist using digital signature verification.

Note: Folder path rules are not effective for dynamic paths. If the application is not listed under Unmanaged Applications, manually define it using a custom rule.

Users who require similar groups of applications can be clustered together to form Custom Groups. This grouping process can be based on roles, departments or any other criteria of your preference.

The two flexibility modes available are audit mode and strict mode. It is recommended to initially deploy policies in the audit mode, where unmanaged applications will be allowed to run along with the allowlisted ones. Once the admin has a clear picture of the applications their users actually require, they can move all of them to a allowlist and shift to the strict mode. In the strict mode none of the unmanaged applications will be allowed to run.

Note: By default blocklisted applications will not run in any of the modes.

To deploy an Application Control policy, administrators first create an Allowlist or Blocklist within the Application Groups section. Then navigate to Deploy Policy , where they can associate and deploy the prepared application group to the target machines. During this process, administrators choose between Audit Mode or Strict Mode for enforcement, can enable user requests for unmanaged applications, and select to deploy immediately or schedule the deployment for a future refresh cycle.

If the same application is present in different allowlist and blocklist policies deployed to the same target group, here is the order of precedence that will be followed:

Blocklisting using Filehash Rule > Allowlisting using Filehash Rule > Blocklisting using Verified EXE Rule > Allowlisting using Verified EXE Rule > Blocklisting using Product Name Rule > Allowlisting using Product Name Rule > Blocklisting using Vendor Rule > Allowlisting using Vendor Rule > Blocklisting using Folder Path Rule > Allowlisting using Folder Path Rule.

All Windows functionality that comes in-built with the Operating System are automatically allowlisted. Application Control will be enhanced with the option to block these apps in the future.

If an endpoint belongs to multiple custom groups with different policies, those policies are merged into a single consolidated policy. In case of conflicts, blocklisted applications take precedence over allowlisted ones. The precedence order is as follows:

Blocklisting using Filehash Rule > Allowlisting using Filehash Rule > Blocklisting using Verified EXE Rule > Allowlisting using Verified EXE Rule > Blocklisting using Product Name Rule > Allowlisting using Product Name Rule > Blocklisting using Vendor Rule > Allowlisting using Vendor Rule > Blocklisting using Folder Path Rule > Allowlisting using Folder Path Rule.

In case, if one policy is deployed in Audit Mode and another in Strict Mode, the machine will be deployed in Strict Mode .

Only one custom notification is applied at a time. The notification message from the most recently deployed policy overrides the custom notifications configured in previously deployed policies, resulting in a single notification being displayed for all blocked applications.

Note: If more than one policy is deployed to a single machine, it will be merged as one.

Unmanaged applications are those that exist in a network without being a part of any of the allowlists or blocklists created. This essentially means that these applications are unmonitored, as they have no policies associated to them. They will run based on the mode of flexibility chosen, i.e they will run when in audit mode and will be prohibited in strict mode. Please note that it is ideal to minimize the number of unmanaged applications to ensure maximum security. Learn more .

While deploying a policy in strict mode, it can be configured to permit user requests by enabling the option 'Allow users to request applications which are unmanaged'.