Regulating extensions is what stops the next malicious one from ever running, and keeps shadow IT off your machines. A written policy is how you get there, but only if you can enforce it. You do not need ten pages of legalese. You need four things: an allowlist, block by default for everything else, a way for people to request what is missing, and the discipline to re-check the list. Here is how to build each.
Block by default. Allow by exception. Govern every update.
Start from one principle
Treat browser extensions as what they are: third-party software with privileged access that updates itself silently. You would not let staff install arbitrary software on a server, and an extension with access to all sites is not far off. So the default is simple. Nothing runs unless it is on the list.
1. Build your allowlist
The allowlist is the heart of the policy: the set of extensions you have decided are worth the access they hold. Build it from evidence, not habit.
Start from your inventory. You already know what is installed and how widely, so begin with what people actually use.
Run each candidate through the assessment: does its access fit its function, is the publisher credible, is the update history clean? The permission dictionary tells you what each permission grants.
Approve the ones that pass. For the rest, find a safer tool that does the same job. A short, deliberate list beats a long, inherited one.
Record each entry by extension ID, never by name, so a lookalike cannot inherit the approval. Note the approved version, who approved it, when, and why.
2. Block everything else by default
An allowlist only matters if everything off it is blocked. Enforce that centrally through the browser management you already have (Chrome Browser Cloud Management, Intune, or Google Workspace): block all extensions, then permit only the IDs on your list.
Block by default only feels heavy-handed if you spring it on people. Explain why extensions are governed like any other software, and always offer a sanctioned alternative so nobody is left stuck. The goal is control without friction, not a wall.
3. Create a workflow for new requests
People will always need tools you have not thought of. Give them a clear path to ask, or they will find a way around you. Keep it light:
A simple request (a ticket or a form) naming the extension, the business need, and where it will be used.
A quick review against the same criteria you used to build the list. Most requests are settled in minutes once you can read the permissions.
A fast, honest answer: approve and add it to the allowlist, approve a safer alternative, or decline with a reason. Speed is what keeps people using the workflow instead of sideloading around it.
Deployment from the console, not a manual install, so the approved version is the one that actually runs.
4. Review your allowlist regularly
This is the step everyone forgets, and the one that matters most. You approved a behavior, not a name forever. An extension you cleared last quarter can change owner or add permissions overnight, so the list is never finished.
Re-check allowlisted extensions on a set cadence, and immediately on any signal: a new version, a permission increase, an ownership change, or a credible public report.
Where your tooling supports it, hold new versions for a short cooldown before they reach everyone, so a hijacked update does not land on day zero.
When something fails re-review, pull it from the list, block it, and tell affected users what to use instead.
This also maps to your compliance frameworks. Governing extensions this way supports NIS2 and aligns with NIST CSF asset-management and supply-chain controls. An extension with access to authenticated sessions on regulated systems is a third party with standing access, and auditors treat it that way.
The part that does not scale by hand
Steps one to three take an afternoon. Step four is the one that defeats teams. Re-checking every allowlisted extension the moment it updates or changes owner, across every browser, forever, is a queue that never empties by hand. That is exactly where a hijacked update walks through a fleet that was, on paper, fully governed. Writing the policy is the easy half. Keeping it true in real time is the half that needs tooling.
Enforce the policy without the manual queue
Ostral enforces block by default across every browser, runs the allowlist, and does the part a policy cannot: continuous monitoring of every approved extension for updates, permission escalation, and ownership changes, with a review hold before risky updates reach your fleet.
