# Understanding Application Control

Last Updated On: 27 Jul 2026  
7 minutes read

A technical look at the agent processes, scanning behavior, policy deployment mechanics, kernel-level enforcement, and conflict resolution in Application Control.

## Specifications of Agent Processes

Six background processes handle discovery, enforcement, and notification on each managed endpoint.

| Agent Process | Running Application Name | Bandwidth Consumption (Approximately) | CPU Consumption (Approximately) | Memory Consumption (Approximately) |
|---|---|---|---|---|
| Application Processing server | Verifytrustedfiles.exe | Will download the configuration in the dcconfig exe | 0.25-0.3% | 30 MB |
| Application Scanner | Dcprocmon.exe | 100-200 KB | 0.3% | 6-24 MB |
| Process Notifier | AppCtrlToast.exe | NA | 0-1% | 20 MB |
| ACP Driver Control | DriverCtrl.exe | NA | 0-0.18% | 1-2 MB |
| ACP Privileger | Privilager.exe | NA | 0-1.4% | 1-1.5 MB |
| Component Upgrade | dcconfig.exe | 3.5 MB | 0-1% | 1 MB |

## Application Discovery: Data Scanning and Collection

How the agent finds and inventories applications on each endpoint.

### One-time scan and continuous monitoring

After agent installation, a one-time scan identifies and collects verified .exe files in the Program Files and Program Files (x86) directories, as well as running processes. Scan duration depends on the number of installed applications. Results appear in the web console once collected.

Once an application control policy is deployed, running applications are continuously monitored. Newly installed applications are detected only if a policy is already in place. The central server automatically removes applications that have been inactive for **90 days**.

**Prerequisites**

Before creating an application group on **macOS**, complete the required [prerequisites](https://www.manageengine.com/desktop-management-msp/help/application-control/configure-mac-prerequisites.html).

## Policy Deployment: Agent-Server Synchronization

How policies flow from the server to each managed endpoint.

### Deployment options and refresh cycles

![Policy deployment flow diagram from server to agents](https://www.manageengine.com/products/desktop-central/help/images/ac-policy-deploy-hw.png)

Policy deployment — immediate push or scheduled refresh cycle.

When a policy is created, two deployment options are available:

- **Deploy Immediately** — pushes the policy to currently online agents. For large custom groups (over 200 machines), the policy is applied to 200 machines initially; the remainder follow in the next refresh cycle.
- **Deploy** — schedules the policy for the next 90-minute refresh cycle.

Policy modifications, deletions, group changes, and unmanaged application updates are all synchronized during refresh cycles. In environments with a Distribution Server, changes are replicated there first, then pushed to agents during the 90-minute cycle.

### Application Access Request Workflow

![Access request workflow diagram from user to administrator approval](https://www.manageengine.com/products/desktop-central/help/images/ac-access-req-hw.png)

Request access — user request flows immediately to the server for admin action.

When a user requests access to an unmanaged application, the request is sent to the server immediately for administrator approval. Once approved, the application becomes accessible to the user right away.

## Policy Enforcement in the Agent

How the kernel-level driver evaluates and enforces policies on each endpoint.

### Kernel-mode driver enforcement

![Policy enforcement flow diagram showing kernel driver filtering new processes](https://www.manageengine.com/products/desktop-central/help/images/ac-policy-enforce-hw.png)

Policy enforcement — the acp_driver kernel module filters each newly created process.

Policies received by the agent are enforced by a kernel-mode driver named **acp_driver**. The driver intercepts every newly created process and permits only those authorized by the deployed policy. Enforcement applies to .exe and .msi applications. Audited and blocked application events are reported during the 90-minute refresh cycle.

### Application Policy Conflict Precedence

When conflicting allowlist and blocklist policies apply to the same target group, **blocklisted applications always take precedence** over allowlisted ones. The full order of precedence, from highest to lowest priority:

1. **Blocklisting** using File Hash rule
2. **Allowlisting** using File Hash rule
3. **Blocklisting** using Verified EXE rule
4. **Allowlisting** using Verified EXE rule
5. **Blocklisting** using Product Name rule
6. **Allowlisting** using Product Name rule
7. **Blocklisting** using Vendor rule
8. **Allowlisting** using Vendor rule
9. **Blocklisting** using Folder Path rule
10. **Allowlisting** using Folder Path rule

**Example**

If Google Chrome is associated with both an allowlist and a blocklist on the same target group, Chrome will be blocked on those machines.

When an endpoint belongs to multiple custom groups with different policies, those policies are **merged into a single consolidated policy**. If one group deploys Audit Mode and another deploys Strict Mode, the endpoint uses **Strict Mode**.

### Just-In-Time Access Workflow

JIT policies provide time-bound access to specified applications. The **acp_driver** facilitates execution of those applications on deployed machines, and access is automatically terminated when the specified duration expires — no administrator action is required to revoke it.

## Related

- [Application Control overview](https://www.manageengine.com/desktop-management-msp/help/application-control/ac-overview.html)
- [Policy deployment modes](https://www.manageengine.com/desktop-management-msp/help/application-control/ac-policy-deployment.html#flexibility-regulator)
- [Just-In-Time Access](https://www.manageengine.com/desktop-management-msp/help/application-control/just-in-time.html)
- [Application Control FAQ](https://www.manageengine.com/desktop-management-msp/help/application-control/ac-faq.html)