Building Enforcement Policies

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.

Enforcement Modes

Every enforcement 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.

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 parameterized 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 - Windows or macOS (Sample)

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. Edit it (or clone it first if you want to preserve the original), replace the seeded entries with the extensions your organization actually approves, and activate the result once the list reflects your environment.

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

Creating a New Policy

To create an enforcement policy:

  1. Navigate to the computer group where you want to apply the policy.

  2. Expand Browser Extension Management in the left navigation.

  3. Click Enforcement Policies.

  4. Click Create Policy.

  5. 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".

  6. Select the Enforcement Mode: Allow List or Deny List.

  7. 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 appear in the discovered inventory can be added to a 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 all three supported 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 the two Chromium variants. See Extension IDs Across Browsers for background on why IDs differ between stores.

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.

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 produced a payload the agent writes it to that browser's registry path, and 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).

Each per-browser payload uses installation_mode entries to encode the policy. See Browser-Specific Behavior for the full breakdown of how each browser reads and acts on these settings, including the removed vs. blocked keyword difference between Chromium and Firefox.

Once the browser reads the managed settings, users see a Managed by your organization indicator in the browser's extensions page, confirming that enterprise management is active, and any extensions that fall outside the policy are uninstalled.

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.

    • 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.

    • Allow List mode: Only extensions on the Allow List should appear. Any extensions not on the list should be absent from the inventory.

  3. Drill into individual endpoint reports to confirm per-machine compliance.

  4. 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.