How to Configure Application Control

How to Configure Application Control

Overview:

Why blocking by name is not the same as blocking by risk

Application allowlisting and blocklisting sounds simple until someone on the finance team needs Chrome for exactly one vendor portal that doesn't work in the approved browser, and the ticket lands on your desk an hour before their meeting. A blanket block solves the security problem and creates an operational one, and most teams end up either leaving the block in place and absorbing the friction, or quietly disabling it and losing the control entirely.

Application Control treats this as two related but separate problems: block an executable by name across the endpoints it shouldn't run on, and grant a scoped, time-limited exception when a legitimate need shows up, without touching the underlying policy. The block stays enforced everywhere else, and the exception expires on its own instead of becoming a standing hole someone forgets to close.

This guide walks the full workflow end to end: creating an application block policy by executable name, deploying it to specific endpoints, granting temporary access through a fixed duration or a scheduled time window, monitoring both the block deployment and the temporary access as they run, and removing a policy cleanly when it's no longer needed.

• Block by executable, not by guesswork: policies target the actual binary name, so enforcement doesn't depend on where the file was installed.
• Grant exceptions without disabling the policy: temporary access opens a scoped window for one endpoint and one application, and closes itself automatically.
• Choose fixed duration or a scheduled window: a support-ticket-driven exception and a planned maintenance window are different shapes of request, and both are supported directly.
• See policy status per endpoint: Active/Inactive status and last-updated time are visible per asset, not just at the policy level.
• Remove cleanly: a Remove-type deployment reverses a block the same way an Apply-type deployment applied it, tracked the same way.

Prerequisites

Confirm all four before creating a block policy. Blocking an executable without first confirming its exact binary name is the most common cause of a policy that silently does nothing.

1. Administrator access: your account holds a role permitted to manage the Application Control module. Read-only operators can view policy status but cannot create policies, deployments, or temporary access grants.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device.
3. Exact executable name confirmed: application binary names are case-sensitive and must match exactly (e.g. notepad.exe, chrome.exe). Confirm the real binary name on a representative endpoint before authoring the policy.
4. Endpoint scope identified: know which specific endpoints, or which broader scope, this block should apply to before creating the deployment. A block created but never deployed to a scope has no effect.

Architecture: how a block reaches an endpoint, and how an exception overrides it

A policy defines what to block. A deployment applies that policy to specific endpoints. Temporary access sits alongside the policy, not inside it, granting a scoped and time-bound exception without editing or removing the underlying block.

Step 1: Open Application Control

Get oriented before creating anything, so you know where policies, deployments, and temporary access each live.

Instructions

1. From the main console, go to Endpoints → Application Control.
2. Note the sections in the left sidebar: Policy (block policies), Deployments, and Temporary Access.

Path: Console / Endpoints / Application Control

Result: You're in the Application Control module with visibility into existing policies before authoring a new one.

Step 2: Create an application block policy

Define the block: a name for the policy and the exact executable it targets.

Instructions

1. Go to Policy → Create Application Control Policy.
2. Enter an Application Name describing the policy's intent, e.g. Block Notepad.
3. Add an optional Description.
4. Enter the Executable Name exactly as it appears on disk, e.g. notepad.exe. This field is case-sensitive.
5. Save the policy.

Path: Console / Application Control / Policy / Create Application Control Policy

Console: policy definition

Result: A policy exists that defines what to block. It has no targets yet, that's set in the deployment step.

Step 3: Deploy the block policy to endpoints

Bind the policy to specific endpoints with a deployment of type Apply Policy.

Instructions

1. Go to Deployments → Create Application Control Policy Deployment.
2. Enter a Deployment Name describing the rollout, e.g. Block Chrome.
3. Set Scope Endpoints to Specific Endpoints (or a broader scope) and select the target device(s).
4. Set Deployment Type to Apply Policy.
5. Set Select Application Control Policy to the policy created in Step 2.
6. Set Deployment Policy (e.g. OOB Instant deployment policy, type Instant).
7. Optionally set Notify to for completion alerts.
8. Select Publish and confirm.

Path: Console / Application Control / Deployments / Create Application Control Policy Deployment

Console: deployment definition

Result: A task is created (e.g. ADR-061: Block Chrome) with status In Progress, visible under the task list with the target endpoint and timestamp.

Step 4: Monitor the block deployment

Track the deployment from initiation through completion, then confirm the policy is actually enforced.

Instructions

1. Go to Deployments to see all deployments with their Type (Apply, Remove), Stage (Initiated, Completed), Progress, and Policy.
2. Open the specific deployment task to see its per-endpoint Status and Last Updated time.
3. Once the deployment stage shows Completed, check Policy Status to confirm the policy is now Active on the target endpoint(s).

Path: Console / Application Control / Deployments

Console: policy status

Result: Confirmation that the block is not just deployed but actually enforced, with a per-endpoint audit trail.

Step 5: Grant temporary access with a fixed duration

Open a scoped exception for a specific endpoint and application when someone has a legitimate, time-bound need.

Instructions

1. Go to Temporary Access → Create Temporary Access.
2. Enter a Name describing the exception, e.g. Temporary Notepad Access.
3. Add an optional Description.
4. Select the target Endpoint.
5. Set Duration Type to Fixed Duration.
6. Set Duration Value and Duration Unit, e.g. 2 and Hours.
7. Under Application, enter the Executable Name the exception applies to, e.g. notepad.exe.
8. Save.

Path: Console / Application Control / Temporary Access / Create Temporary Access

Console: fixed-duration access

Result: The named endpoint can run the specified executable for the fixed duration, after which the underlying block resumes automatically.

Step 6: Grant temporary access for a scheduled time window

Use a defined start and end time instead of a rolling duration, for a planned maintenance window or a known meeting time.

Instructions

1. Go to Temporary Access → Create Temporary Access.
2. Enter a Name, e.g. Temporary access for chrome.
3. Select the target Endpoint.
4. Set Duration Type to Time Window.
5. Set Window Start Time and Window End Time using the date/time picker.
6. Under Application, enter the Executable Name, e.g. chrome.exe.
7. Save.

Path: Console / Application Control / Temporary Access / Create Temporary Access

Console: time-window access

Result: The application is only permitted on that endpoint within the exact window specified, outside of which the block applies as normal.

Step 7: Monitor temporary access status

Confirm a grant is active, and know when it expires, without waiting for someone to report a problem.

Instructions

1. Go to Temporary Access to see all grants with Endpoint Name, Access/Duration Type, Duration, Executable, and Status.
2. Read the Status column: an active grant shows as in effect; an elapsed one shows as Expired.
3. Use this view before granting a new exception to confirm an old one isn't still active and overlapping unnecessarily.

Path: Console / Application Control / Temporary Access

Console: temporary access list

Result: A clear record of every exception granted, active or expired, without needing to cross-reference tickets to know what's currently open.

Step 8: Remove a block policy

Reverse a block cleanly through a Remove-type deployment rather than deleting the policy outright.

Instructions

1. Go to Deployments → Create Application Control Policy Deployment.
2. Enter a Deployment Name for the removal, e.g. Unblock Notepad.
3. Set Scope Endpoints to the same or a different target set.
4. Set Deployment Type to Remove.
5. Set Select Application Control Policy to the policy being removed.
6. Select Publish.

Path: Console / Application Control / Deployments / Create Application Control Policy Deployment

Result: A Remove-type task runs and, once Completed, the policy's status for that endpoint moves to Inactive in Policy Status.

Step 9: Confirm the removal took effect

Verify the policy is genuinely inactive rather than only assuming the Remove deployment succeeded.

Instructions

1. Return to Deployments and confirm the Remove-type deployment's Stage shows Completed.
2. Check Policy Status for the affected endpoint and confirm the policy now shows Inactive.
3. If the application was blocked via a Time Window or Fixed Duration temporary access exception rather than a full policy removal, confirm instead via Temporary Access that the relevant grant is active or has expired as expected.

Path: Console / Application Control / Deployments and Console / Application Control / Policy Status

Result: Confirmed, evidence-backed removal rather than an assumption based on the deployment task alone.

Step 10: Review policy status across the fleet

Get a single view of every application control policy's current enforcement state before calling a rollout complete.

Instructions

1. Go to Policy Status (or the equivalent asset-level view).
2. Review every row: Asset Name, Applied Policy, Status (Active/Inactive), and Updated Time.
3. Cross-check this list against the deployments you expect to be in effect. An endpoint missing from this list, or showing an unexpected status, is worth investigating before you consider the rollout done.

Path: Console / Application Control / Policy Status

Result: A fleet-wide, per-endpoint confirmation of which application control policies are actually enforced right now, the evidence behind your block policy's real coverage.

Best practices for application control

Troubleshooting: common issues and resolutions

Frequently asked questions