How to Enforce Browser Updates Across a Managed Fleet

When Google patched the V8 zero-dayZero-Day🛡️A security vulnerability that is exploited or publicly disclosed before the software vendor can release a patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program., giving developers 'zero days' to fix it. CVE-2026-85046 on 3 September 2026, most managed fleets had the new Chrome installer within hours. That is not the same as being patched. Chrome, Edge and every other Chromium-based browser load the update on the next relaunch, and users who keep dozens of tabs open for weeks defeat auto-update entirely. This guide covers how to turn "update available" into "update running" across a managed fleet, and how to prove it from inventory.

Step 1: Decide what "patched" means

Write the target down before you touch policy. For a Chromium security fix you need three numbers: the fixed Chrome build (for CVE-2026-85046, 152.0.7977.82), the equivalent Edge build (152.0.4191.62 per Microsoft's security notes), and the version of any other Chromium-based browser you allow. The version that matters is the one reported by the running process, not the installer log. Most inventory tools report the installed binary, which is correct only if the process has restarted since installation.

For the wider set of Chromium copies on a machine (WebView2WebView2🛡️Microsoft's control for embedding Chromium-based web content inside Windows applications. The Evergreen runtime updates alongside Microsoft Edge, while a Fixed Version runtime is bundled by the application vendor and receives Chromium security fixes only when the vendor ships a new package., Electron apps) the definition is per product, and the planning piece The Chromium Downstream Problem: Tracking Patches in Forks and Embedded Browsers covers that inventory. This guide focuses on the browsers you manage directly.

Step 2: Confirm auto-update is on and not throttled

On Windows, Chrome updates are handled by Google Update, and Google publishes administrative templates for it. The documented controls include an update policy override (allow updates, silent updates only, manual only, or disabled), a target version prefix, a target channel, a daily suppression window, and an update check period. Audit for two mistakes:

• An update policy override set to manual or disabled, usually left over from a compatibility freeze years ago.
• A target version prefix pinning the browser to an old major. Pinning is legitimate during a rollback, but it silently blocks security updates until someone removes it.

Edge uses its own updater with equivalent controls, and Microsoft moved Edge to a two-week major release cadence in 2026, so a pin that seemed harmless last year now holds the browser back by several security releases.

Chrome's Extended Stable channel is worth knowing about: it receives security fixes on the same day as Stable but takes feature releases every eight weeks instead of four. It is a way to reduce change without reducing security updates, and is often a better answer than pinning.

Step 3: Force the relaunch

This is the step most organizations skip. Google's enterprise documentation describes a small set of Chrome policies for it:

• RelaunchNotification. Set to "Relaunch recommended" the user sees a dismissible prompt. Set to "Relaunch required" the user sees a recurring warning that the browser will relaunch itself when the period ends, and Chrome then relaunches on its own.
• RelaunchNotificationPeriod. The length of that window in milliseconds. The default when unset is seven days, which is far too long during an in-the-wild exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access.; a value of one or two days is common for security-sensitive groups.
• RelaunchWindow. Lets you constrain the forced relaunch to a time window, for example overnight, so that users are not interrupted mid-task. Google notes that by default relaunches aim for a two-to-four AM window in the user's time zone and that the countdown extends if the window cannot be met.

Chrome restores tabs on a policy-driven relaunch, so the user cost is low. Edge exposes the same family of relaunch policies, and its August 2026 release added a policy to relaunch in the background when all windows are closed, which closes the gap for users who close the browser but never reboot.

Apply these through the same channel as the rest of your browser policy: Group Policy or Intune on Windows, configuration profiles on macOS, JSON policy files on Linux, or Chrome Browser Cloud Management for Chrome on any platform.

Step 4: Set up an emergency tier

Normal cadence and zero-day cadence should be different policies, and the switch between them should be a single change. A workable pattern:

• Baseline: relaunch required, seven-day period, overnight window.
• Elevated (a KEV addition or a vendor in-the-wild note): relaunch required, period cut to 24 or 48 hours, applied to all users.
• Priority group (administrators, help desk, finance, anyone with standing privileged sessions): 24 hours at all times.

Keep the elevated policy pre-staged in a disabled state so that flipping it takes minutes, not a change ticket. The triage flow in How to Triage a CISA KEVCISA KEV🛡️The Known Exploited Vulnerabilities catalog maintained by CISA, listing vulnerabilities actively exploited in attacks that federal agencies must patch by specific deadlines. Addition in 72 Hours assumes exactly this kind of pre-approved switch.

Step 5: Verify from the running version

Inventory should answer one question: how many endpoints have a Chromium-based browser process running below the floor right now? Sources, in rough order of reliability:

• Chrome Browser Cloud Management and the Edge management service report the version of enrolled browsers directly, including the currently running version, and can flag machines with a pending relaunch.
• Endpoint detection tools generally record the image version of running processes, which lets you query for browser executables below a version rather than relying on installed-software tables.
• Configuration management inventories (Intune, SCCM, Jamf) report the installed version and are the least reliable for this purpose, because they cannot see whether the process restarted.

Set a reporting deadline that matches the exploit window. For a KEV entry with a fourteen-day federal due date, a 48-hour target for the priority group and seven days for everyone else is a reasonable internal standard.

Step 6: Handle the exceptions

Three groups will always fall outside the main flow:

• Kiosks, shared workstations and long-running sessions that never log off. Schedule a forced reboot for these rather than a relaunch.
• Machines running a pinned version for a line-of-business web app. Document the pin with an owner and an expiry, and consider Extended Stable instead.
• Unmanaged Chromium browsers users installed themselves. Application control that limits browsers to the managed set removes this category; failing that, at least inventory it.

Why the process matters more than the patch

Chrome shipped six in-the-wild zero-day fixes in the first eight months of 2026. Each fix is trivial to deploy and easy to leave unapplied in memory. The bugs themselves, explained in How V8 Type ConfusionType Confusion🛡️A memory-safety bug (CWE-843) in which code accesses a resource using an incompatible type, such as reading a pointer as an integer. In JavaScript engines it typically arises when optimized code trusts an assumption about an object's shape that a callback has since invalidated, as in CVE-2026-85046. Bugs Turn JavaScript Into Memory Corruption, are triggered by nothing more than visiting a page, which makes the gap between "installed" and "running" the entire exposure window. A fleet that can relaunch every managed browser within 48 hours of a vendor note, and prove it, has turned a recurring emergency into routine maintenance.