---
title: Understand AppLocker policy design decisions (Windows 10)
description: This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using AppLocker within a Windows operating system environment.
ms.assetid: 3475def8-949a-4b51-b480-dc88b5c1e6e6
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Understand AppLocker policy design decisions
**Applies to**
- Windows 10
This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions when you plan a deployment of application control policies by using AppLocker within a Windows operating system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices. The resulting decisions will affect your policy deployment scheme and subsequent application control policy maintenance.
You should consider using AppLocker as part of your organization's application control policies if all the following are true:
- You have deployed or plan to deploy the supported versions of Windows in your organization. For specific operating system version requirements, see [Requirements to Use AppLocker](requirements-to-use-applocker.md).
- You need improved control over the access to your organization's applications and the data your users access.
- The number of applications in your organization is known and manageable.
- You have resources to test policies against the organization's requirements.
- You have resources to involve Help Desk or to build a self-help process for end-user application access issues.
- The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.
The following questions are not in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment).
### Which apps do you need to control in your organization?
You might need to control a limited number of apps because they access sensitive data, or you might have to exclude all applications except those that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
| Possible answers | Design considerations|
| - | - |
| Control all apps | AppLocker policies control applications by creating an allowed list of applications by file type. Exceptions are also possible. AppLocker policies can only be applied to applications installed on computers running one of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
| Control specific apps | When you create AppLocker rules, a list of allowed apps are created. All apps on that list will be allowed to run (except those on the exception list). Apps that are not on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
|Control only Classic Windows applications, only Universal Windows apps, or both| AppLocker policies control apps by creating an allowed list of apps by file type. Because Universal Windows apps are categorized under the Publisher condition, Classic Windows applications and Universal Windows apps can be controlled together. AppLocker policies for Universal Windows apps can be applied only to apps that are installed on PCs that support the Windows Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.
For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#bkmk-compareclassicmetro) in this topic.|
| Control apps by business group and user | AppLocker policies can be applied through a Group Policy Object (GPO) to computer objects within an organizational unit (OU). Individual AppLocker rules can be applied to individual users or to groups of users.|
| Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure is not based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you will have to identify users, their computers, and their app access requirements.|
|Understand app usage, but there is no need to control any apps yet | AppLocker policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the AppLocker event log to create AppLocker policies.|
>**Important:** The following list contains files or types of files that cannot be managed by AppLocker:
- AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.
- You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
- AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros.
>**Important:** You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
- AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps after they are launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules.
For more info, see [Security considerations for AppLocker](security-considerations-for-applocker.md).
### Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers running Windows operating systems that support Windows Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are:
- All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
- Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps cannot change the system state because they run with limited permissions. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
- Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as through software vendors or retail distribution.
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections. You have the choice to control Universal Windows apps, Classic Windows applications, or both.
For more info, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
### How do you currently control app usage in your organization?
Most organizations have evolved app control policies and methods over time. With heightened security concerns and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate app control practices or design a comprehensive application control scheme. AppLocker includes improvements over SRP in the architecture and management of application control policies.
| Possible answers | Design considerations |
| - | - |
| Security polices (locally set or through Group Policy) | Using AppLocker requires increased effort in planning to create correct policies, but this results in a simpler distribution method.|
| Non-Microsoft app control software | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Managed usage by group or OU | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Authorization Manager or other role-based access technologies | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Other | Using AppLocker requires a complete app control policy evaluation and implementation.|
### Which Windows desktop and server operating systems are running in your organization?
If your organization supports multiple Windows operating systems, app control policy planning becomes more complex. Your initial design decisions should consider the security and management priorities of applications that are installed on each version of the operating system.
Possible answers | Design considerations |
---|---|
Your organization's computers are running a combination of the following operating systems:
|
AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
Note
If you are using the Basic User security level as assigned in SRP, those privileges are not supported on computers running that support AppLocker. AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way. |
Your organization's computers are running only the following operating systems:
|
Use AppLocker to create your application control policies. |