Partly. Chrome tries to stop users uninstalling a force-installed extension, but its own policy text says that prevention is best effort because some operating systems make external modification impossible to defend against. It also says users can change extension source through developer tools, and suggests DeveloperToolsDisabled if that worries you.
What the policy definition states
Three statements in the Chromium definition of ExtensionInstallForcelist matter here:
- Chrome "aims to prevent users from uninstalling these extensions," but some operating systems make it impossible to defend against extensions being modified externally, so this prevention is best effort.
- The source code of any extension may be altered by users through developer tools, which can leave the extension dysfunctional. If that is a concern, set the
DeveloperToolsDisabledpolicy. - The policy does not apply to Incognito mode.
None of this means force-install is weak. It means it is a management control, not a tamper-proof one.
Threat model: who are you worried about?
| Who | Likely action | Does the policy stop it? |
|---|---|---|
| Curious employee | Opens developer tools and edits the extension | Not by default. Consider DeveloperToolsDisabled |
| Employee who wants a tool off | Tries to disable or remove it | Blocked in the browser interface, best effort at OS level |
| Malware on the machine | Modifies files directly | Not reliably. Chrome says so itself |
| Outside attacker | Publishes a malicious update | Policy does not help. Publisher review does |
What to do about it
- Lock developer tools where the extension is a control. If your forced extension enforces something, such as a posture check, set
DeveloperToolsDisabledfor that group. This has a cost: developers need devtools, so scope it to non-developer groups. - Do not rely on the browser to enforce security by itself. If an extension gates access, verify the result server-side as well.
- Check Incognito. Because the policy note says it does not apply to Incognito mode, decide whether Incognito should be disabled or restricted for managed profiles. Confirm the current setting names in the browser's policy list.
- Use device management. File-level protections belong to the operating system layer, not the browser.
- Monitor for the extension being absent. If your management console can report installed extensions, alert when a required one is missing.
Where an extension should not be the control
An extension is code running in a browser the user controls. For anything high stakes, such as blocking exfiltration or enforcing authentication, the browser-side piece should be a convenience and the decision should be made by a server you control.
Pair it with review
A forced extension runs with permissions you granted implicitly. Review its requested permissions and host access, and keep it on a short list. See what force-installing grants.
What to put in your policy document
Write down what the control is meant to do and what it is not. For example: forced extensions are installed and updated by management, users cannot remove them through the browser, and the company does not rely on them as the only enforcement. That sentence sets honest expectations for auditors and for your own team, and it stops someone later treating a browser extension as a security boundary it was never designed to be.
Quick check
Does force-install protect against a malicious update?
No. It controls installation and removal, not what a publisher ships. That risk needs review and monitoring.
Should I disable developer tools for everyone?
Probably not. Developers rely on them. Scope the setting to groups where the extension acts as a control.
Sources
Last reviewed: 19 October 2026.
