Step 1 — Gather Extension IDs
⏱ 5–10 min
1
Collect the 32-Character ID for Each Approved Extension
edge://extensions
▼
💡 Why is this step needed?
Intune's Edge extension policies are enforced by extension ID — not by name. Extension IDs are unique 32-character alphanumeric strings that permanently identify a specific extension in the Microsoft Edge Add-ons store. Using IDs rather than names means the policy is unambiguous and tamper-resistant — an extension cannot bypass the block by being renamed, and there is no risk of accidentally allowing the wrong extension because two extensions share a similar name.
| # | Action | Notes |
|---|---|---|
| 1 | Open Microsoft Edge on any managed device | |
| 2 | Navigate to edge://extensions | The browser's built-in extension management page |
| 3 | Toggle on Developer Mode | Switch in the bottom-left of the page — reveals full extension details |
| 4 | Note the 32-character Extension ID shown beneath each extension's name | e.g. jmjflgjpcpepeafmmgdncpkgpkfhhlm |
| 5 | Record the ID for every extension that R&R IT has approved | Keep a master list in your change record or ITSM ticket |
ℹ Alternative — Edge Add-ons Store URL
The extension ID also appears in the URL when you view an extension's page in the Edge Add-ons store:
microsoftedge.microsoft.com/addons/detail/[name]/ID-HERE. This is useful for collecting IDs for extensions not yet installed on any device.⚠ Vet Every Extension Before Adding
Adding an extension ID to the allow-list permits it on every managed R&R device. Every extension must be security-reviewed before its ID is recorded. Check the extension's permissions (what data it can access), publisher reputation, and whether it is required for a legitimate business purpose.
Step 2 — Create Configuration Profile
⏱ 3–5 min
2
Create a New Settings Catalog Policy in Intune
intune.microsoft.com
▼
💡 Why Settings Catalog — not ADMX or Custom OMA-URI?
The Settings Catalog is Microsoft's modern, searchable policy configuration interface for Intune. It natively exposes Edge browser policies (including extension control settings) without requiring manual ADMX imports or hand-crafted OMA-URI strings. This makes the policy auditable, readable, and maintainable — another engineer can open the policy in the portal and immediately understand what it does, without needing to decode raw XML or OMA-URI paths.
| # | Action | Notes |
|---|---|---|
| 1 | Open the Intune Admin Center | intune.microsoft.com |
| 2 | Navigate to Devices → Configuration → Create → New Policy | |
| 3 | Set Platform to Windows 10 and later | |
| 4 | Set Profile Type to Settings Catalog | |
| 5 | Enter a clear, descriptive policy name | e.g. Win11 – Block Edge Extensions – Allow-List |
| 6 | Click Next |
ℹ Naming Convention
Use a consistent naming pattern that signals OS, purpose, and scope. This makes the policy identifiable in a list of dozens of configuration profiles and helps engineers understand its function without opening it.
Step 3 — Add Extension Settings
⏱ 2–3 min
3
Search for and Add the Microsoft Edge Extension Settings
Settings Catalog
▼
💡 Why is this step needed?
The Settings Catalog contains thousands of configurable settings across all policy areas. You must explicitly add the three Edge extension settings to your policy before you can configure them — they do not appear by default. All three must be added at Device scope (not User scope) to ensure the policy applies regardless of which user logs into the device.
| # | Action | Notes |
|---|---|---|
| 1 | Click Add settings on the Configuration settings page | |
| 2 | In the Settings Picker, search for Microsoft Edge > Extensions | Use the search box at the top of the picker |
| 3 | Add the following three Device-level settings (tick each): | Ensure you select the (Device) variants |
Settings to add:
Block
Control which extensions cannot be installed (Device)Allow
Allow specific extensions to be installed (Device)Optional
Control which extensions are installed silently (Device)
Step 4 — Configure the Three Settings
⏱ 5 min
4
Configure Block-All, Allow-List, and Silent Install Settings
Settings Catalog
▼
💡 Why do these three settings work together?
The block-all wildcard and the allow-list are evaluated together by Edge — the allow-list acts as an explicit exemption from the blanket block. Microsoft confirms that setting
* in the blocklist blocks every extension, but the allowlist takes precedence for any ID explicitly listed. The silent install setting is a separate, optional control governing whether IT can push extensions without user interaction.1
Control which extensions cannot be installed
🚫 Block All
Setting name
ExtensionInstallBlocklist
Set toEnabled
Value* (a single asterisk — wildcard for all extensions)
The wildcard
* instructs Edge to block every extension from installing unless it appears on the allow-list. This establishes the deny-by-default baseline — no extension can be installed by default, eliminating the risk of users installing unvetted add-ons that could exfiltrate data or compromise security.2
Allow specific extensions to be installed
✅ Allow-List
Setting name
ExtensionInstallAllowlist
Set toEnabled
ValueEnter each approved extension ID on its own line (from Step 1)
Add each 32-character extension ID from your Step 1 list, one per line. Edge evaluates this list against the blocklist and permits only these specific extensions to be installed. This is R&R's organisational extension allow-list — changes to this list require IT security sign-off and a change record.
3
Control which extensions are installed silently
◇ Optional
Setting name
ExtensionInstallForcelist
Set toDisabled (unless force-install is required)
Disabling this prevents Intune from automatically pushing extensions to devices without user awareness. Enable and configure this setting only if R&R needs to silently deploy a specific approved extension to all managed devices — for example, a mandatory security or productivity tool.
Step 5 — Assign the Policy
⏱ 2 min
5
Assign to Pilot Group, Then Promote to Production
Intune
▼
💡 Why is this step needed?
This policy has immediate user impact — the moment it applies to a device, any extension not on the allow-list will be blocked. If an approved extension ID was accidentally missed from the list, or if an extension used by a business-critical workflow was overlooked during the approval process, users will lose access without warning. A phased pilot deployment catches these gaps on a small group before the policy affects the full estate.
| # | Action | Notes |
|---|---|---|
| 1 | Click Next to reach the Assignments page | |
| 2 | Add the pilot group under "Included groups" | A small representative set of users covering different roles |
| 3 | Click Next and then Create | |
| 4 | Monitor the pilot group for any blocked extensions that should have been approved | Intune → Devices → Monitor → Configuration profiles |
| 5 | After successful validation, edit the policy and add the production group | Only after pilot is confirmed clean |
⚠ Check Business-Critical Extensions First
Before assigning to production, confirm with department leads whether any role-specific extensions are in use that have not been approved — for example, accessibility tools, dictation software, or screen reader add-ons. Blocking these without warning could impact users with accessibility needs.
Step 6 — Validate on Client
⏱ 5 min
6
Validate Policy Application on a Managed Device
edge://policy
▼
💡 Why is this step needed?
Intune policy reporting confirms the policy has been delivered to the device — but it does not confirm that Edge has applied the settings. The
edge://policy page is the authoritative source within the browser itself, showing every policy that Edge has received and applied. Checking here confirms the extension blocklist and allowlist are active, catching any misconfiguration or policy conflict before production rollout.Check policy application in Edge:
| # | Action | Notes |
|---|---|---|
| 1 | On a pilot device, trigger an Intune sync | Settings → Accounts → Access work or school → Sync, or via Company Portal |
| 2 | Open Microsoft Edge and navigate to edge://policy | |
| 3 | Locate ExtensionInstallBlocklist and ExtensionInstallAllowlist | Use Ctrl+F to search the page |
| 4 | Verify the values match what was configured in Step 4 | See expected output below |
Expected output at edge://policy:
edge://policy
ExtensionInstallBlocklist = ["*"]
← blocks all extensionsExtensionInstallAllowlist = ["approvedID1", "approvedID2", "approvedID3"] ← your approved IDs
Verify expected behaviour:
| Scenario | Extension Type | Expected Outcome |
|---|---|---|
| Install a non-approved extension from the Edge Add-ons store | Any unlisted ID | 🚫 Blocked immediately |
| Install an approved extension from the Edge Add-ons store | Listed in allowlist | ✅ Installs normally |
| Extension already installed before policy applied | Unlisted ID | 🚫 Automatically disabled |
| Extension already installed before policy applied | Listed in allowlist | ✅ Continues to function |
✔ Deployment Complete
All policy values are confirmed in
edge://policy and the expected block/allow behaviours are working correctly. Proceed to assign the policy to the production group. Document the extension allow-list in your change record and establish a review process for approving new extension requests.