How to Configure Browser Management

Overview:

Why a browser is the widest, least-controlled attack surface on an endpoint

Every managed endpoint has a browser, and every browser has an extension store sitting one click away from anyone using it. An extension is effectively third-party code granted whatever permissions it asks for and the user happens to accept, often without reading what those permissions actually mean. A single unreviewed extension with broad host permissions can read every page a user visits, including anything typed into an internal tool, a webmail client, or an admin console. Browsers are also the one application category most users expect to configure themselves, which makes ad hoc restriction unpopular and inconsistent.

Browser Management treats extensions and browser capability as a managed policy surface rather than a user preference. A policy defines whether users can install extensions at all, which specific extensions are explicitly blocked, which browser API permission categories are blocked fleet-wide regardless of which extension requests them, how native messaging (a browser extension's ability to talk to a local application) is handled, and which extensions are pinned for visibility. That policy is then deployed to endpoints the same way any other managed configuration is.

This guide walks the full workflow end to end: creating a browser policy for a specific browser type, configuring extension control and a blocked extensions list, blocking permission categories at the API level, configuring native messaging behavior, pinning approved extensions, deploying the policy to endpoints, and confirming the deployment succeeded per endpoint.

• Block by extension, not by trust alone: a specific, known-bad or unapproved extension ID can be blocked outright, regardless of what it claims to do.
• Block by permission category: an entire class of capability (Cookies, Debugger, Downloads, History, Native Messaging, and others) can be denied fleet-wide, closing the door on any extension, known or not yet discovered, that requests it.
• Control native messaging explicitly: the bridge between a browser extension and a local executable is set to Not Configured, Allowed, or Blocked, with an explicit allowed-hosts list when needed.
• Pin what's approved: known-good extensions can be pinned for visibility and consistency across the fleet.
• Deploy per browser type: Chrome and Edge policies are configured and deployed independently, matching the actual browsers in use.

Prerequisites

Confirm all four before creating a policy. A policy built for the wrong browser type, or missing a permission category someone assumed was covered, is the most common source of a browser restriction that looks complete but has a gap.

1. Administrator access: your account holds a role permitted to manage Browser Management. Read-only operators can view deployment status but cannot create policies or deployments.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device.
3. Browser type identified: know whether this policy targets Chrome, Edge, or another supported browser, since policies are authored and deployed per browser type.
4. Extension IDs and permission scope decided: know which specific extensions to block (by name and ID) and which permission categories to restrict before starting, rather than deciding ad hoc while building the policy.

Architecture: how a browser policy becomes enforced extension control

A policy defines extension-level rules (install permission, a blocked extensions list, blocked permission categories, native messaging behavior, and pinned extensions) scoped to a specific browser type. A deployment binds that policy to endpoints and installs it, with per-endpoint task tracking.

Step 1: Open Browser Management

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

Instructions

1. From the main console, go to Endpoints → Device Control.
2. Under Network and Web, select Browser Management, described as securing the browser by allowing appropriate permissions to browser extensions.
3. Note the module's two main areas: policy list and Deployments.

Path: Console / Endpoints / Device Control / Browser Management

Result: You're in the Browser Management module with visibility into any existing policies before authoring a new one.

Step 2: Create a browser policy and set its browser type

Start the policy with a name and the specific browser it targets.

Instructions

1. Go to Create Browser Policies.
2. Enter a Name for the policy, e.g. Block Extension.
3. Add an optional Description.
4. Set Browser Type to the target browser, e.g. Chrome or Edge.

Path: Console / Browser Management / Create Browser Policies

Console: policy details

Result: A named, browser-specific policy shell exists. Extension control settings are configured next.

Step 3: Configure extension control and the blocked extensions list

Decide whether users can install extensions at all, and name the specific extensions to block outright.

Instructions

1. Under Extension Control, toggle Allow Users to Install Extensions on or off depending on whether ad hoc installation should be permitted at all.
2. If extensions are allowed generally, use Blocked Extensions to explicitly deny specific ones by name and ID, e.g. ChatGPT to PDF by PDFCrowd (jlfcopnobjbkjiclieaopipchijelm), Awesome Screen Recorder & Screenshot (gpmjlinohibfgmeoaeceoajachkabijo).
3. Add each blocked extension individually, confirming both the display name and the extension ID match the intended item, since display names can be reused by unrelated extensions.

Path: Console / Browser Management / Create Browser Policies / Extension Control

Console: extension control fields

Result: Named, specific extensions are blocked regardless of the general install permission, while other, unlisted extensions remain installable if Allow Users to Install Extensions is on.

Step 4: Configure blocked permission categories

Deny entire categories of browser API capability, closing the door on any extension, known or not, that requests them.

Instructions

1. Under Blocked Permissions, review the available categories: Cookies, Debugger, Declarative Content, Declarative Net Request, Desktop Capture, Downloads, History, Identity, Management, Native Messaging, Notifications, Page Capture, Privacy, Proxy, and others.
2. Select the categories that represent unnecessary or high-risk capability for your environment, e.g. History.
3. Understand that this blocks the capability itself: no extension, present or future, can use a blocked permission category once it's denied at the policy level.

Path: Console / Browser Management / Create Browser Policies / Blocked Permissions

Console: sample permission categories

Result: A category-level restriction that applies to every extension on the endpoint, not just the ones named individually in Step 3.

Step 5: Configure native messaging

Set explicit behavior for the bridge between browser extensions and local, non-browser applications.

Instructions

1. Set Native Messaging Action to Not Configured, Allow, or Block depending on whether extensions should be permitted to communicate with local applications at all.
2. If native messaging must be permitted for specific, known-good hosts, add them under Native Messaging Allowed Hosts rather than leaving the capability open fleet-wide.

Path: Console / Browser Management / Create Browser Policies / Native Messaging Action

Console: native messaging fields

Result: Native messaging behavior is explicitly decided rather than left to whatever the browser's own default happens to be.

Step 6: Configure pinned extensions

Pin known-good, approved extensions for visibility and consistency across the fleet.

Instructions

1. Under Pinned Extensions, enter the extension IDs that should be pinned to the browser toolbar.
2. Use this for extensions the organization has explicitly approved and wants visible and consistent across every managed endpoint, not as a substitute for the Blocked Extensions or Blocked Permissions controls.
3. Save the policy once Extension Control, Blocked Permissions, Native Messaging, and Pinned Extensions are all configured.

Path: Console / Browser Management / Create Browser Policies / Pinned Extensions

Result: A complete browser policy: what's blocked by name, what's blocked by capability, how native messaging is handled, and what's pinned for visibility.

Step 7: Deploy the browser policy

Bind the policy to specific endpoints so it's actually installed and enforced.

Instructions

1. Go to Deployments → Create Browser Management Deployment.
2. Enter a Deployment Name, e.g. Allow Specific Exe.
3. Add an optional Description.
4. Set Scope Endpoints to Specific Endpoints and select the target device(s).
5. Set Select Browser Management Policy to the policy created in Steps 2 through 6, e.g. Block Extension.
6. Set Deployment Policy, e.g. OOB Instant deployment policy (type Instant).
7. Optionally set Notify to for completion alerts.
8. Select Publish.

Path: Console / Browser Management / Deployments / Create Browser Management Deployment

Console: deployment definition

Result: A task is created (e.g. ADR-072: Allow Specific Exe) with type Install, visible under the deployments list with an initial stage such as Initiated.

Step 8: Monitor the deployment

Track the deployment from initiation through completion across the deployments list.

Instructions

1. Go to Deployments to see all Browser Management deployments with their Type (Install), Stage (Initiated, Completed), Progress, and Policy.
2. Open the specific deployment task to see its per-endpoint Status and Last Updated time.
3. Watch the endpoint's status move from an initial state such as Ready to Deploy toward a final result.

Path: Console / Browser Management / Deployments

Console: task status progression

Result: A live view of the rollout, endpoint by endpoint, before treating the browser policy as fully in effect.

Step 9: Confirm task success per endpoint

Verify the policy actually installed successfully on the target endpoint.

Instructions

1. Reopen the deployment task, e.g. ADR-072: Allow Specific Exe.
2. Confirm Status has progressed to Success for every targeted endpoint, not just that the overall deployment stage shows Completed.
3. Note the updated Last Updated timestamp confirming when the successful state was reached.

Path: Console / Browser Management / Deployments / <Task>

Console: task status (final)

Result: Endpoint-level confirmation that the browser policy was actually applied, the evidence behind the deployment's overall completed stage.

Step 10: Review the policy list before scaling to more browsers or endpoints

Confirm the full set of browser policies before expanding scope, since each is tied to a specific browser type.

Instructions

1. Return to the Browser Management policy list and review each entry: Name, Browser Type, and Allow Extensions status.
2. Confirm there's a corresponding policy for every browser type actually in use across the fleet, a policy built only for Edge does nothing for Chrome endpoints.
3. Before broadening a deployment's Scope Endpoints, confirm the browser type of the newly included endpoints matches the policy being deployed.

Path: Console / Browser Management

Console: policy list (example)

Result: A clear view of policy coverage across browser types, so a gap (a browser in use with no corresponding policy) is visible before it becomes an incident.

Best practices for browser management

Troubleshooting: common issues and resolutions

Frequently asked questions