In a large corporate environment, the end-users do not usually have the rights to install just any application they download from the internet themselves.

But how do you decide which applications are allowed to be installed and run and which aren’t? Today, I want to walk you through the application whitelisting basics, the most common ways enterprises whitelist their apps, as well as how you can increase your security by adding digital signatures to your applications as part of your automated packaging process.

Application Whitelisting as Part of your Automated Packaging Workflow

What Is Application Whitelisting?

The National Institute of Standards and Technology defines an application whitelist as

“a list of applications […] that are authorized to be present or active on a host according to a well-defined baseline.”

The definition also includes an index of approved application components, such as software libraries, plug-ins, extensions, and configuration files to increase the flexibility of your environment.

In a Windows environment, there are two methods to determine whether or not an application is a “trustworthy app” and if it should be allowed to run: blacklisting and whitelisting.

In the first method, known as blacklisting, you allow any apps to run by default except the ones you specifically do not allow. This method is often used by security technologies such as antivirus software. The problem is, you need to know the offender. Whitelisting, on the other hand, disallows all applications by default and is designed to permit only the applications you explicitly allow.

Why You Should You Whitelist Your Apps

Obviously, with new malware, ransomware, and other malicious software being developed every day, whitelisting is a much safer way! But whitelisting isn’t only about cyber security and the increasing threat of malicious apps being installed without your knowledge or consent.


When done strategically, whitelisting can help you enforce corporate standards and enable you to have a much tighter handle on your application estate management — hence avoiding, or at least minimizing, the risk of Shadow IT and application sprawl.

In other words, it works best in a centrally-managed IT environment because you need to have exact insights into which software is needed and can be allowed, but also configure your machines so that they will only allow the installation of apps that are signed.

How Does Whitelisting Work?

Whitelisting can be compared to SSL certificates on websites. By digitally signing applications with a certificate you guarantee that the publisher of this app is who they say they are. Depending on your whitelisting policies, you can further limit who the signed apps can come from. For example, you could say that only Microsoft Store apps can be installed or only apps that are signed by your organization are allowed.

Application whitelisting can be managed in many ways but the 2 most common ways are:

  1. Using the PATH from where an app is launched (e.g C:program files x(86)OpenBloomberg) and
  2. Using a digital signature from an .EXE (e.g C:program files x(86)OpenBloombergBlpmain.exe). 

unsigned.pngWhen combined with a product like Avecto Defendpoint, a group policy can maintain the whitelist of a product PATH or the digital certificate. If an application doesn’t have a digital signature on the .EXE, a signature can be created using tools like signtool.exe from Microsoft. 

Applying a whitelist using your application paths does improve your security. However, it could potentially expose hundreds of vulnerable files to malware of some kind. For that reason, many IT teams prefer whitelists at .EXE level over trusting a PATH as you can determine on a case-by-case basis which applications you deem trustworthy. That is why most vendors nowadays digitally sign the .EXE as part of their development and compile.

As a larger organization, you are developing .EXE internally which would also benefit from having a digital signature. Therefore, you would probably sign your own code or other people’s code using your own certificates. To do so, you can utilize whitelisting programs, such as open source software 7-Zip or more sophisticated technologies, such as Avecto Defendpoint and now Access Capture.

Whitelisting & Windows 10

While you could do similar things with Windows 7 and 8 with Authenticode Code Signing and other programs like it, digitally whitelisting has recently gotten much more attention with Windows 10 as Microsoft is tightening the security screws built into the operating system.


Digitally signing your applications is only one side of the coin. You also have to manage the client side of things. Microsoft has a few tools to do that, like AppLocker in Windows 7, and there are lots of different ways of configuring it. For example, it can be deployed as a group policy through SCCM, Active Directory, and now, in Windows 10, Windows Device Guard.

For example, Microsoft tested in its Windows 10 Creators Update a new option to only permit apps to install if they’re from the Windows Store. As Microsoft only allows Xapps, apps built on its application framework Universal Windows Platform, to be distributed through the Microsoft Store, this would provide developers an incentive to update their software to be compatible with UWP.


Windows Defender Application Control (Image Credit: Microsoft)

Another example is Windows Defender Device Guard, which is integrated into its Windows Defender ATP suite. One of the key features is an “application and software whitelisting technology known as configurable code integrity that, together with AppLocker, enables enterprises to strongly control what is allowed to run in their environment.”

However, to leverage these features, you need to have your applications signed in the first place. As there are thousands of applications floating around in larger enterprises, this can be incredibly difficult. This is where automating the process comes in.

Benefits Of Digitally Signing .EXE Files As Part Of Your Automated Packaging & Testing Workflow

If you decide you do not want to use the PATH but rather go for the more secure option of digitally signing your executable files, it would make the most sense to do so while packaging them as you will have to package, test and certify every single application in your estate at some point in time anyway.

Once you’ve completed this step, your apps would still have to go to another team to be digitally signed. Since you are not signing the install, but the actual executables within the package, it’s not a straightforward task. Then you would have to recompile them — adding an extra step and significant resources, time, and budget.

If you are not automating your application packaging and testing and you don’t manage your app estate very tightly, it is very unlikely that you could even whitelist every trustworthy piece of code.

However, if you already have automation in place or are planning to do so, adding another manual step with an extra tool would take away from the benefit of the packaging automation in the first place. That’s where Capture comes in.

With our sophisticated app packaging & testing solution, like Access Capture, you can not only centrally manage whitelisted and therefore pre-approved application components to make discovery process easier, but you can also lock down the security policies to only allow trustworthy apps by automatically adding digital signatures to .EXE in the packaging process! 

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment