The two parts of any deployment
However you deploy, you're always doing two things:
Install the extension — force-install the extension so it lands on the device and stays enabled.
Configure the deployment key — link the installed extension to your organization's Nudge Security instance.
Both are required. Install without the key and the extension runs but stays unlinked from your Nudge Security instance, so it reports nothing.
You'll find every file and value you need in Nudge Security under Settings → Browser Extension → Enroll New Users → Managed Deployment → Device Management, then select your browser.
Choose your method
Intune gives you two ways to deliver both parts. They produce the same end state—a force-installed, linked extension—but they behave very differently afterward.
| Method 1: Configuration profiles | Method 2: Platform scripts |
What it is | Native Intune policy (Settings catalog, imported ADMX, or macOS preference file) | PowerShell (Windows) or shell (macOS) scripts run on the device |
Enforcement | Continuous — re-applied on every check-in, drift is corrected | One-time — runs once after enrollment, no self-healing |
Removal | Automatic — unassign the profile and the setting reverts | Manual — you need a separate teardown script |
Compliance reporting | Yes — per-device applied/failed/drift state in the console | Only whether the script ran, not whether the state is still correct |
ADMX import needed? | Yes, for Brave, Firefox, and Comet on Windows | No — scripts write the keys directly |
Effort per browser | One or two profiles each | One script set covers all browsers at once |
Use configuration profiles when you want the extension enforced and visible long-term—the right default for a managed fleet you're reporting on.
Use platform scripts when you want the fastest rollout with the fewest moving parts, or you're deploying to a mixed or partly unmanaged fleet where importing ADMX templates per browser is a hassle. The tradeoff is no ongoing enforcement, no compliance reporting, and manual cleanup.
Pick one method per browser—don't run both. Layering a script and a profile that both write ExtensionInstallForcelist is the classic cause of policy conflicts. If you already force-install other extensions, fold Nudge into your existing approach rather than adding a second one.
Method 1: Configuration profiles
The enforced, reportable path.
On Windows, Chrome and Edge work out of the box; Brave, Firefox, and Comet need their ADMX templates imported first. On macOS, you upload preference-file PLISTs.
Windows (profiles)
The process (all browsers)
Part 1 — Install the extension
Go to Devices → Manage Devices → Configuration → Create → New Policy.
Set platform to Windows 10 and later and profile type per the table below, then click Create.
Name it (e.g., Nudge Security – Chrome), add a description if you want, then click Next.
In the Setting picker, enable the per-browser setting from the table and paste in the value.
Click Next, set scope tags if needed, then assign your target groups or all users. Click Next.
Review and click Create.
Part 2 — Configure the deployment key
Go to Scripts and Remediations, click Add, and select Windows.
Name it (e.g., Nudge Security – Chrome Registry Settings).
In Nudge, go to Settings → Browser Extension → Enroll New Users → Managed Deployment → Device Management → select your browser → Confirm Browsers → Step 2: Configure Deployment Policy → Download PowerShell script. Upload that script.
Set: Run as logged-on user = No, Signature check = No, 64-bit host = Yes.
Assign your device groups, review, and click Save.
Even in the profile-based method, the deployment key (Part 2) is delivered by a small script, because the key isn't a browser policy setting—it's a Nudge value the browser can't express as a managed policy. Only Part 1 is a true configuration profile here.
Per-browser specifics (Windows)
The shared force-install value for all Chromium browsers (Chrome, Edge, Brave, Comet, Dia, Atlas) is:
diaecjfdpohehjhliaephjnpnlmeajfa;https://clients2.google.com/service/update2/crx
Browser | Import ADMX first? | Profile type | Setting to enable | Value to paste |
Chrome | No | Settings catalog | Google Google Chrome Extensions → Configure the list of force-installed apps and extensions | Chromium value (above) |
Edge | No | Settings catalog | Microsoft Edge\Extensions → Control which extensions are installed silently | Chromium value (above) |
Brave | Yes — Brave ADMX | Templates → Imported Administrative Templates | Computer Configuration → Brave → Brave → Extensions → Configure the list of force-installed apps and extensions | Chromium value (above) |
Comet | Yes — Perplexity + Comet ADMX | Templates → Imported Administrative Templates | Perplexity → Comet → Extensions → Configure the list of force-installed apps and extensions | Chromium value (above) |
Firefox | Yes — Mozilla + Firefox ADMX | Templates → Imported Administrative Templates | See Firefox note below | See Firefox note below |
Importing ADMX templates (Brave, Comet, and Firefox)
These browsers aren't in Intune's native catalog, so you import their policy definitions once before creating the profile.
Brave:
Download policy_templates.zip from Brave and extract it.
In Intune, go to Devices → Configuration → Import ADMX → Import and import the files.
Firefox needs two imports, in order, because one depends on the other.
Download the latest policy_templates_vX.YY.zip from Mozilla and extract it.
In Intune, go to Devices → Configuration Profiles → Import ADMX → Import.
Import mozilla.admx with mozilla.adml first and wait for the status to show Available. (
mozilla.admxis a dependency—importingfirefox.admxfirst fails with a missing-namespace error.)Then import firefox.admx with firefox.adml.
Comet also ships two templates and requires an enrollment step.
Download the policy package (.zip) from your Comet admin console under Organization Settings → Comet configuration → Organization deployment → Download policy package files.
Import perplexity.admx first, then comet.admx, each with its matching
.adml.Before the force-install policy will apply, enroll the device by setting the CloudManagementEnrollmentToken policy (under Perplexity → Comet) to your org token. This links Comet to your organization and is unique to Comet—Chrome, Edge, and Brave don't need it.
Firefox setting details
Firefox uses two settings instead of one. Under Computer Configuration → Mozilla → Firefox → Extensions:
Extensions to Install → Enabled → paste:
https://addons.mozilla.org/firefox/downloads/latest/nudge-security-browser-ext/latest.xpiPrevent extensions from being disabled or removed → Enabled → paste:
nudge-security-browser-helper@nudge.security
Then continue with Part 2 above to configure the deployment key.
macOS (profiles)
You'll create two configuration profiles per browser: one to install the extension, one to configure the deployment key.
Where to get your files: In Nudge, go to Settings → Browser Extension → Enroll New Users → Managed Deployment → Device Management → select your browser(s) → macOS. Download the Install Extension PLIST in Step 1 and copy the Deployment Key value in Step 2.
The process (all browsers)
Part 1 — Install the extension
Go to Devices → macOS → Configuration → Create → New Policy.
Set profile type and category per the table below.
Name it (e.g., Nudge Security – Chrome macOS Install).
Set the install preference domain from the table.
Upload the Install Extension PLIST.
Assign groups/devices.
Part 2 — Configure the deployment key
Create a new profile: Devices → macOS → Configuration profiles → Create profile.
Name it (e.g., Nudge Security – Chrome macOS Registry Settings).
Set the deployment-key preference domain from the table.
In your Configure Extension PLIST, replace
DEPLOYMENT_KEY_HEREwith the key you copied from Nudge, then upload it.Assign groups/devices.
Sync devices with Intune, or use Company Portal on a target device to force a check-in while testing.
Per-browser specifics (macOS)
Browser | Part 1 profile type | Install preference domain | Deployment-key preference domain |
Chrome | Templates → Preference file |
|
|
Brave | Templates → Preference file |
|
|
Edge | Settings catalog (see note) | — |
|
Firefox | Templates → Preference file |
| Uses a Bash script — see note |
Edge note: For Part 1, Edge uses a Settings catalog profile instead of a PLIST. Set category to Microsoft Edge → Control which extensions are installed silently, check the box, and paste the Chromium value above. Then continue to Part 2 normally.
Firefox note: Firefox requires managed storage to be defined separately from the extension bundle, so Part 2 uses a script instead of a PLIST:
Create the profile under Devices → macOS → Scripts → Add.
Download the Bash script from Step 2B in the Nudge product and upload it.
Set: Run script as signed-in user = No, Hide script notifications = Yes, Script frequency = Every 1 day.
Dia, Atlas, and Comet on macOS
These are all Chromium-based—deploy them like Chrome, Brave, or Edge, with their own preference domains. Add the matching keys to the install PLIST so Nudge knows which browser it's running in.
Browser | Install preference domain |
|
Dia |
|
|
Atlas |
|
|
Comet |
|
|
For example, for Comet the deployment-key preference domain is ai.perplexity.comet.extensions.diaecjfdpohehjhliaephjnpnlmeajfa, and the install PLIST includes:
<key>nudge-security-browser-name</key>
<string>comet</string>
<key>nudge-security-deployment-key</key>
<string>DEPLOYMENT_KEY_HERE</string>
Comet has one extra prerequisite. Enroll the device in your Comet organization (the CloudManagementEnrollmentToken policy, set with your org token) before browser policies take hold. The Nudge extension force-installs regardless, but enrollment is what links Comet to your org for centralized management.
A few things to know about macOS profiles
Both PLISTs are required for the extension to work (Firefox is the exception—one PLIST plus the script).
Install-only (no key) means the extension installs but stays unlinked from Nudge.
Give it time to sync after deployment. Restarting the browser is often needed before it picks up the new policy.
Pros and cons — configuration profiles
Pros
Continuous enforcement. Intune re-applies the policy on every check-in. If a value drifts or gets cleared, it's restored automatically—so the extension can't be quietly removed.
Clean removal. Unassign the profile and the setting reverts on its own. No teardown script to write or maintain.
Compliance visibility. The console reports applied/failed/drift state per device, which feeds the kind of fleet-wide reporting and health scoring you'd want long-term.
Microsoft-maintained definitions for Chrome and Edge—no scripts of your own to sign or update.
Cons
ADMX import overhead. Brave, Firefox, and Comet each need their templates imported before you can configure them, with dependency-order gotchas.
More artifacts. Up to two profiles per browser, per OS, so the object count grows quickly across a multi-browser fleet.
Preview features. Intune's imported administrative templates are still labeled Preview, with limits (max 20 ADMX files, 1 MB each, en-us ADML only).
Still needs a script for the key. The deployment key can't be a pure policy, so Part 2 is always a small script even here.
Method 2: Platform scripts
The fastest path with the fewest moving parts. One set of scripts handles install and deployment key for every browser at once—no ADMX imports, no per-browser profiles. You ship them under Devices → Scripts and they run once per device after enrollment.
Nudge provides three scripts (don't confuse the install script with the per-browser configure scripts):
Script | Does | Covers |
InstallNudgeBrowserExtension.ps1 | Writes the force-install list for every browser | Chrome, Edge, Brave, Comet, and Firefox |
ConfigureNudgeBrowserExtension.ps1 | Writes the deployment key into each Chromium browser's policy path | Chrome, Edge, Brave, Comet |
ConfigureFirefoxNudgeBrowserExtension.ps1 | Writes Firefox's managed-storage JSON + registry pointer | Firefox only |
Firefox gets its own configure script because it can't take the key via registry policy the way Chromium browsers do—it uses a managed-storage manifest instead.
Windows (scripts)
Open each script and replace the
NUDGE_EXTDK.REPLACE_MEplaceholder with your deployment key from Nudge (Settings → Browser Extension → Enroll New Users → Managed Deployment).In Intune, go to Devices → Scripts and Remediations → Platform scripts → Add → Windows.
Name it (e.g., Nudge – Install Browser Extension) and upload the script.
Set: Run this script using the logged-on credentials = No, Enforce script signature check = No, Run script in 64-bit PowerShell Host = Yes. (HKLM writes need system context and the 64-bit host, or the keys land in the wrong place.)
Assign your device groups and save.
Repeat for the configure script(s):
ConfigureNudgeBrowserExtension.ps1for Chromium browsers, plusConfigureFirefoxNudgeBrowserExtension.ps1if you support Firefox.
The install script merges safely—it appends Nudge to any existing ExtensionInstallForcelist rather than overwriting, and migrates an older single-value force list into the numbered-key format. So it won't clobber extensions you already force-install.
Comet still needs enrollment. The scripts write Comet's force-install and key just like Chrome's, but the CloudManagementEnrollmentToken that links Comet to your org isn't something these scripts set. Push that one value as a policy (or via your Comet admin console) regardless of which method you use for the extension itself.
macOS (scripts)
macOS uses the equivalent shell scripts from Nudge, deployed under Devices → macOS → Scripts → Add:
Run script as signed-in user = No
Hide script notifications on devices = Yes
Script frequency = Every 1 day (re-running on a schedule is how you regain some of the self-healing a profile gives you for free)
This is the same shell-script mechanism the Firefox-on-macOS managed-storage step uses in Method 1.
Pros and cons — platform scripts
Pros
No ADMX imports. One install script writes Brave, Firefox, and Comet force-install keys directly—skipping the whole template-import dance and its dependency gotchas.
One artifact set, all browsers. No per-browser profiles to build and assign; the scripts loop through every browser.
Works on mixed/unmanaged fleets. Handy where configuration-profile coverage is incomplete or you're deploying via an RMM alongside Intune.
Safe merge. Nudge's install script appends rather than overwrites, so it coexists with existing force-installed extensions.
Cons
Run-once, no self-healing. A platform script runs a single time after enrollment. If the registry value is wiped or drifts, nothing restores it. (Setting the macOS scripts to re-run on a schedule partly closes this gap.)
No automatic removal. Unassigning the script leaves everything it wrote in place. You'll need a separate teardown script to offboard cleanly.
No compliance reporting. Intune shows only that the script ran—not whether the resulting state is still correct across the fleet.
Ordering and elevation are on you. Scripts must run as system (HKLM); the Firefox configure script even exits silently if not elevated. Run order isn't guaranteed, so a fresh device can briefly have the key set before the install policy lands (it self-corrects).
You own the scripts. Updating extension IDs, signing, and maintenance fall to you rather than Microsoft's maintained policy definitions.
Verify the installation
Once installed and configured, users start showing as Connected on the Browser Extension settings page in Nudge. Discovery can take up to 72 hours. To check a single device manually:
Chrome, Edge, Brave, and Comet
Is it installed? Go to chrome://extensions and look for the Nudge Security extension. If it's missing, check the force-install list (see Troubleshooting).
Is the deployment key applied? Open the status page at chrome-extension://diaecjfdpohehjhliaephjnpnlmeajfa/options.html:
Configured → fully installed and working.
Waiting for User → still in the discovery process.
NO_DEPLOYMENT_KEY → something's wrong with the deployment policy.
Firefox
Is it installed? Go to about:addons and look for the Nudge Security browser extension. If it's missing, check the extension settings (see Troubleshooting).
Is the deployment key applied? In about:addons, find Nudge Security Browser Extension and click Preferences. You'll see the same three states as above.
Troubleshooting
Check the force-install policy. Go to chrome://policy and find ExtensionInstallForceList. If the extension is listed but not installed, restart the browser and try again. If it's not listed at all, check for policy conflicts below.
Resolve policy conflicts. Conflicts happen when ExtensionInstallForceList is set in two places—most often because both a configuration profile and a script are writing it. Pick one method, consolidate all force-installed extensions into a single entry, and remove duplicates.
Validate the deployment policy. At chrome://policy, scroll to the Nudge Security Browser Extension section and confirm the policy applied. If it didn't, recheck the value format and preference domain (profiles) or that the configure script ran as system in the 64-bit host (scripts).
Still stuck after working through this guide? Reach out through the Intercom chat in the bottom-right of your screen and we can assist.