Enabling Extension Inventory

Before you can review or enforce browser extension policies, Privilege Manager must discover what extensions are installed across your managed Windows and macOS endpoints. Privilege Manager [provides a pre-staged Browser Extension Inventory Policy for this purpose. The policy is installed disabled by default; you enable it, optionally adjust its schedule, and confirm its target computer group. Once the policy is active, the Privilege Manager agent on each endpoint scans browser extension data and reports the results to the server.

What the Agent Scans

When the Browser Extension Inventory Policy is active on a Windows or macOS endpoint, the Privilege Manager agent enumerates extensions from the following browsers:

  • Google Chrome - All user profiles on the machine

  • Microsoft Edge - All user profiles on the machine

  • Mozilla Firefox - All user profiles on the machine

For each browser, the agent iterates through every local Windows or macOS user account that has a browser profile directory on the machine. This means the inventory captures extensions installed by any user who has logged into the endpoint, not just the currently logged-in user.

The agent reads extension meta data from each browser's profile directories on disk. The browser does not need to be running at the time of the scan.

The agent collects the following information for each discovered extension:

  • Extension name (from the manifest)

  • Store ID

  • Version

  • Author

  • Description

  • Permissions (required and optional, API and host)

  • Enabled/disabled state

  • Install source (e.g., web store, side-loaded, enterprise policy)

  • Browser and browser profile

Step 1: Enable the Pre-Staged Browser Extension Inventory Policy

Privilege Manager provides separate pre-staged Browser Extension Inventory Policies for Windows and macOS endpoints. Each policy is disabled by default so that administrators can review its targeting and schedule before agents begin reporting. You do not create a new policy; you enable the one that already exists. By default, it is shipped disable so that administrators can review its targeting and schedule before agents begin reporting. You do not create a new policy; you enable the one that already exists.

  1. Navigate to Computer Groups in the left navigation panel.

  2. Select Windows Computers (the default resource target of the pre-staged policy).

  3. For Windows endpoints, expand Windows Computers, then select Scheduled Jobs. For macOS endpoints, expand MacOS Computers, then select Scheduled Jobs.

  4. Locate the policy named Browser Extension Inventory Policy in the list.

  5. Open the policy and set Enabled to On (the pre-staged state is Off).

  6. Click Save.

The pre-staged policy is marked with the NoModify, NoDelete, and NoReplication attributes, which prevent accidental deletion or structural changes. Enabling, disabling, adjusting triggers, and changing the target group are all still permitted - these are configuration changes, not structural changes to the shipped item.

Step 2: Adjust the Scan Schedule (Optional)

Out of the box, the Browser Extension Inventory Policy runs on two triggers:

  • Weekly trigger - Wednesday at 11:00 AM local endpoint time, with a random delay of up to three hours to stagger agent load. This applies one week apart.

  • On-agent-registration trigger - Runs once when an agent first registers with the server and receives the policy, so newly onboarded endpoints are inventoried without waiting for the next weekly window.

These defaults are intended to give you fleet-wide coverage once per week without all agents scanning simultaneously. For most environments, no schedule changes are needed.

If you need to change when scans run, edit the triggers on the policy using the standard scheduled-job trigger editor (the same editor used for other scheduled jobs and scheduled client commands in Privilege Manager. Typical adjustments include:

  • Changing the day of the week or start time of the weekly trigger.

  • Increasing the random delay to spread load across a larger window.

  • Adding additional triggers (for example, a daily trigger for high-turnover environments).

Tightening the schedule: For example, running the inventory daily instead of weekly, or reducing the random delay to zero increases the load the policy places on endpoints and on the server. A weekly cadence is sufficient for most environments because extension inventory changes are typically low-frequency events. Only tighten the schedule if your security posture requires faster detection of newly installed extensions.

The inventory does not have a single "interval" setting; all schedule control is through the triggers collection on the policy.

Step 3: Target the Policy to a Computer Group

The pre-staged policies target the Windows or MacOS Computers resource group by default. If that target is appropriate for your environment, no changes are needed and you can skip this step. Otherwise, adjust the targeted groups as follows:

  1. On the policy detail page, locate the Computer Groups Targeted section.

  2. Click Edit to modify the list of targeted computer groups.

  3. Select the computer groups that should receive the inventory policy.

  4. Click Save.

You can target the same policy to multiple computer groups. For example, a single policy can target both a general group and a narrower group to give uniform inventory coverage across your fleet.

Step 4: Deploy and Wait for Agents to Report

Once the policy is enabled and targeted, the Privilege Manager agent on each endpoint in the targeted computer group will receive the policy on its next policy update cycle. The agent then performs an initial scan of all browser profiles on the machine - either because the on-agent-registration trigger fires for newly onboarded endpoints, or because an existing agent picks up the policy change and queues the next run according to the weekly trigger.

The time between enabling the policy and first results appearing in reports depends on:

  • Agent update interval - How frequently agents check for new policies. This is configured in the agent configuration settings for the computer group.

  • Number of endpoints - Larger environments take longer for all agents to check in and report.

  • Number of browser profiles - Machines with many user profiles take slightly longer to scan.

In most environments, you can expect initial results to begin appearing within one to two agent update cycles after enabling the policy.

Step 5: View Inventory Results

Once agents have reported extension data, you can review the results in the extension inventory reports.

  1. Navigate to Reports in the left navigation panel.

  2. Locate the Browser Extensions report category.

  3. Select Browser Extension Inventory to view the fleet-wide summary.

The Browser Extension Inventory report shows one row per unique extension resource, identified by the composite (Source, Browser, StoreId) key, and is sorted by Risk Score in descending order by default. This gives you immediate visibility into the highest-risk extensions across your environment.

Refer to Browser Extension Inventory Reports for detailed information about each report, including column definitions, filtering options, and drill-down capabilities.

Troubleshooting

If extensions are not appearing in reports after enabling the inventory policy, verify the following:

  • The pre-staged Browser Extension Inventory Policy is Enabled (it disabled by default).

  • The policy is targeted to the computer group that contains your endpoints. By default it targets Windows Computers or MacOS Computers. Make sure your endpoints are members of that group or of whatever group you retargeted the policy to.

  • Agents in the targeted computer group have checked in recently. You can verify agent status on the individual computer resource pages.

  • Enough time has elapsed for the agent to run the policy. If you enabled the policy mid-week, existing agents will not run it until their on-registration trigger fires (at next agent registration) or the next Wednesday weekly window, whichever comes first. If you need immediate results, use the standard scheduled-job controls to run the policy on demand on a specific endpoint.