Browser Update Management: Chrome, Edge, Firefox

Many enterprise browsers run old code for days after a fix is downloaded, because the update is staged on disk but the browser is not relaunched. Browsers ship security fixes far more often than operating systems, and their rendering engines appear regularly in the CISA Known Exploited Vulnerabilities catalogue, so the gap between "update available" and "update running" is real exposure. This guide covers update enforcement for Google Chrome, Microsoft Edge and Mozilla Firefox on managed Windows and macOS fleets: release channels, update and relaunch policies, version pinning and rollback, measurement and the rollout process. Platforms are listed alphabetically, and the order is not a ranking. It is written for endpoint engineers, vulnerability managers and security architects. For browser security settings (Safe Browsing, extensions, password storage), see the Browser Security Hardening Guide; this page deals only with getting fixes installed and running.

Key takeaways

Relaunch is the control that matters. All three browsers download updates silently, but the fix only runs after a restart, so a forced relaunch deadline (Chrome and Edge RelaunchNotification set to Required) is the single biggest lever.
Pick the channel deliberately. Stable gets a major release about every two weeks; Chrome and Edge Extended Stable move to an eight-week feature cycle and Firefox ESR to roughly 52 weeks, while all keep receiving security fixes.
Pin only to test, never to park. TargetVersionPrefix and AppUpdatePin are temporary tools; vendors warn that pinned or rolled-back devices fall behind on security fixes.
Measure the running version, not the installed one. Track the share of devices on the current security release within 72 hours and 7 days of release, from browser management reporting or EDR inventory.
Ring the rollout. Keep about 5% of users on Beta (Google's guidance) and a pilot ring on Stable, so compatibility problems surface before the broad fleet updates.

Why browser patching is different from operating system patching

Browser update management fails when teams treat it as a monthly patch-cycle item. Three properties make it different.

Cadence: Google, Microsoft and Mozilla each describe a Stable or Release major update about every two weeks, with security fixes shipped in between as needed. A monthly maintenance window guarantees that devices are always at least one security release behind.
Self-updating architecture: each browser carries its own updater (Google Update or the Chrome updater, Microsoft Edge Update, and the Firefox updater with its Windows background task). Patch tools that deploy MSI packages often fight these updaters rather than help them. See the Patch Management Guide for the wider process.
Exploitation path: browsers process untrusted content all day. Attackers use them for drive-by compromise (MITRE ATT&CK T1189) and exploitation for client execution (T1203), often through compromised or watering hole sites. See the Watering Hole Attacks Guide.
Embedded engines: Microsoft Edge WebView2 Runtime and Electron-based desktop applications carry their own copy of a browser engine. Edge Update manages WebView2 through a separate Update policy, and Microsoft warns that disabling those updates may break dependent applications.

Release channels and how to choose them

Each vendor offers a fast channel for most users and a slower channel for organisations that need fewer feature changes. The slower channel reduces feature churn, not security patching: Chrome and Edge Extended Stable and Firefox ESR all continue to receive security fixes.

Browser	Default enterprise channel	Slower channel	Preview channel for testing	Channel policy
Chrome	Stable: major release every 2 weeks	Extended Stable: updates every 8 weeks, still receives security fixes	Beta: Stable features about 2 weeks early; Google suggests about 5% of users	Target Channel override (Google Update policy)
Edge	Stable: about every 2 weeks, serviced until the next release	Extended Stable: 8-week major cycle (every fourth Stable release), security fixes as needed	Beta (supported channel); Dev and Canary are not supported	TargetChannel (Edge Update policy)
Firefox	Release: major update every 2 weeks, fixes as needed	ESR: major update on average every 52 weeks, minor updates at least every two weeks	Beta or Nightly on test devices	Separate ESR installer and update channel

Cadence figures are taken from the vendors' channel pages as checked in November 2026; vendors adjust schedules, so confirm against the current pages before setting SLAs.

Decision guidance

Choose Stable or Release for most knowledge workers. Feature changes are frequent but small, and the fleet stays close to the newest security code.
Choose Extended Stable or ESR where line-of-business web applications are fragile, where change control requires documented testing of every feature release, or for kiosks, call centres and shared clinical workstations. Mozilla recommends Firefox Release where possible and positions ESR mainly for testing internal applications.
Small organisations (no dedicated endpoint team) should stay on Stable with auto-update and a forced relaunch; the slower channels add process overhead without a test team to use the extra time.
Large organisations usually run three rings: Beta for IT and application owners, Stable pilot (5 to 10% of users across business units), then broad Stable. Extended Stable is reserved for named exception groups.

Enforcing updates: Chrome

Google Update policies (from the Google Update ADMX templates) control whether and how Chrome updates. Google states that only domain-joined or MDM-managed Windows computers honour these Group Policy settings, and recommends checking the applied values at chrome://policy after a change.

Update policy override default and Update policy override: set to allow updates (Google's recommendation) or automatic silent updates only. Google does not recommend disabling updates, and notes that if you do, you need a process for timely manual updates and a plan to re-enable them.
Auto-update check period override (AutoUpdateCheckPeriodMinutes): accepts 1 to 43,200 minutes. Leave it unset or short; a long period silently delays security fixes.
Time period in each day to suppress auto-update check: use only for bandwidth-sensitive sites, and keep the window short.
RelaunchNotification: 1 (Recommended) shows a recurring, dismissible prompt; 2 (Required) shows a recurring warning and forces a relaunch when the notification period ends. The browser session is restored afterwards.
RelaunchNotificationPeriod: in milliseconds; the default is 604,800,000 (seven days) and the minimum is 3,600,000 (one hour). The menu indicator appears after one third of the period and changes colour at two thirds.
RelaunchWindow: (Chrome 93 and later) moves the end of the notification period into a daily window, for example outside trading hours. The policy text warns that it may delay updates.
RelaunchFastIfOutdated: (Chrome 137 and later, minimum 7 days) shortens the notification period to two hours when the running version has been outdated for longer than the set number of days. It is a useful backstop for laptops that are rarely restarted.

Enforcing updates: Edge

Microsoft Edge Update policies live under HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate (msedgeupdate.admx). Per-channel settings take the channel GUID as a suffix, for example Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} for Stable. Microsoft documents several of these policies (UpdateDefault, Update, TargetVersionPrefix, RollbackToTargetVersion, TargetChannel) as applying to domain-joined devices, so confirm how your MDM delivers them before relying on them for Entra-joined fleets.

UpdateDefault and Update (per channel): 0 disabled, 1 always allow updates (Microsoft's recommended value), 2 manual updates only, 3 automatic silent updates only. Use 1 or 3.
AutoUpdateCheckPeriodMinutes: 0 to 43,200; Microsoft notes that 0 disables all periodic updater traffic and is not recommended.
UpdatesSuppressed: start hour, start minute and a duration of up to 960 minutes per day. Treat a long suppression window as an exception that needs approval.
RelaunchNotification: under HKLM\SOFTWARE\Policies\Microsoft\Edge (MSEdge.admx, Administrative Templates/Microsoft Edge/Relaunch), 1 Recommended or 2 Required; the default period is seven days and is set with RelaunchNotificationPeriod. The session is restored after the restart.
WebView2 Update: leave at 1 (always allow, the default). Inventory applications that ship a fixed-version WebView2 runtime, because those are updated by the application vendor, not by Edge Update.

Enforcing updates: Firefox

Firefox enterprise policies are set through the Firefox ADMX (Software\Policies\Mozilla\Firefox), Intune OMA-URI (./Device/Vendor/MSFT/Policy/Config/Firefox~Policy~firefox/...), macOS configuration profiles or a policies.json file in the installation directory.

AppAutoUpdate: true installs updates without asking the user (the operating system might still require approval); false downloads them but lets the user choose when to install. Set to true.
BackgroundAppUpdate: (Firefox 90 and later, Windows) installs updates while Firefox is not running. Enable it so devices where the browser is closed overnight wake up patched. It has no effect if DisableAppUpdate or AppAutoUpdate false is set.
DisableAppUpdate: turns off application updates completely. Use it only where another tool (a packaging and deployment system) delivers every Firefox release, and monitor that tool's lag.
AppUpdateURL: points Firefox at an internal update server; useful for offline networks, but you then own the speed of every security release.
ManualAppUpdateOnly: Mozilla describes it as intended for advanced end users rather than enterprises. Do not use it on managed fleets.
Restart prompts: pair AppAutoUpdate with your endpoint management tool's restart or notification workflow, and use BackgroundAppUpdate so closed browsers update without user action.

The live CIS Control 9 Email and Web Browser Protections Guide covers the related safeguard on running only fully supported browsers.

Version pinning and rollback

Pinning and rollback exist for a broken release, not for change avoidance. All three vendors provide them, and the vendor documentation is consistent that they should be short-lived.

Need	Chrome	Edge	Firefox	Vendor caution
Hold at a version while testing	TargetVersionPrefix, ideally a major milestone such as "130."	TargetVersionPrefix{GUID}	AppUpdatePin, value must end in a dot ("128." or "128.0.")	Google: pin only temporarily, such as while testing. Microsoft: an invalid version leaves Edge with no further automatic updates. Mozilla: a version that never exists means Firefox updates beyond it.
Return to an earlier version	RollbackToTargetVersion (needs a target set), three most recent majors only	RollbackToTargetVersion{GUID} (Edge 86 and later, needs TargetVersionPrefix and updates on)	Redeploy the earlier build through your software distribution tool	Google: earlier versions expose users to known security issues. Microsoft: intended as a temporary fix; turn on Sync first to avoid data loss.
Protect user data during rollback	Profile snapshots (three by default), Chrome sync or roaming profiles	Edge Sync	Profile backup before downgrade	Downgrading a profile can lose or corrupt newer data.

Pin by milestone, not full version: Google recommends major-milestone pinning so devices still receive security fixes within that milestone. Firefox AppUpdatePin "xx." works the same way.
Every pin has an owner and an expiry: record the reason, the application at fault, the approving manager and an end date of days, not months.

Implementation: a phased rollout

Inventory first. List every browser, channel and running version on every device, including portable copies and per-user installs under the user profile. Chrome Enterprise Core exposes browserVersions and channel per enrolled browser through its API; Edge and Firefox versions come from your EDR, MDM or software inventory. Map this to NIST SP 800-53 CM-8 and CSF ID.AM-02.
Remove what you will not support. Uninstall unapproved browsers and old per-user installs, or block them with application control. One unmanaged Chromium build undermines the whole programme.
Set the update baseline in audit form. Apply Update policy override, UpdateDefault and AppAutoUpdate to a pilot group with RelaunchNotification set to Recommended. Confirm settings at chrome://policy, edge://policy and about:policies.
Define rings. IT and application owners on Beta; a Stable pilot ring of 5 to 10% across departments; broad Stable; a named Extended Stable or ESR exception group with a documented reason.
Switch relaunch to Required. Start with RelaunchNotificationPeriod of seven days, then reduce to 72 or 48 hours once help desk volumes settle. Add RelaunchWindow if forced restarts during working hours are a problem, and RelaunchFastIfOutdated as a backstop on Chrome.
Write the emergency path. For an actively exploited browser flaw, shorten the relaunch period for the affected browser to a few hours through policy, notify users, and report coverage every few hours. See the Emergency Out-of-Band Patching Playbook.
Test rollback before you need it. In the pilot ring, rehearse TargetVersionPrefix plus RollbackToTargetVersion (Chrome, Edge) and a package downgrade (Firefox), and confirm that profiles and sync survive.
Hand over to operations. Publish the metrics below to the vulnerability management dashboard and review exceptions monthly.

Where identity fits

Browser patching protects identities as much as endpoints. A compromised browser process can read session cookies and saved credentials, which lets an attacker replay a signed-in session without the password or MFA. Unpatched browsers on privileged access workstations and on devices used by developers holding cloud console sessions deserve the shortest relaunch deadlines in the fleet. The software distribution and update servers themselves hold powerful machine credentials. See the MITRE ATT&CK T1185 Browser Session Hijacking page and Securing the patch management tool itself.

Detection and measurement

Report on the version that is running, because an update waiting for relaunch looks patched in some inventories. Useful data sources include Chrome Enterprise Core browser reporting, Edge management and MDM inventory, EDR process telemetry (the executable version of chrome.exe, msedge.exe and firefox.exe), and web proxy logs where user agent strings reveal outdated major versions.

Metric	How to measure	Suggested target
Fleet on current security release	Running version equals or exceeds the latest vendor security release, per browser	90% within 72 hours, 98% within 7 days
Median time from release to running	Vendor release timestamp to first report of the new running version	Under 3 days
Devices with updates disabled or long check periods	Policy compliance query for UpdateDefault 0 or 2, DisableAppUpdate, AutoUpdateCheckPeriodMinutes over 1,440	Zero outside approved exceptions
Active pins and their age	Count of TargetVersionPrefix and AppUpdatePin settings, with days since applied	No pin older than 14 days
Unsupported browsers or channels	Inventory of unmanaged browsers, Dev or Canary builds, and versions past vendor support	Zero on managed devices
Uptime of browser processes	EDR: browser processes running longer than the relaunch period	Falling month on month

Alert on policy drift too: a device that reports Update policy override as disabled, or a user-writable policies.json on a shared machine, is an early sign of someone working around the baseline. These checks support NIST SP 800-53 SI-2(2) (automated flaw remediation status) and CSF DE.CM-09. See the Risk-Based Vulnerability Management Guide for how browser findings fit into wider prioritisation.

Common failure patterns

Measuring installed, not running: software inventory reports the new version on disk while the old process has been running for three weeks. Without RelaunchNotification set to Required, many laptops simply sleep and resume.
Permanent pins: a TargetVersionPrefix set for one incompatible application stays in a GPO for a year. The fleet stops receiving security releases beyond that milestone and nobody notices because updates are "on".
Patch tool fighting the updater: updates are disabled to let a deployment tool control versions, the tool's package lags by weeks, and the browser's own faster path is gone. If you disable the built-in updater, measure the replacement's lag against vendor releases.
Forgotten engines: WebView2 with a fixed-version runtime, Electron applications and portable browsers in user profiles are outside the browser update policies and are often older than anything else on the device.
Exceptions without owners: Extended Stable and ESR groups grow because nobody reviews membership, and the "slow" group becomes the default.
Unsupported devices: operating system versions that a browser no longer supports stop receiving browser updates at all; these need replacement, isolation or removal.

Framework mapping

Framework	Reference	How browser update management meets it
NIST CSF 2.0	ID.AM-02, ID.RA-01, PR.PS-02, DE.CM-09	Browser and channel inventory, vulnerable version identification, software maintained commensurate with risk, monitoring of running versions
NIST SP 800-53 Rev 5	SI-2, SI-2(2), SI-2(3), CM-8	Flaw remediation, automated remediation status, time-to-remediate benchmarks, component inventory
NIST SP 800-40 Rev 4	Enterprise patch management planning	Treat browser updates as routine preventive maintenance with defined maintenance plans
CIS Controls v8.1	Safeguards 7.4 and 9.1	Automated application patch management; only fully supported browsers
ISO/IEC 27001:2022 Annex A	A.8.8, A.8.19	Management of technical vulnerabilities; installation of software on operational systems
MITRE ATT&CK	T1189, T1203	Reduces the window for drive-by compromise and client exploitation

Practitioner checklist

Inventory every browser, channel and running version, including per-user and portable installs.
Set Chrome Update policy override, Edge UpdateDefault and Firefox AppAutoUpdate to automatic updates on all managed devices.
Set RelaunchNotification to Required in Chrome and Edge with a period of 72 hours or less once the pilot is stable.
Enable Firefox BackgroundAppUpdate on Windows and attach restart prompts through endpoint management.
Keep about 5% of users on Beta and a Stable pilot ring that represents every department.
Give every pin and Extended Stable or ESR exception an owner, a reason and an expiry date.
Rehearse rollback in the pilot ring and confirm profile or sync recovery.
Report the share of devices on the current security release at 72 hours and 7 days, per browser.
Include WebView2, Electron applications and unsupported operating systems in the scope review.
Pre-approve an emergency policy change that shortens the relaunch period for actively exploited flaws.

Browser Update Management Guide: Enforcing Chrome, Edge and Firefox Updates at Scale