The new Microsoft Edge offers a rich set of policies that enable IT administrators to control many aspects of its operation.
You can visit
edge://policy/ to see the policies in effect in your current browser:
Clicking on a policy name will take you to the documentation for that policy. The Status column indicates whether the policy is in effect, in Error, or Ignored. A policy is in Error if the policy name is unrecognized or the policy value is malformed. A policy is Ignored if the policy is a Protected Policy and the machine is not Domain Joined or MDM managed. Policies are marked “Protected” if they are especially often abused by malware. For instance, policies controlling the content of the New Tab Page are protected because adware/malware commonly attempted to monetize users by silently changing their search engine and homepage when their “free” apps were installed on a user’s PC. Protected Policies are marked in the Edge documentation with the note:
This policy is available only on Windows instances that are joined to a Microsoft Active Directory domain, Windows 10 Pro or Enterprise instances that enrolled for device management, or macOS instances that are that are managed via MDM or joined to a domain via MCX.
When Edge detects that a device is in a managed state in which Protected Policies are allowed, it will show “Managed by your organization” at the bottom of the … menu
There’s no magic in how policies are implemented: while you should prefer using
edge://policy to look at policies to get Edge’s own perspective about what policies are set, you can also view (and set) policies using the Windows Registry:
Careful, this thing is loaded…
You must take great care when configuring policies, as they are deliberately much more powerful than the options exposed to end-users. In particular, it is possible to set policies that will render the browser and the device it runs on vulnerable to attack from malicious websites.
Administrators should take great care when relaxing security restrictions through policy to avoid opening clients up to attack. For instance, avoid using entries like
https://* in URLList permission controls– while such a rule may cover all of your Intranet Zone sites, it also includes any malicious site on the Internet using HTTPS.
… but Incomplete
Notably, not all settings in the browser can be controlled via policy. For instance, some of the web platform feature settings inside
edge://settings/content can only be enabled/disabled entirely (instead of on a per-site basis), or may not be controllable at all.
In some cases, you may only be able to use a Master Preferences file to control the initial value for a setting, but the user may later change that value freely.