Chrome Manifest V3 Transition: Enterprise Extension Policy

Google has finished retiring Manifest V2 Chrome extensions, and the enterprise policy that kept them alive no longer exists in current Chrome, so any business process still relying on an MV2 extension is either broken or pinned to an outdated browser. Manifest V3 (MV3) also changes what extensions are technically able to do, which changes how security teams should write extension policy. This guide covers the official dated timeline, how to find MV2 extensions and the browsers still running them, the migration choices, how to test and roll back policy changes, and what MV3 does and does not fix. It is for endpoint, browser and identity teams that manage Chrome with Group Policy, MDM or the Google Admin console. For general extension risk management, see the Browser Extension Security Guide.

This is an independent guide from NHI Mgmt Group, based on Google's public Chrome extension documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

The policy escape hatch has closed. Google states that Chrome 138 was the final version to support MV2 extensions with the ExtensionManifestV2Availability policy, that the policy is removed in Chrome 139, and that MV2 extensions cease to function from Chrome 139 onwards.
The Chrome Web Store has removed MV2 listings. Per Google's timeline, all remaining MV2 extensions were removed from the store on 31 August 2026, so existing installs cannot be updated or reinstalled.
Old browsers are now the risk. The only way to keep an MV2 extension running is to hold Chrome at version 138 or earlier, which means running an unpatched browser; treat any such device as a vulnerability finding.
MV3 closes the remote code door, not the update door. MV3 forbids remotely hosted code and limits CSP, but a compromised publisher account can still ship a malicious MV3 update, so allow lists, permission controls and update monitoring still matter.
ExtensionSettings is now the main control. Use installation_mode, blocked_permissions, runtime_blocked_hosts and minimum_version_required to govern MV3 extensions, with the Admin console Apps and extensions usage report as the inventory.

What is changing and why

An extension's manifest.json declares its manifest_version. MV3 is the current platform; MV2 is the legacy one. Google's stated reasons for MV3 are security, privacy and performance, and the changes that matter for enterprise security teams are these:

Area	Manifest V2	Manifest V3	Security effect
Remotely hosted code	Extensions could load and run JavaScript fetched from a server	Removed: only JavaScript shipped in the package runs, and the package is what the Chrome Web Store reviews	Behaviour can no longer change after review without an update
Arbitrary code execution	tabs.executeScript with code strings, eval(), new Function()	scripting.executeScript with files or func and args; eval and new Function only in sandboxed iframes	Fewer injection paths for attacker-supplied strings
Content Security Policy	A single string, could be loosened	A dictionary with extension_pages and sandbox keys; script-src, object-src and worker-src limited to 'self', 'none', 'wasm-unsafe-eval' (and localhost for unpacked development)	No 'unsafe-eval' and no remote script hosts on extension pages
Background context	Persistent background page	Service worker that runs only when needed	Less long-lived state; mostly a performance change
Network request handling	Blocking webRequest, which required extensions to see and proxy all traffic	declarativeNetRequest rules evaluated by the browser for many use cases	Content filtering possible without reading every request
Host access	Host patterns mixed into permissions	Separate host_permissions and optional_host_permissions fields	Host access is visible as its own field
Web accessible resources	Flat list, exposed to all sites by default	Objects with resources and matches, exposed only to listed sites or extension IDs	Less fingerprinting and resource abuse from arbitrary sites

Google notes that some capabilities remain, for example scripting.insertCSS with remote stylesheets, devtools inspectWindow.eval and debugger.sendCommand, so high-privilege extensions still need scrutiny under MV3.

Official timeline and current status

All dates below are from Google's Manifest V2 support timeline page on developer.chrome.com, last updated 9 September 2026 and checked on 8 November 2026.

Date	Milestone (as Google states it)
January 2022	Chrome Web Store stopped accepting new MV2 extensions with Public or Unlisted visibility
June 2022	Store stopped accepting new MV2 extensions with Private visibility
3 June 2024	Phase-out began on Beta, Dev and Canary: warning banners, Featured badge removed from MV2 extensions
9 October 2024	Warnings reached all MV2 users and disabling began in stable; enterprises using the policy exempt until June 2025
31 March 2025	MV2 extensions disabled by default; users could still re-enable them
24 July 2025 (Chrome 138)	MV2 extensions disabled for all users on all channels, with no user re-enable; Chrome 138 is the final version supporting MV2 when paired with the policy
Chrome 139	ExtensionManifestV2Availability removed; MV2 extensions cease to function for anyone on Chrome 139 or later
31 August 2026	All remaining MV2 extensions removed from the Chrome Web Store; existing installs on Chrome 138 or earlier keep running but cannot be updated or reinstalled

Google's page describes the Chrome 139 policy removal in future tense, so we state it as announced rather than as an observed event. The Admin console help for the usage report states that from Chrome 139, MV2 extensions load disabled and cannot be re-enabled.

The ExtensionManifestV2Availability policy took four values: 0 or unset (follow the default timeline), 1 (disable MV2 and block installation), 2 (allow MV2) and 3 (allow only force-installed MV2 extensions, including those set by ExtensionInstallForcelist or ExtensionSettings). On current Chrome the policy has no effect, so remove it from GPO, Intune and Admin console baselines to avoid a false sense of control.

Who and what is affected

Line-of-business extensions: internal or vendor extensions built for MV2 that were force-installed and kept alive with policy value 2 or 3. These stopped working on Chrome 139 unless rewritten.
Self-hosted extensions: extensions installed from an internal update_url rather than the store are not affected by the store removal but are affected by the browser change.
Pinned or frozen browsers: kiosks, VDI images, OT jump hosts and test rigs where Chrome updates were held back to protect an MV2 workflow.
Security tooling delivered as extensions: DLP, web filtering, password management and SSO helpers. Vendors had to move to MV3 and declarativeNetRequest; behaviour and coverage may have changed.
Users with unmanaged profiles: extensions installed by users, whose MV2 add-ons are now disabled or have silently been replaced with lookalikes from the store.

Finding affected systems and identities

The fastest inventory for managed Chrome is the Google Admin console report at Devices > Chrome > Reports > Apps & extensions usage (Chrome administrator privilege, reporting turned on, data can take up to 24 hours). Google documents these useful columns: Notifications (flags such as MV2 deprecation or removal from the store in the past 28 days), Install type (admin, development, normal, sideload and others), Chrome Web Store status (Published, Unpublished by developer, Taken down by Google, No record on CWS, Developer account deleted), Permission count, Manifest version (with a warning icon for MV2) and App ID. Filter on Manifest version, export to CSV, and use the row actions Block or Force install.

Question	Where to look	What to act on
Which MV2 extensions are still installed?	Usage report, filter Manifest version 2	Find an MV3 replacement or remove
Which devices still run Chrome 138 or earlier?	Admin console browser list, endpoint management inventory, or your vulnerability scanner	Update the browser; treat holdouts as exceptions with an owner and end date
Which extensions were removed or taken down from the store?	Chrome Web Store column and Notifications column	Block items taken down by Google; review items with no store record
Which extensions are sideloaded or in developer mode?	Install type column	Block unless approved and signed through an internal update_url
Which policies reference MV2?	GPO, Intune configuration profiles, Admin console settings for ExtensionManifestV2Availability	Remove obsolete settings

The identity angle: extensions run inside authenticated browser sessions, and many hold OAuth tokens, session cookies or API keys for SaaS tools. Map each high-permission extension to the identities and SaaS tenants it can reach, and check the publisher account itself: a store developer account is a non-human publishing credential, and a single consent-phished developer token can be enough to push a malicious update, so protect publisher accounts with strong MFA and review OAuth grants on them. See the Browser Storage Security Guide.

Migration options

Situation	Option	Trade-off
Store extension with an MV3 version from the same publisher	Allow the MV3 version, set minimum_version_required to the first MV3 release	Check whether features were dropped, especially network filtering moved to declarativeNetRequest
Store extension abandoned by its publisher	Replace with a reviewed alternative or remove the business need	New publisher, new permissions review; watch for lookalike clones
Internal MV2 extension	Rewrite to MV3: bundle all code, service worker background, scripting API, host_permissions, new CSP format	Development effort; remote configuration must become JSON data, not code
Extension used only for a narrow site integration	Replace with a web app, bookmarklet-free workflow or server-side integration	Removes an extension entirely, which is the lowest-risk outcome
Hard dependency with no replacement yet	Isolated, time-boxed exception: a dedicated, network-restricted device or VDI pool on an older build	Running an unpatched browser; needs compensating controls and an end date

Decision guidance: small organisations should move to a strict allow list (installation_mode blocked for "*", allowed or force_installed per ID) as part of the clean-up, because the inventory is already in hand. Large organisations should set the default policy by organisational unit: block by default for most staff, a reviewed catalogue for developers, and force-installed security extensions everywhere. Use blocked_permissions for high-risk API permissions such as debugger or nativeMessaging where business need is absent, and runtime_blocked_hosts (up to 100 host patterns) to keep every extension away from identity providers, admin consoles and finance systems, with runtime_allowed_hosts for the few that need access.

Testing and rollback

Pilot by organisational unit: apply new ExtensionSettings to a pilot OU or a pilot GPO security filter first, including IT and the owners of affected business processes.
Test the replacement, not just the install: confirm the MV3 extension performs the business task, survives service worker restarts and still sees the sites it needs once runtime_blocked_hosts applies.
Watch user impact: use blocked_install_message (up to 1,000 characters) to point users at the request process, and track help desk tickets for the pilot.
Expand in rings: extend to wider OUs once the pilot is quiet for an agreed period, then remove the obsolete ExtensionManifestV2Availability value from all baselines.
Rollback: because policy is declarative, rolling back means restoring the previous ExtensionSettings JSON for the OU, which is why it should live in version control. Rolling back to MV2 itself is not possible on Chrome 139 or later; the only "rollback" for an MV2 dependency is the isolated exception above.

Risks of doing nothing

Browser update freezes: teams that hold Chrome below 139 to keep an MV2 tool forfeit browser security fixes on devices that handle email, SaaS and identity sessions.
Silent loss of security controls: an MV2 DLP, filtering or credential helper extension that stopped loading leaves a gap that nobody reports.
Unsupported extensions: MV2 extensions removed from the store receive no further updates, so known flaws stay unfixed on any old browser still running them.
Lookalike replacements: users searching for a replacement may install clones; without an allow list, these arrive with broad host permissions (ATT&CK T1176.001 Browser Extensions).
Stale policy: baselines still carrying ExtensionManifestV2Availability suggest a control that no longer exists, which misleads audits.

Framework mapping

Framework	Reference	Application
NIST CSF 2.0	ID.AM-02, PR.PS-02	Extension and browser version inventory; replacing unsupported software
NIST SP 800-53 Rev 5	CM-7, CM-11, SA-22, CM-8	Least functionality via allow lists, user-installed software control, removing unsupported extensions, inventory
CIS Controls v8.1	Safeguard 2.2; Safeguard 9.4 Restrict Unnecessary or Unauthorized Browser and Email Client Extensions	Supported software only; allow-listed extensions
MITRE ATT&CK v20	T1176.001 Browser Extensions	Malicious or hijacked extensions used for persistence and session theft

See the CIS Control 9 Email and Web Browser Protections Guide and, for an extension already suspected of compromise, the Malicious Browser Extension Incident Playbook.

Practitioner checklist

Export the Apps and extensions usage report and list every MV2 extension, sideloaded item and store takedown.
Find every device on Chrome 138 or earlier and either update it or record a time-boxed exception.
Remove ExtensionManifestV2Availability from GPO, Intune and Admin console baselines.
Move to a default-deny ExtensionSettings policy with per-ID allowed or force_installed entries.
Set runtime_blocked_hosts for identity provider, admin and finance domains, with narrow runtime_allowed_hosts exceptions.
Use blocked_permissions for high-risk API permissions with no business need.
Set minimum_version_required for critical extensions to stop downgrades to old builds.
Review the publisher accounts of internal extensions: MFA, consent restrictions for store publishing access, and alerting on new versions.

Chrome Manifest V3 Transition: Security Impact for Enterprise Extension Policy