How to Configure Device Access Control

Overview:

Why blocking a device type needs a policy, not a manual lockdown

A single unmanaged USB drive, an unapproved wireless adapter, or a rogue input device is enough to move data off an endpoint or introduce something unwanted onto it. Disabling ports by hand solves it on one machine and breaks legitimate work on the next, because the same policy that blocks an attacker's drive also blocks the finance team's approved encrypted USB.

Device Access Control covers that path: an Access Control Policy defines what happens for each device type, a Trusted Devices registry identifies the specific hardware that stays permitted, Temporary Access grants a time-boxed exception without editing the policy, and a Deployment pushes the policy to a chosen scope of endpoints. Defining a policy changes nothing by itself; nothing happens until it's deployed, and every deployment breaks down into a per-endpoint task with its own status and execution log.

This guide walks the full workflow end to end: opening Device Access Control, creating a policy with a device type rule, registering a trusted device, granting temporary access, publishing a deployment, and confirming from the task output that the policy actually applied.

• Four access levels per device type: each rule sets Allow, Block, Allow Trusted Devices, or No Change, so a policy can lock down one device class while leaving others untouched.
• Multiple rules in one policy: Add Rule stacks several device type rules into a single policy, rather than one policy per device class.
• Trusted devices identified by hardware IDs: a device is registered by Vendor ID, Product ID, and optionally Serial Number, so an approved drive is recognised by its hardware identity rather than its drive letter or label.
• Temporary Access is time bound by design: an exception is granted as either a fixed duration or an explicit start and end time window, and expires on its own.
• Apply and Remove deployment types: the same module both applies a policy and removes one, each tracked as its own deployment.

Prerequisites

Confirm these before deploying an access control policy. A blocked input device or an unregistered approved drive is the most common reason a rollout gets reversed within minutes.

1. Administrator access: your account holds a role permitted to manage the Device Control -> Device Access Control module.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device.
3. Hardware identifiers collected: for any device that must stay permitted, gather its Vendor ID, Product ID, and Serial Number before creating the trusted device entry.
4. Endpoint scope identified: know which specific endpoints the policy should reach before publishing the deployment.
5. Recovery path confirmed: if you plan to block input devices such as keyboards or mouses, confirm you have remote access to the endpoint that does not depend on the device class being blocked.

Architecture: how an access control policy reaches an endpoint

An Access Control Policy defines the rules. A Trusted Device entry identifies specific hardware that a rule can exempt. Temporary Access grants a time-limited exception. A Deployment binds the policy to a scope of endpoints, and the agent enforces it and reports back.

Step 1: Open Device Access Control

Get oriented before creating anything, so you know where policies, trusted devices, exceptions, and deployments each live.

Instructions

1. From the main console, go to Device Control in the left sidebar.
2. Under Access and Applications, select Device Access Control.
3. Note the sections in the left panel: Access Control Policies, Trusted Devices, Temporary Access, Policy Status, and Deployments.

Path: Console / Device Control / Device Access Control

Result: You're in the Device Access Control module with visibility into existing policies, trusted devices, and deployments before making changes.

Step 2: Create an Access Control Policy

Define what each device type is allowed to do, so the same decision can be applied consistently to any number of endpoints.

Instructions

1. Go to Access Control Policies -> Create.
2. Enter a Name describing the intent, e.g. Block Keyboard.
3. Optionally enter a Description (up to 500 characters).
4. Select Add Rule to create Device Type Rule 1.
5. Choose a Device Type, e.g. Keyboards. Available types include Printers, Bluetooth Adapters, Biometric Devices, Imaging Devices, Modems, Keyboards, Mouses, Smart Card Readers, Tape Drives, Wireless Network Adapters, Floppy Disks, Infrared Devices, and Removable Storage.
6. Set the Access Level to Allow, Block, Allow Trusted Devices, or No Change.
7. If you chose Allow Trusted Devices, select the entries to permit in the Trusted Devices field that appears.
8. Select Add Rule again to cover additional device types in the same policy.
9. Select Create.

Path: Console / Device Control / Device Access Control / Access Control Policies / Create

Console: policy definition (example)

Result: The policy appears in the Access Control Policies list with its device type and access level. Like other policy-based modules, it has no effect until targeted by a deployment.

Step 3: Register a Trusted Device

Identify the specific hardware that should stay permitted, so an Allow Trusted Devices rule can exempt it by hardware identity rather than by name.

Instructions

1. Go to Trusted Devices -> Create.
2. Enter a Name for the device, e.g. Keyboard device.
3. Choose the Device Type, e.g. Keyboards.
4. Optionally enter a Description.
5. Under Device Identifier, set Add Device By to IDs and Serial Number.
6. Enter the Vendor ID and Product ID.
7. Optionally enter the Serial Number to pin the entry to one physical device rather than every device sharing that vendor and product pair.
8. Select Create.

Path: Console / Device Control / Device Access Control / Trusted Devices / Create

Console: trusted device definition (example)

Result: The device appears in the Trusted Devices list with its device type, and becomes selectable inside any rule using the Allow Trusted Devices access level.

Step 4: Grant Temporary Access (optional)

Create a time-boxed exception for a single endpoint, without editing or redeploying the policy itself.

Instructions

1. Go to Temporary Access -> Create.
2. Enter a Name, e.g. Temp Access, and an optional Description.
3. Select the Endpoint that receives the exception.
4. Set the Duration Type:
   • Fixed Duration: enter a Duration Value and Duration Unit (for example, 2 Hours).
   • Time Window: pick a Window Start Time and Window End Time from the date and time picker.
5. Select Add Allowed Device to create Allowed Device 1.
6. Choose the Device Type and set Allowed For, e.g. All Instances.
7. Select Create, or Update when editing an existing entry.

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

Console: temporary access list

Result: The exception appears in the Temporary Access list with its window and a status of Pending, moving to Expired once the window closes. Row actions allow revoking, editing, or deleting an exception before it expires.

Step 5: Publish a Deployment to endpoints

Bind the policy to a scope of endpoints so the rules are actually enforced, rather than just defined.

Instructions

1. Go to Deployments -> Create.
2. Enter a Deployment Name, e.g. Block Keyboard, and an optional Description.
3. Set Scope to Specific Endpoints (or another available scope) and select the target Endpoints.
4. Set Deployment Type to Apply Policy (or the equivalent remove action when withdrawing a policy).
5. Under Select Device Access Control Policy, choose 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 (or Save As Draft to finish later).

Path: Console / Device Control / Device Access Control / Deployments / Create

Console: deployment definition

Result: A deployment task is created (e.g. ADR-260: Block Keyboard) with stage Initiated and progress 0/1, moving through to Completed with progress 1/1. The Deployments list shows each entry with a Type of APPLY or REMOVE alongside its stage and policy.

Step 6: Confirm the deployment with per-endpoint task status and output

Verify the policy actually applied on the endpoint, rather than assuming from the deployment stage alone.

Instructions

1. Go to Deployments to see every deployment with its Type, Stage, Progress, and Policy.
2. Select the view icon on a deployment row to open its Tasks panel, showing Endpoint, Name, Status, and Last Updated.
3. Confirm the Status moves from Ready To Deploy to Success for the target endpoint.
4. Select the task row to open its Output view and review the timestamped execution log.
5. Check Policy Status for a per-endpoint view of which policies are currently in effect.

Path: Console / Device Control / Device Access Control / Deployments / Tasks / Output

Console: task status

Result: Evidence-backed confirmation that the named policy reached the endpoint and applied, with a timestamp for each stage of the task, not just a single Success flag for the whole deployment.

Best practices for device access control

Troubleshooting: common issues and resolutions

Frequently asked questions