Nudge Security’s browser extension normally determines the registered user automatically using a few methods (see: Browser extension user registration methods).

In some environments, you may want to force the extension to register as a specific known user by setting the registered-user policy value via your MDM solution.

This article explains how to do that, along with examples of how you might determine the correct email address at deployment time.

When should I use registered-user?

Use this method if:

You want to guarantee a consistent user association in environments where user detection is unreliable
Your devices are shared, kiosk-like, or heavily locked down
You want to pre-register the extension before the user ever signs in

Important notes before you begin

registered-user is attempted first before other registration methods
1. If registered-user is set, the extension will attempt to register using that value
2. It will fall back to other methods (like browser profile detection or authentication-session-based registration)
It applies to all browser profiles on the device
1. This policy is applied at the browser policy level, so it overrides registration for all profiles using that browser on that device
The email must be correct
1. The email must match the user’s primary email address in your workspace provider:
  1. Google Workspace
  2. Microsoft 365 / Entra ID
2. If the email does not match a valid user, the extension will attempt to fall back to other methods but will show the user as Not connected until registered
The extension will retry automatically
1. The extension checks policies periodically. If the user does not exist yet (or the value is corrected later), the extension will keep trying until registration succeeds

Step 1 — Set the deployment key (required)

Before the extension can register, it must know which Nudge Security tenant it belongs to.

This is done using the policy:

nudge-security-deployment-key

This is typically deployed via your MDM solution.

Step 2 — Set the registered-user policy

To force the extension to register as a specific user, set:

registered-user = user@yourcompany.com

Important: registered-user must be set at the same policy path/location as nudge-security-deployment-key

The exact policy location varies slightly depending on browser type. Below are examples for Chrome and Edge on macOS and Windows.

macOS example (Chrome + Edge)

On macOS, extension policies are typically delivered via a configuration profile (either .plist or .mobileconfig depending on your MDM solution) using a plist or mobileconfig payload.

Add registered-user in the same mcx_preference_settings dictionary as nudge-security-deployment-key

Example configuration profile snippet

<key>mcx_preference_settings</key>
<dict>
  <key>nudge-security-deployment-key</key>
  <string>NUDGE_EXTDK.88de14e0-c307-4e76-acce-a707f35df0b3.6aKMqcvsFJhVc2467k9oqmExrWTPzUxPYxnmjAXOlrBnKlzPZoTOMci3tJTbksZn</string>

  <key>registered-user</key>
  <string>user@yourcompany.com</string>
</dict>

Note: This example is shown in the Chrome and Edge extension policy sections. Other browsers may require different policy domains.

Windows example (Chrome + Edge)

On Windows, extension policies are typically delivered using registry-based browser policies under:

HKLM:\\Software\\Policies\\<Vendor>\\<Browser>\\3rdparty\\Extensions\\<extensionId>\\policy

Add registered-user at the same level as nudge-security-deployment-key

Example PowerShell script (Chrome + Edge)

$deploymentKey = "NUDGE_EXTDK.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
$registeredUser = "user@yourcompany.com"

$extensionId = "diaecjfdpohehjhliaephjnpnlmeajfa"

$browsers = @(
    @{
        Name = "Chrome"
        Vendor = "Google"
    },
    @{
        Name = "Edge"
        Vendor = "Microsoft"
    }
)

foreach ($browser in $browsers)
{
    $browserPath = "$( $browser.Vendor )\\$( $browser.Name )"
    $policyPath = "HKLM:\\Software\\Policies\\$browserPath\\3rdparty\\Extensions\\$extensionId>\\policy"

    if (-not (Test-Path $policyPath)) {
        New-Item -Path $policyPath -Force | Out-Null
    }

    # Set the deployment key
    New-ItemProperty -Path $policyPath -Name "nudge-security-deployment-key" `
        -PropertyType String -Value $deploymentKey -Force | Out-Null

    # Force the registered user
    New-ItemProperty -Path $policyPath -Name "registered-user" `
        -PropertyType String -Value $registeredUser -Force | Out-Null
}

How do I determine what email to set?

Different environments have different identity sources, and there is no universal, reliable way to determine the correct email address across all Windows and macOS deployments.

In general, the best option is to use the email address that represents the currently signed-in user for the device.

Recommended approach

If your MDM supports per-device or per-user variables (some do), use those values to populate the policy.

For example:

A “user principal name” (UPN)
The MDM’s notion of the assigned user
A directory-backed user email field

Windows examples of potential options

Option 1 — Use UPN from the current user session

In many Microsoft environments, this returns the signed-in user’s UPN:

$registeredUser = (whoami /upn).Trim()

If this returns a valid email address, it is often the best and simplest option.

Option 2 — Use the username + a known domain (simple fallback)

If your organization has a consistent email format (for example, first.last@company.com), you may be able to build the email address from the signed-in username.

$username = $env:USERNAME
$registeredUser = "$username@yourcompany.com"

This only works if your Windows username matches your email naming convention.

macOS examples of potential options

Option 1 — Use a known mapping rule

If your macOS shortname reliably maps to email (for example

jdoe → jdoe@yourcompany.com), you can generate the email:

loggedInUser=$(stat -f "%Su" /dev/console)
registeredUser="${loggedInUser}@yourcompany.com"

This only works if your macOS shortname matches your email naming convention.

Option 2 — Use your identity tooling

Many organizations deploy identity tools on macOS (for example, tools that integrate with Google Workspace, Microsoft, Okta, etc.).

If you already use one of these tools to determine the signed-in user, the best approach is often to use that tool’s output to populate the registered-user policy value.

Because identity setups vary widely, we recommend validating your chosen method on a small test group before rolling out broadly.

Troubleshooting

The extension shows the user as “Not connected”

This typically means the extension cannot successfully register the user using the value provided in registered-user.

Check the following:

Confirm the email is correct
- The email must match the user’s primary email in Google Workspace or Microsoft 365 / Entra ID.
Confirm the policy is being applied
- macOS: confirm the configuration profile is installed and contains the key
- Windows: confirm the registry value exists at the correct browser policy path
Confirm the value is set for the correct browser
- Policies are browser-specific. If you deploy the value for Chrome, it will not automatically apply to Edge, Firefox, etc.
Confirm the user exists
- If the user account does not exist yet in Nudge Security, the extension will keep retrying until it does.