Building Browser Extension Policies for Chrome, Edge, and Firefox

After discovering and reviewing browser extensions through the inventory process, administrators can create enforcement policies to control which extensions are permitted on managed endpoints. This guide walks through the complete process of creating, configuring, and verifying enforcement policies for Chrome, Edge, and Firefox.

Enforcement Modes

Every browser extension policy operates in exactly one mode. Two enforcement modes are supported:

Allow List Mode

In Allow List mode, only the extensions listed in the policy are permitted. Every other extension is removed from the browser. This is the most restrictive approach and is appropriate for high-security environments where the organization maintains a defined catalog of approved software.

  • Extensions on the list: permitted to remain installed
  • Extensions not on the list: removed by the agent
  • New extensions installed by users: removed on the next policy enforcement cycle unless they are on the list

Deny List Mode

In Deny List mode, the extensions listed in the policy are removed. Everything else is permitted. This is a targeted approach that works well when the organization wants to block specific known-bad or unauthorized extensions without restricting the broader ecosystem.

  • Extensions on the list: removed by the agent
  • Extensions not on the list: permitted to remain installed
  • New extensions installed by users: permitted unless they match an entry on the list

If your organization is unsure which mode to start with, Deny List mode is typically easier to adopt because it does not require a complete inventory of approved extensions. You can start by blocking high-risk or unauthorized extensions and move toward Allow List mode as your approved extension catalog matures.

Blocked Extensions

When Privilege Manager blocks a browser extension, the extension is uninstalled from the browser via the browser's native policy mechanism. The extension is not merely disabled; it is fully removed. The browser's built-in enterprise policy engine handles the removal, which means:

  • The extension's code and data are deleted from the browser profile.
  • The user cannot reinstall the extension while the enforcement policy is active.
  • The browser displays a notification or visual indicator that the extension was removed by enterprise policy (the exact presentation varies by browser).

Enforcement relies on browser policy support. The Privilege Manager agent writes policy entries that the browser reads on startup or at its next policy refresh interval. There may be a brief delay between policy deployment and the browser acting on the policy.

Enforcement Behavior for Chrome and Edge

Overview

When a Deny List policy is applied, the agent sets the installation_mode for each blocked extension to removed.

This instructs the browser to:

  1. Immediately uninstall the extension if it is currently installed.
  2. Prevent the user from reinstalling the extension from the browser's extension store.
  3. Display a notice that the extension has been removed by enterprise policy if the user attempts to install it.

When an Allow List policy is applied, extensions not on the list are also set to installation_mode removed, achieving the same uninstall behavior.

User-Visible Indicators

Users see the following indicators when enforcement is active:

  • The browser's extensions page (chrome://extensions or edge://extensions) displays a Managed by your organization banner at the top of the page or near managed extensions.
  • Blocked extensions that the user previously had installed disappear from the extensions page.
  • Attempting to install a blocked extension from the web store shows a message indicating that the extension is blocked by the organization's administrator.

Enforcement Behavior for Firefox

Overview

When a Deny List policy is applied, the agent writes a Firefox enterprise policy that sets the installation_mode for each blocked extension to blocked. Despite the different keyword (blocked vs. removed in Chromium), the outcome is the same:

  1. The extension is uninstalled if currently installed.
  2. The user cannot reinstall the extension.
  3. Firefox displays a notification that the extension has been blocked by the system administrator.

User-Visible Indicators

Users see the following indicators when enforcement is active:

  • The Firefox Add-ons Manager (about:addons) shows a Your browser is being managed by your organization message when enterprise policies are active.
  • Blocked extensions are removed from the Add-ons Manager.
  • Attempting to install a blocked extension displays a message that the extension has been blocked.

Sample Enforcement Policies

Privilege Manager provides pre-staged items for Windows and macOS that administrators can use as starting points for creating enforcement policies: a parameterized template that generates a new policy, and a seeded sample policy. The policies default to disabled, so it does not take effect until an administrator reviews it, customizes the extension list, and activates it.

Browser Extension Enforcement Policy Template (Windows or macOS)

A parametrized template that generates a new enforcement policy when run. Rather than being an empty policy you clone, the template prompts for inputs (such as Name and Description) and creates a fresh enforcement policy with sensible defaults: Deny List mode, disabled, targeted at Windows Computers or MacOS Computers, with weekly and agent-registration triggers. After the new policy is created, open it, switch the mode if you want Allow List behavior, add the extensions you want to deny (or allow), and activate it when ready.

Browser Extension Enforcement Policy Sample (Windows or macOS)

A working Allow List sample that ships disabled, seeded with a handful of common enterprise extensions as examples of how entries look when populated. The seeded list includes Chrome, Edge, and Firefox variants of extensions such as 1Password, Okta Browser Plugin, Microsoft 365, and uBlock Origin.

The sample is meant to be reviewed and customized before deployment, not activated as-is. Duplicate and edit it, replacing the seeded entries with the extensions your organization approves, and activate the result once the list reflects your environment.

When editing an Allow List policy in the enforcement editor, a warning is displayed: "Allow List mode will remove ALL unlisted extensions from targeted computers." Review the list carefully before activating. Any extensions your users depend on that are not on the list will be removed when the policy is enabled. Previously installed extensions are not restored when the policy is removed.

Creating a New Policy

To create an enforcement policy:

  1. Navigate to the computer group where you want to apply the policy and expand it.
  2. Click Browser Extension Policies in the left navigation for the desired computer group.
  3. Click Create Policy.
  4. Enter a Name and Description for the policy. Use a descriptive name that indicates the mode and purpose, such as "Block Unauthorized AI Extensions" or "Engineering Approved Extensions Only". Click Create.
  5. Select the Enforcement Mode: Allow List or Deny List.
  6. Click Save to create the policy.

The policy is created in an inactive state. You must add extensions and activate the policy before it takes effect.

Adding Extensions to a Policy

Once the policy is created, you need to populate it with the extensions that should be allowed or blocked (depending on the mode).

Searching by Name

  1. Open the policy and click Add Extension.
  2. In the search field, type the extension name (for example, Grammarly or uBlock Origin). The discovered extension inventory returns matching results.
  3. Select the extension you want to add. The extension's name, store ID, browser, and risk score are displayed to help you confirm the selection.
  4. Click Add to include the extension in the policy.

Only extensions that have been discovered through the inventory policy can be added to the policy. The editor does not accept raw store IDs for extensions that have never been inventoried. If you need to cover an extension that has not yet been seen on any endpoint, wait until inventory has captured it before authoring the policy entry.

Multi-Browser Considerations

Because each browser store assigns its own unique identifier to extensions, a single enforcement policy may need multiple entries for the same logical extension. For example, to enforce policy for uBlock Origin across Chrome, Edge, and Firefox browsers, the policy needs three entries, one for each browser's store ID.

Browser Extension Store ID
Chrome uBlock Origin cjpalhdlnbpafiamejdnhcphjbkeiagm
Edge uBlock Origin odfafepnkmbhccpbejgmiehpchacaeak
Firefox uBlock Origin uBlock0@raymondhill.net

The inventory lists each browser variant as a separate row. When populating a policy, add each variant as its own entry. If your organization only uses Chrome and Edge, you only need those variants.

Activating and Applying the Policy

After adding extensions to the policy:

  1. Review the extension list to confirm it is complete and correct.
  2. Toggle the policy to Active.
  3. The policy is applied to endpoints in the computer group on the next agent policy update cycle.

Each browser handles managed extensions differently.

Browser Windows mechanism MacOS mechanism
Google Chrome ExtensionSettings registry policy Managed Preferences plist
Microsoft Edge ExtensionSettings registry policy Managed Preferences plist
Mozilla Firefox Enterprise policies (JSON) Enterprise Policies plist

When the agent receives the updated policy on a Windows endpoint, it builds one managed-settings JSON payload per supported browser (Chrome, Edge, and Firefox) and writes each payload to its corresponding registry path under HKLM:\SOFTWARE\Policies:

  • Chrome: HKLM:\SOFTWARE\Policies\Google\Chrome\ExtensionSettings
  • Edge: HKLM:\SOFTWARE\Policies\Microsoft\Edge\ExtensionSettings
  • Firefox: HKLM:\SOFTWARE\Policies\Mozilla\Firefox\ExtensionSettings

On a macOS endpoint, the server delivers enforcement as a shell script that runs on the agent. The script builds one managed-settings JSON payload per supported browser and writes each payload to its corresponding managed preferences plist:

  • Chrome: /Library/Managed Preferences/com.google.Chrome.plist
  • Edge: /Library/Managed Preferences/com.microsoft.Edge.plist
  • Firefox: /Library/Managed Preferences/org.mozilla.firefox.plist

The agent does not check which browsers are installed before writing on either platform. For each browser, if the policy produces a payload the agent writes it to that browser's registry path. If the payload is empty the agent clears that browser's ExtensionSettings value instead. On a machine where one of the browsers is not installed, any written settings sit idle in the registry and take effect the first time that browser launches (including after a later install).

Verifying Enforcement

After the policy has been active for at least one agent update cycle:

  1. Navigate to the Browser Extension Inventory Report for the relevant computer group.
  2. Check whether blocked extensions still appear in the inventory.
  3. Deny List mode: Extensions on the Deny List should no longer appear in the inventory for endpoints that have received the policy. If they still appear, verify that the agent has completed a policy update cycle on those endpoints.
  4. Allow List mode: Only extensions on the Allow List should appear. Any extensions not on the list should be absent from the inventory.
  5. Drill into individual endpoint reports to confirm per-machine compliance.
  6. For newly deployed policies, allow 1–2 agent update cycles for full propagation across all endpoints.

If an extension persists in the inventory after multiple update cycles, check that the store ID in the policy matches the store ID reported in the inventory. A mismatch (for example, using the Chrome store ID for an Edge installation) will prevent enforcement.

Editing an Existing Policy

To modify a policy after creation:

  1. Open the policy from the Enforcement Policies list.
  2. Add or remove extensions as needed.
  3. Changes take effect on the next agent policy update cycle.
  4. You do not need to deactivate and reactivate the policy to apply changes.

Removing a Policy

When an enforcement policy is deactivated or deleted:

  1. The agent removes the managed browser configuration (ExtensionSettings) on the next policy update cycle.
  2. The browser reverts to an unmanaged state for extensions.
  3. The Managed by your organization indicator disappears from the browser's extension settings.
  4. Previously blocked extensions can be reinstalled by users. The browser does not automatically reinstall extensions that were removed by the policy.
  5. Previously force-allowed extensions remain installed but are no longer protected from user removal.

Removing a policy does not restore previously uninstalled extensions. Users must manually reinstall any extensions they want to use after the policy is removed. Communicate policy changes to users in advance to avoid confusion.

Best Practices

Start with a Deny List to address the highest-risk extensions first. Review the risk scoring report, identify Critical and High extensions that are not business-justified, and add them to a Deny List policy.

  • Pilot before broad deployment by applying the policy to a test computer group before rolling it out organization wide. Monitor the inventory report and gather user feedback.
  • Document approved extensions in the policy description field. Include the business justification for each allowed extension so that auditors and future administrators understand the rationale.
  • Review regularly as extensions update and new ones are installed. Schedule periodic reviews of the enforcement policy to add newly discovered extensions and remove entries for extensions that are no longer relevant.
  • Coordinate across browsers by checking the inventory report for each browser variant of an extension and adding every relevant variant to the policy as a separate entry. Each browser's extension store assigns its own store ID, so a policy entry for Chrome's uBlock Origin does not cover the Edge or Firefox builds.