← All resources
How-to

Deploying browser security across a client fleet with Intune

Force-installing a managed browser extension is a well-trodden path in Microsoft Intune. Here is the shape of the process, and the details that catch people out.

How-to · 6 min read · By SafeToOpen · July 2026

The good news for anyone deploying browser-layer protection across a managed fleet is that you are not doing anything unusual. Force-installing browser extensions through policy is a standard, well-documented operation in Microsoft Intune, in Group Policy, and in every major RMM platform. There is no agent to package, no kernel driver, no reboot.

What follows is the general shape of the work, and the details that tend to cause friction the first time.

The three mechanisms

Microsoft Intune. For Edge and Chrome, extension deployment is handled through configuration profiles using the browser’s administrative templates — specifically the force-install list, which takes the extension ID. Once the profile is assigned to a device or user group, the extension arrives at the next policy refresh and cannot be removed by the user.

Group Policy. For clients still running traditional domain infrastructure, the same settings exist as ADMX templates. The mechanics differ; the concept is identical.

Your RMM. ConnectWise, Datto, NinjaOne, Kaseya and similar platforms can push the same registry keys or configuration profiles. For MSPs already standardised on an RMM, this is usually the path of least resistance because it fits the multi-client model you already operate.

Whichever mechanism you use, the outcome is the same: the extension is installed by policy rather than by the user, and it stays installed. This distinction matters for any client who has previously tried to roll out security tooling by asking staff to install something.

Identity and licensing

Deployment gets the software onto the device. Identity determines who each installation belongs to, which client tenant it reports into, and which policy applies.

For Microsoft environments this comes from Microsoft Entra ID, formerly Azure AD. For Google environments it comes from Google Workspace. In both cases the user signs in with credentials they already have, and the installation associates itself with the right tenant automatically. There is no separate user database to maintain and no per-user provisioning step.

For a multi-tenant provider, this is the part worth getting right early. Deploying two hundred endpoints across six clients is straightforward when each client’s identity provider is mapped to the right tenant, and tedious when it is not.

Email protection deploys differently — and more simply

A common source of hesitation is the assumption that email protection means touching mail flow. It does not, in this model. Protection that runs inside Outlook and Gmail as an add-in operates on messages the user is already reading, in the client they already use.

That means no MX record changes, no mail routing through a third party, no journaling rules and no risk of a misconfiguration silently affecting delivery. For an MSP, this removes the single most nerve-wracking element of deploying email security: the possibility of breaking a client’s mail.

Policy decisions worth making before you deploy

Three decisions are easier to make once, centrally, than to revisit per client.

Internal domain exclusions. Most clients have internal applications and intranet sites that never need analysis. Excluding them entirely reduces noise and answers the privacy question before anyone asks it.

Warn or block. Decide whether a high-risk verdict warns the user and lets them proceed, or stops them. Different clients and different user populations warrant different answers, and the decision is easier to defend when it was deliberate.

Where events go. Security events reaching an unmonitored mailbox help nobody. Route them into the queue your team actually watches, at the point of deployment rather than three months later.

What tends to go wrong

The failures we see are rarely technical. The most common is deploying to a device group when the licences are assigned by user, or the reverse — the extension installs but does not activate, and the cause is a mismatch between two assignment models rather than anything broken.

The second is skipping the pilot. A ten-user pilot inside one client, run for a week, surfaces the policy questions above while they are still cheap to answer. Rolling straight to four hundred endpoints means answering them under pressure.

Protecting a client base?

A short introduction covering multi-tenant management, deployment and how the partner model works.

Book a partner introduction →