How to Deploy and Manage Device Access Control

How to Deploy and Manage Device Access Control

Overview:

Why uncontrolled peripherals are a data-loss gap, not just a hygiene one

A USB drive is the quietest way data leaves an organization. Nobody has to break in, nothing trips a firewall, and the copy takes seconds. On the other side of the same port, an unknown keyboard or other input device can be plugged in to inject keystrokes. Either way, the question an auditor asks is the same: was the port governed before the device was plugged in, and can you prove it?

The problem organizations run into is rarely a lack of policy on paper. It is enforcement: which endpoints actually block removable storage, which exceptions were granted, who approved them, whether the exception ever expired, and whether anyone can produce that record months later.

The Device Access Control module closes that gap by treating peripheral access as a managed policy. You define the rule once (device type plus access level), register the specific devices you trust, grant time-boxed exceptions when someone genuinely needs a blocked device, and push the result to endpoints through a tracked deployment.

This guide walks the full workflow end to end: an access control policy with per-device-type rules, a trusted device list, a temporary access window, a deployment that applies the policy to real endpoints, and the task output that proves it landed.

• Reduce exposure: every managed endpoint enforces a known access level per device class instead of relying on whatever the user plugs in.
• Prove compliance: policies, deployments, and task logs give you evidence on demand instead of a fire drill before an audit.
• Allow the exceptions you need: trusted devices and temporary access windows let legitimate work continue without weakening the baseline rule.
• Expire access automatically: a temporary grant ends on its own; nobody has to remember to revoke it.
• Remove manual work: one policy scales to every targeted endpoint; there is no per-machine device manager or registry change to make by hand.

Prerequisites

Confirm all five before creating a policy. A missing prerequisite usually surfaces mid-deployment, when a policy is already half applied and harder to walk back cleanly.

1. Administrator access: your account holds a role permitted to manage the Device Access Control module. Read-only operators can view policies and status but cannot create or publish them.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device. Devices not yet enrolled are invisible to any deployment.
3. Device inventory known: you know which device classes matter to you (removable storage, keyboards, printers, Bluetooth adapters, and so on) and which specific devices must stay usable.
4. Device identifiers on hand: for every trusted device, have its Vendor ID, Product ID, and Serial Number ready. Trusted devices are matched on these values.
5. Endpoint scope defined: target devices are organized so a deployment can be scoped deliberately (specific endpoints, departments, or locations) rather than applied ad hoc.

Architecture: how a policy becomes an enforced port

The rule, the exceptions, and the enforcement travel through distinct stages: a policy defines the rule, trusted devices and temporary access define who is exempt, a deployment binds the policy to specific endpoints, and the agent on the endpoint applies it and reports back.

Step 1: Open the Device Access Control module

Navigate to the module and get oriented before creating anything, so you know where policies, exceptions, deployments, and status each live.

Instructions

1. From the main console, open the Device Access Control module.
2. Note the five sections in the left sidebar: Access Control Policies, Trusted Devices, Temporary Access, Policy Status, Deployments.
3. Open Access Control Policies to see any existing policies. The list shows Name, Device Type Rules, Rules Count, and Actions (edit or delete).

Path: Console / Device Access Control

Result: You're in the Device Access Control module. Policies, exceptions, and deployments each have their own section, and nothing is enforced until a policy is deployed in Step 6.

Step 2: Create an access control policy

Define what happens to each device class in a single reusable policy.

Instructions

1. Go to Access Control Policies → Create.
2. Enter a Name that describes what the policy enforces (e.g. Block Keyboard). Add an optional Description (up to 500 characters).
3. Select Add Rule to create Device Type Rule 1.
4. Set Device Type from the dropdown (e.g. Keyboards). Available types include Removable Storage, Windows Portable Devices, CD/DVD Drives, Printers, Bluetooth Adapters, Biometric Devices, Imaging Devices, Modems, Keyboards, Mice, and Smart Card Readers.
5. Set Access Level to one of the available options: No Change, Allow Trusted Devices, or Block.
6. Select Add Rule again to add more device types to the same policy, then select Create.

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

Console: policy settings

Result: The policy appears in the Access Control Policies list with its rule count. It is not attached to any endpoint yet: that happens in Step 6.

Step 3: Register trusted devices

Build the list of specific devices that must keep working even when their device class is restricted.

Instructions

1. Go to Trusted Devices → Add Trusted Device.
2. Enter a Name (e.g. Keyboard device) and choose the Device Type (e.g. Keyboards or Removable Storage). Add an optional Description.
3. Under Device Identifier, set Add Device By to IDs and Serial Number.
4. Enter the Vendor ID, Product ID, and Serial Number of the device.
5. Select Create.

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

Console: trusted device settings

Result: The device appears in the Trusted Devices list with its Name, Device Type, Add Device By, and Device Instance Path, ready to be referenced by any policy rule set to Allow Trusted Devices.

Step 4: Grant temporary access

Give one endpoint short-lived access to a blocked device class without changing the baseline policy.

Instructions

1. Go to Temporary Access → Create.
2. Enter a Name (e.g. Temp Access) and an optional Description.
3. Select the Endpoint that needs the exception.
4. Choose a Duration Type:
   • Fixed Duration: set Duration Value and Duration Unit (e.g. 2 Hours).
   • Time Window: set Window Start Time and Window End Time from the date and time picker.
5. Select Add Allowed Device, choose the Device Type (e.g. Keyboards), and set Allowed For to All Instances.
6. Select Create. To change it later, open the entry with the edit icon and select Update.

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

Console: temporary access settings

Result: The entry appears in the Temporary Access list with its Endpoint, Duration Type, Duration, Devices count, and Status. A future window shows Pending; once the window closes the status changes to Expired.

Step 5: Review existing deployments

Understand how the module tracks enforcement before you publish anything new.

Instructions

1. Go to Deployments.
2. Read the list columns: Deployment (ID and name), Type (Apply or Remove), Stage (e.g. Initiated, Completed), Progress (e.g. 1/1 endpoints), and Policy (e.g. OOB Instant deployment policy).
3. Use the eye icon on a row to open its task details.

Path: Console / Device Access Control / Deployments

Result: You can see the history of every policy applied or removed, including any deployment whose progress bar shows a failure.

Step 6: Deploy the policy to endpoints

Bind the policy to actual devices with a deployment of type Apply Policy.

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 All Endpoints, Specific Departments, Specific Locations, or Windows for broader rollout) and select the target device(s) under Endpoints.
4. Set Deployment Type to Apply Policy.
5. Under Select Device Access Control Policy, choose the policy created in Step 2.
6. Set Deployment Policy to OOB Instant deployment policy.
7. Optionally set Notify to so an admin or team is alerted.
8. Select Publish, or Save As Draft to finish later.

Path: Console / Device Access Control / Deployments / Create

Console: deployment definition

Result: A new deployment (e.g. <TASK-ID> – Block Keyboard) appears at the top of the Deployments list with type Apply and stage Initiated, moving to Completed once the endpoint reports back.

Step 7: Verify the deployment and read the task output

Confirm the policy actually landed on the endpoint using the task view and log rather than the stage label alone.

Instructions

1. In Deployments, select the eye icon on the deployment you just published.
2. In the Tasks dialog, find the target endpoint's row and read its Status (for example Ready to Deploy, then success) and Last Updated time.
3. Open the task output to read the agent log. A healthy run shows the agent starting the access control policy task, applying the named policy, and reporting that the policy was applied successfully.
4. Return to the Deployments list and confirm the stage reads Completed with progress 1/1.

Path: Console / Device Access Control / Deployments / Tasks

Result: You have per-endpoint evidence that the policy was applied, with a timestamped log entry.

Step 8: Check policy status

Use the Policy Status section for an ongoing view of what is applied where, once deployments have completed.

Instructions

1. Go to Policy Status.
2. Review the per-endpoint entries for the policy you deployed.
3. Investigate any endpoint that does not show the policy as applied after its deployment reports Completed.

Path: Console / Device Access Control / Policy Status

Result: A view you can reference when someone asks which endpoints currently enforce a given policy.

Step 9: Remove a policy when needed

Reverse a restriction through a tracked deployment rather than an ad hoc change on the endpoint, so the action stays auditable.

Instructions

1. Go to Deployments → Create.
2. Name it for the action (e.g. Unblock Keyboard).
3. Set Scope and Endpoints to the machines the policy should come off.
4. Set Deployment Type to the removal option and select the policy to remove.
5. Set Deployment Policy and select Publish.
6. Confirm the deployment appears in the list with type Remove and stage Completed.

Path: Console / Device Access Control / Deployments / Create

Result: The restriction is lifted through a tracked action, with the same task and log visibility as the original apply.

Best practices for Device Access Control

Troubleshooting: common issues and resolutions

Frequently asked questions