Skip to content

Browser Security Policy

⚠ Note: SenseOn detects and responds to malicious and suspicious activity. It is not a browser content filter, and it does not enforce browser policy for you. If you are retiring a third-party endpoint suite alongside a SenseOn deployment, the browser security controls that suite provided can be moved onto native browser policy. This guide shows how to harden Microsoft Edge and Google Chrome with Microsoft Intune, Active Directory Group Policy, or Microsoft Configuration Manager.

This guide applies to Windows 10 22H2 and Windows 11. Product versions, policy names and admin centre navigation change over time, so verify against the linked source before relying on any specific setting.

For the host firewall half of a third-party suite replacement (Microsoft Defender Firewall, rule baselines, exception handling), see Firewall Configuration. That guide also holds the fuller control-plane comparison and the shared rollout ring model, which apply to browser policy too.

Browser policy is only a partial replacement for browser content filtering. It covers the security half well and the productivity half poorly. What browser policy will not do for you sets out where the gap is and what fills it.

How browser policy is delivered

Each setting below is available through more than one channel. Use whichever matches your management plane:

  • Microsoft Intune through the settings catalogue (Edge) or imported ADMX (Chrome).
  • Active Directory Group Policy through the Edge and Chrome ADMX templates in the Central Store.
  • Microsoft Configuration Manager (SCCM) through registry-value Configuration Items. See Deploying browser policy with Configuration Manager.

Do not set the same policy from two channels at once. As with the firewall, split ownership is the most common cause of a policy that will not apply. See Do not manage the same setting from both.

Separating security filtering from productivity filtering

These are two different problems that get conflated because one product used to do both. Splitting them makes it easier to choose the right control.

Use case What it means Right control
Security filtering Blocking known malicious, phishing and malware distribution sites, and dangerous downloads. Native browser protection (SmartScreen in Edge, Safe Browsing in Chrome) plus policy hardening, deployed by Intune or GPO. Fully covered by this section.
Targeted blocking Blocking or allowing specific named sites, for example a handful of known bad domains or an approved AI tool list. URL block and allow lists in browser policy. Covered here, with a 1,000 entry practical ceiling per list.
Productivity filtering Blocking whole categories such as gambling, adult content or social media. Not a browser policy function at any workable scale. Needs DNS layer filtering or a web proxy or secure web gateway. See What browser policy will not do for you.

Microsoft Edge via Intune

Edge policies are natively available in the Intune settings catalogue, so no template import is needed.

Devices > Configuration > Create > New Policy > Windows 10 and later > Settings catalog > Add settings > category Microsoft Edge

Policy Recommended Effect
SmartScreenEnabled Enabled Turns on Microsoft Defender SmartScreen. On by default, but setting it explicitly removes the user's ability to disable it.
SmartScreenPuaEnabled Enabled Blocks potentially unwanted applications: adware, bundleware, coin miners, low reputation apps. Off by default, so this is a real gain.
PreventSmartScreenPromptOverride Enabled Users cannot click through a SmartScreen site warning.
PreventSmartScreenPromptOverrideForFiles Enabled Users cannot complete a download SmartScreen has flagged.
TyposquattingCheckerEnabled Enabled Warns on lookalike domains. On by default with user override, so set it to enforce.
DownloadRestrictions 4 Block malicious downloads flagged by the reputation service, without blocking dangerous file types wholesale. Values 1 and 2 are stricter and produce a materially higher rate of false positives.
EnhanceSecurityMode 1 (Balanced) Hardware enforced stack protection and JIT hardening for less visited sites. Balanced is the usable default. Strict causes compatibility issues.
URLBlocklist / URLAllowlist As required Targeted site blocking. Up to 1,000 entries per list. Syntax in URL allow and block list syntax.
ExtensionInstallBlocklist * Blocks all extensions except those in the allow list. See Extension control.
InPrivateModeAvailability Consider 1 Disables InPrivate. The Forced option (2) is not supported on Windows or macOS, only on mobile.

⚠ Deprecated profile type: The older Templates > Administrative Templates profile type for Windows is deprecated and read-only from the Intune December 2412 release. Existing profiles continue to work, but all new browser configuration must be built in the settings catalogue or through imported ADMX.

Managing Edge updates. Edge update behaviour is a separate policy family stored under HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate, not under the browser's own key. The per channel value names are GUID based, for example the Stable channel is Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}. Set it to 1 to always allow updates, which is the recommended value for a security baseline. Other values are 0 disabled, 2 manual only and 3 automatic silent only.

Microsoft Edge via Group Policy

  1. Download the policy templates from the Microsoft Edge for Business enterprise site (https://aka.ms/EdgeEnterprise) and extract MicrosoftEdgePolicyTemplates.
  2. Copy msedge.admx (and msedgeupdate.admx if you are managing updates) to the Central Store at %systemroot%\sysvol\domain\policies\PolicyDefinitions, and the matching .adml files to the language subfolder, normally en-GB or en-US.

  3. The settings then appear at the paths below.

  4. Computer Configuration > Policies > Administrative Templates > Microsoft Edge

  5. Computer Configuration > Policies > Administrative Templates > Microsoft Edge - Default Settings (recommended settings that users can override)
  6. Computer Configuration > Policies > Administrative Templates > Microsoft Edge Update > Applications

Use the Microsoft Edge node for anything that must be enforced and the Default Settings node only where you want to set a starting value the user may change.

Google Chrome via Intune

Chrome is less straightforward than Edge because Google does not ship a native Intune integration. Three routes exist and all three are currently supported.

Route How When to use it
Settings catalogue A subset of Chrome settings is built into Intune, under Administrative Templates\Google\Google Chrome and its subfolders. First choice. Check here before doing anything else. Google notes the built-in set is basic, so you may still need one of the routes below.
Import ADMX Devices > Configuration > Import ADMX tab > Import. Gives full policy coverage. When a setting you need is missing from the settings catalogue. Still labelled public preview.
Custom OMA-URI ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/<PolicyName> with an XML formatted value. One-off settings, or scripted deployment. Requires the Chrome ADMX to be ingested first, otherwise the namespace does not resolve.

Importing the Chrome ADMX correctly. Order matters. Importing chrome.admx first fails with ADMX file referenced not found NamespaceMissing:Google.Policies. Please upload it first. Import in this order, waiting for each to show status Available before starting the next:

  1. google.admx with google.adml
  2. GoogleUpdate.admx with GoogleUpdate.adml
  3. chrome.admx with chrome.adml

The files are in the Chrome policy templates bundle under windows\admx with language subfolders. Documented limits on the import feature: a maximum of 20 ADMX files, each 1 MB or smaller, one ADML per ADMX, and only en-us ADML files are supported. The combo box setting type is not supported and fails to import. Do not import the built-in Windows ADMX files from C:\Windows\PolicyDefinitions. Once imported, the resulting profile type is Imported Administrative templates (Preview).

Recommended Chrome settings.

Policy Recommended Effect
SafeBrowsingProtectionLevel 1 or 2 0 off, 1 standard, 2 enhanced. Setting it by policy stops users turning it off. Enhanced sends more data to Google, so check your data position first.
SafeBrowsingProxiedRealTimeChecksAllowed Leave default (true) Allows standard protection to do real time lookups through a privacy proxy. Disabling it materially weakens standard protection.
DownloadRestrictions 4 Block malicious downloads flagged by Safe Browsing. Google marks this as the recommended value. Values 1 and 2 are for organisations with a high tolerance for false positives.
URLBlocklist / URLAllowlist As required Up to 1,000 URLs per list.
ExtensionInstallBlocklist * With ExtensionInstallAllowlist for approved extension IDs.
PasswordManagerEnabled Per policy Disable only if an enterprise password manager is deployed. Existing saved passwords remain usable when disabled.
IncognitoModeAvailability Consider 1 0 enabled, 1 disabled, 2 forced. IncognitoModeUrlAllowlist takes precedence if set.
BrowserSignin 1 0 disabled, 1 enabled, 2 forced. Forcing sign-in also disables Guest mode by default.
EnterpriseRealTimeUrlCheckMode Only with Chrome Enterprise connectors configured 1 enables real time main frame URL checking against your enterprise configuration. Requires additional connector setup and changes where URL data is sent.

⚠ Do not use ExtensionManifestV2Availability: This policy was removed in Chrome 139. Chrome 138 was the last version that honoured it. Any guide or baseline still recommending it is out of date, and setting it now has no effect.

Google Chrome via Group Policy

  1. Download the policy templates bundle. The stable templates are published by Chromium, and the same files ship in the Chrome Enterprise browser bundle from https://chromeenterprise.google/browser/download.
  2. Copy google.admx, GoogleUpdate.admx and chrome.admx to the Central Store, plus the matching .adml files to the language folder.
  3. Settings appear at the path below.

Computer Configuration > Policies > Administrative Templates > Google > Google Chrome

Chrome reads policy from HKLM\SOFTWARE\Policies\Google\Chrome. List policies are stored as a subkey named after the policy, containing values named 1, 2, 3 and so on, numbered from one rather than zero. This matters when you are scripting a deployment or verifying by registry rather than through chrome://policy.

URL allow and block list syntax

Edge and Chrome share the Chromium URL filter format. The grammar is:

[scheme://][.]host[:port][/path][@query]

Only host is mandatory. Key behaviours:

  • example.com matches example.com, www.example.com and sub.www.example.com.
  • A leading dot disables subdomain matching. .www.example.com matches only that exact host.
  • * as the host is the catch-all. The standard deny-by-default pattern is * in the block list and the permitted hosts in the allow list.
  • Wildcards cannot be appended to the end of a URL, so https://example.com/* is invalid. Use https://example.com instead.
  • Where a block list and an allow list entry are equally specific, the allow list wins. Otherwise the most specific match wins, evaluated as longest host, then scheme and port, then longest path.
  • Scheme and host are case insensitive. Path and query are case sensitive.

Caveats to be aware of:

  • The block list does not stop dynamically loaded JavaScript content or URL rewriting through the History API, so it is not a content filter.
  • Microsoft notes that Edge's URLBlocklist does not behave as expected with file://* wildcards.
  • From Chrome 147, wildcard patterns no longer implicitly cover internal chrome:// URLs. Blocking internal browser pages is discouraged in both browsers in favour of the targeted policies designed for the purpose.
  • Both lists are capped at 1,000 entries. Entries beyond that are ignored, silently in the Edge case. This is the hard practical ceiling that rules browser policy out as a category filter.

Extension control

The pattern is identical in both browsers and is the highest-value browser control after the built-in reputation services.

  1. Set ExtensionInstallBlocklist to a single entry of *. Every extension is now blocked, including anything already installed, which is disabled rather than removed.
  2. Add approved 32-character extension IDs to ExtensionInstallAllowlist. Users can install these and nothing else.
  3. Use ExtensionInstallForcelist for anything that must be present, in the form {extension_id};{update_url}. The update URL is optional and defaults to the relevant store. Force installed extensions cannot be removed or disabled by the user. Removing an entry uninstalls the extension.

Chrome additionally offers ExtensionSettings, a JSON dictionary that supersedes the individual policies and allows per extension control of permissions, allowed and blocked host access, minimum version, toolbar pinning and a custom block message. Use it where you need a nuanced position rather than a flat allow or block.

💡 Deploying the SenseOn browser extension: A deny-by-default extension policy is what makes a managed browser extension deployment predictable. If you are deploying the SenseOn browser extension, put its ID in the force list for coverage and in the allow list so it survives a tightening of the block list.

What browser policy will not do for you

Browser policy does not do category based filtering. There is no "block gambling" switch in Edge or Chrome policy. The only mechanism is an explicit URL list, capped at 1,000 entries, which is nowhere near enough to express a category and would need constant maintenance.

If the requirement is genuine category filtering, the options are:

Approach Examples of the layer Trade-off
DNS layer filtering A protective DNS or DNS filtering service applied to corporate resolvers and to roaming clients Cheapest and fastest to deploy. Blocks at domain granularity only, and can be bypassed with a hard-coded resolver or DNS over HTTPS unless you also lock those down.
Web proxy or secure web gateway On premises proxy or a cloud gateway with an agent Full category control, URL path granularity, TLS inspection where required. Highest cost and the most operational overhead.
Network firewall with URL filtering The existing perimeter firewall's subscription based filtering Often already licensed and unused. Only covers traffic that traverses the perimeter, so it misses remote workers unless traffic is routed back to the corporate network.

Where the browser and the endpoint agent add value alongside any of these is visibility. Telemetry on browsing activity lets you see and investigate where users have been, even in places you are not blocking, which is a different and complementary capability to filtering.

Deploying browser policy with Configuration Manager

Configuration Manager (formerly SCCM) has no dedicated browser policy profile. Where Configuration Manager is your management plane, there are three routes, matching the firewall routes:

  • Co-manage and use Intune. Move the relevant workloads to Intune and use the Intune sections above. This is the least effort for the richest policy set.
  • Configuration Items and baselines. Browser policy is only registry values under HKLM\SOFTWARE\Policies\Microsoft\Edge and HKLM\SOFTWARE\Policies\Google\Chrome. Create registry-value Configuration Items, or a single script Configuration Item, that set the policies from the registry reference, then deploy them in a Configuration Baseline with remediation enabled so drift is corrected on a schedule. List policies such as URLBlocklist are stored as numbered values under a subkey, so a script Configuration Item is usually cleaner than one item per value.
  • Deploy Group Policy alongside Configuration Manager. Where the estate is domain joined, the Group Policy sections above are the simplest way to deliver browser policy, with Configuration Manager used only for software distribution and reporting.

Deployment and rollout

Browser policy rolls out through the same ring model as the firewall. Deploy each control in an observable state before you enforce it.

Audit first, enforce second

Control Audit state Enforced state
Extension control Inventory installed extensions across the estate first, via browser reporting or endpoint telemetry. ExtensionInstallBlocklist = * with a reviewed allow list.
URL block list Deploy to Ring 0 only and confirm no unexpected matches. Estate wide.

Monitoring

  • edge://policy and chrome://policy on an endpoint show every applied policy, its source and its value. This is the fastest way to confirm a policy has landed. The Reload policies button forces a refresh.
  • Look for policies shown with a conflict or error status, which usually means an ADMX version mismatch or a malformed value.

Troubleshooting

Symptom Likely cause and check
Chrome ADMX import fails Dependency order. Import google.admx, then GoogleUpdate.admx, then chrome.admx, waiting for Available between each.
Browser policy not visible in chrome://policy Policy applies at machine level and the browser needs a restart. Also confirm the registry values are under Policies\Google\Chrome and that list entries are numbered from 1.
A policy shows a conflict or error The same policy is being set from two channels, or an ADMX version mismatch. Set each policy from one channel only.

Go live checklist

  • [ ] Delivery channel decided per browser (Intune, Group Policy, or Configuration Manager), with no overlap
  • [ ] SmartScreen and Safe Browsing enforced and locked from user override
  • [ ] Download restrictions set to the reputation-based value (4) and validated for false positives
  • [ ] Extension inventory completed before the deny-by-default extension policy is enforced
  • [ ] ExtensionInstallBlocklist = * with a reviewed allow list, including the SenseOn extension if deployed
  • [ ] URL allow and block lists reviewed and within the 1,000 entry ceiling
  • [ ] Edge and Chrome policies confirmed applied via edge://policy and chrome://policy
  • [ ] Category filtering requirement met at the DNS or proxy layer if needed, not assumed from browser policy

Appendix: registry reference

Component Location
Microsoft Edge policy HKLM\SOFTWARE\Policies\Microsoft\Edge
Microsoft Edge recommended HKLM\SOFTWARE\Policies\Microsoft\Edge\Recommended
Microsoft Edge update HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate
Google Chrome policy HKLM\SOFTWARE\Policies\Google\Chrome
Chrome list policies HKLM\SOFTWARE\Policies\Google\Chrome\<PolicyName> with REG_SZ values named 1, 2, 3 and so on
Chrome OMA-URI namespace ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome/<PolicyName>
Group Policy Central Store %systemroot%\sysvol\domain\policies\PolicyDefinitions

Data type mapping for browser policies. String policies are REG_SZ. Integer and boolean policies are REG_DWORD, with booleans expressed as 0 or 1. List policies become a subkey named after the policy, containing values named from 1 upwards. Dictionary policies such as Chrome's ExtensionSettings are supplied as a JSON string.

Reading browser policy on an endpoint

# Browser policy in the registry
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Edge' -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Google\Chrome' -ErrorAction SilentlyContinue
Get-ChildItem 'HKLM:\SOFTWARE\Policies\Google\Chrome\URLBlocklist' -ErrorAction SilentlyContinue

To confirm browser policy as the browser sees it, open edge://policy or chrome://policy and use Reload policies.

Sources

All URLs verified on 17 August 2026.

Microsoft Edge

Google Chrome

Intune configuration