How to Manage Browser Extensions on macOS Without MDM

Managing browser extensions on macOS presents a unique challenge for IT teams. Unlike Windows, where Group Policy provides a familiar management framework, macOS uses a different mechanism called managed preferences. And like Windows, the native tools only go so far before leaving meaningful gaps.

This guide covers how browser extension management works on macOS across Chrome, Edge, Firefox, Brave, and Safari, where the native approach falls short, and what full coverage looks like.

How macOS Browser Extension Management Works

macOS uses managed preference plists stored in the macOS managed preferences directory to deliver browser policy. Each browser reads from its own plist file, identified by its bundle ID. This works similarly to Mobile Device Management profiles, but can be applied directly without a full MDM deployment.

Managing Safari Browser Extensions on macOS

Safari extensions are distributed through the App Store and installed as app extensions rather than standalone files. This means the management model is fundamentally different from Chrome or Firefox. To restrict Safari extensions on managed Macs, organizations typically use one of three approaches: blocking the App Store entirely, using an MDM to allowlist specific app extensions, or using a com.apple.appstore.plist managed preference to restrict what can be installed.

None of these give you the same granular per-extension ID control that Chrome or Firefox policy provides. Safari extension management on macOS is, in practice, coarser and harder to audit than other browsers.

Managing Chrome, Edge, and Brave Extensions on macOS Without MDM

For organizations that do not have Jamf, Mosyle, or another MDM in place, browser extension policy can still be enforced on macOS by writing managed preference plists directly to the system. Each Chromium-based browser reads from its own plist file, and both allowlist and blocklist configurations are supported.

The same policy mechanism applies across Chrome, Edge, and Brave, though each browser reads from a separate file. After changes are written, macOS needs to be prompted to reload its preference cache before the policy takes effect in the browser. Firefox on macOS uses a separate enterprise policy format rather than the standard plist approach.

Where Native macOS Extension Management Falls Short

No inventory. Writing plists tells browsers what to allow or block, but gives IT no visibility into what is actually installed across the fleet. You can set policy without ever knowing what you are governing.

Policy drift. Plists written manually on individual machines can fall out of sync. A device that was re-imaged, upgraded, or had its preferences directory cleared may lose its extension policy without any alert.

Unmanaged browsers and profiles. A managed Chrome installation and a personal Chrome profile on the same Mac are separate preference domains. Policy written for the managed instance does not apply to the personal profile. Firefox installed outside your management scope has no restrictions at all.

No risk scoring. Native plist-based management has no concept of extension risk. You block what you know about, but you have no mechanism for identifying which extensions across your fleet are actually high risk based on their permissions or threat intelligence.

Managing Browser Extensions on macOS With Extensight

Extensight addresses all of these gaps with a lightweight macOS agent that runs as a LaunchDaemon, inventories every extension across all installed browsers and profiles, and manages the plist files automatically to enforce your policy. No MDM required, no manual plist management, and no gap for personal profiles or unmanaged browsers.