Deploy the browser extension

Before you begin

Use the Deployment Center in elba for the current configuration values, installation links, and downloadable artifacts for your workspace. Do not reuse identifiers, policy values, or scripts copied from another environment or an earlier rollout.

You will need:

• Access to Browser Security settings in elba.
• Administrative access to the browser or device-management platform you plan to use.
• A defined pilot group and target device scope.
• A communication plan for any users who must sign in or install manually.

Choose a deployment method

The methods shown in elba vary by browser and platform. Select a browser in the Deployment Center to see the options and exact values available for it.

Standard rollout process

1. In elba, open Browser Security settings and select the deployment view.
2. Choose the target browser and deployment method.
3. Copy the displayed values or download the provided artifacts.
4. Apply them in your browser, device-management, or RMM platform.
5. Assign the policy to the pilot group and trigger a policy refresh where appropriate.
6. Restart or relaunch the browser if the management platform requires it.
7. Confirm the policy and extension state on a pilot device.
8. Ask the pilot user to sign in to the extension.
9. Verify the user's extension status in elba before expanding the assignment.

Private and incognito browsing

Private-window coverage is separate from installing, force-installing, or enrolling the extension. The Deployment status in elba reports normal-mode enrollment and the existing heartbeat window only. It does not reveal browser private-mode settings, so an active heartbeat or Enrolled status is never proof of private-mode protection.

Use the browser-specific state below. Administrator setup required, Unobservable by elba, and Unsupported are different outcomes; do not interpret any of them as protected.

Chrome

• Current state — Administrator policy and user action required. On managed ChromeOS 114 or later, MandatoryExtensionsForIncognitoNavigation can prevent navigation until the user explicitly allows the Elba extension. The policy does not silently grant access, and desktop Chrome does not currently support this required-extension path.
• Administrator action. On supported ChromeOS, add the Elba extension ID to the required-extension policy. Where consent cannot provide reliable coverage, disabling Incognito with IncognitoModeAvailability is a separate administrator choice.
• What elba can verify — Unobservable by elba. Validate policy and Incognito access on a managed pilot device.

Edge

• Current state — Administrator policy and user action required. On Edge 139 or later for Windows and macOS, MandatoryExtensionsForInPrivateNavigation can prevent navigation until the user explicitly allows the Elba extension. It does not silently grant access.
• Administrator action. Add the Elba extension ID to the required-extension policy, or disable InPrivate separately with InPrivateModeAvailability.
• What elba can verify — Unobservable by elba. Validate policy and InPrivate access on a managed pilot device.

Firefox

• Current state — Managed policy available. Firefox 136 and Firefox ESR 128.8 or later support "private_browsing": true in the extension's ExtensionSettings entry.
• Administrator action. Add the setting to the Elba extension entry using the Firefox ExtensionSettings policy. Disabling Private Browsing is a separate PrivateBrowsingModeAvailability choice.
• What elba can verify — Unobservable by elba. Validate the applied policy in about:policies on a managed pilot device.

Safari

• Current state — Unsupported for the current Elba paths. The managed Elba declaration uses PrivateBrowsing: AlwaysOff, and the manual validation path does not support Private Browsing. Apple's platform exposes a Safari extension-management control, but the current Elba deployment does not enable it.
• Administrator action. Keep Private Browsing classified as unsupported. Do not change the generated Elba declaration or claim coverage from a standard-browsing installation.
• What elba can verify. There is no protected private-mode state to verify in the current Elba Safari paths.

Method-specific guidance

Safari sign-in prerequisite

Google Workspace and Microsoft 365 sign-in use applications managed by elba. If your workspace uses Okta, update the existing Okta OIDC application before assigning Safari: keep https://login.eu.elba.security/auth-verify/okta and add https://login.eu.elba.security/api/oauth/extension/callback under Sign-in redirect URIs. The same Safari URI is displayed in the Deployment Center. Do not create a second Okta application or replace the existing client credentials.

Complete one Safari sign-in with a pilot user before broad MDM assignment. A package can be correctly signed and installed while the identity provider still rejects an unregistered redirect URI.

Google Admin

1. Open the Chrome application and extension management area in Google Admin.
2. Select the target organizational unit.
3. Add the extension using the values displayed in elba.
4. Set the installation policy for the target users or devices.
5. Apply the optional advanced policy value only if it is part of your browser-management model.
6. Refresh policy and validate the extension on a managed device.

Microsoft Intune

1. Create or update the browser policy for the target Windows devices.
2. Add the setting described in the elba Deployment Center.
3. Paste the generated name, configuration location, and value exactly as displayed.
4. Assign the policy to the pilot device group and trigger a sync.
5. Confirm that the browser reports the policy and installs the extension.

Group Policy

1. Open Group Policy Management and edit the target computer policy.
2. Apply the browser extension policy values generated by elba.
3. Preserve existing settings for other managed extensions when merging policy values.
4. Wait for the normal policy refresh or trigger one according to your standard process.
5. Relaunch the browser and validate the resulting policy state.

macOS MDM

For Chrome, create a macOS configuration profile using the managed preference domain and values displayed in elba.

For Safari 26 or later on macOS 26 or later:

Production Safari deployment is supported only through MDM. The host app has no built-in updater, so MDM must deploy every newly approved signed package version.

The Deployment Center shows both the latest pilot-download alias and the approved immutable elba-<version>.pkg URL. Pin the immutable URL in the MDM application record, verify it against the published SHA-256 checksum linked from the Deployment Center, and update the pinned URL deliberately for each approved rollout.

1. Download and deploy the signed, notarized elba Safari package shown in the Deployment Center. The package installs the host application and embedded Safari extension in /Applications.
2. Confirm that the host application is installed before assigning the Safari declarations. Safari cannot apply settings for an extension that has not yet been registered by its host application.
3. Create a user-channel declarative management configuration with type com.apple.configuration.safari.extensions.settings using the configuration JSON displayed in elba. Use the exact managed extension identifier, including the Apple team identifier in parentheses.
4. In the same channel, create the displayed com.apple.activation.simple declaration. Its StandardConfigurations value references the configuration from the previous step; the configuration does not apply without this activation.
5. Assign both declarations to the pilot Mac group and wait for device check-in.
6. Confirm that the extension is registered, always enabled, allowed on all website domains, and disabled in Private Browsing. Ask the user to open the extension in Safari, select Sign in, and complete authentication in the dedicated Safari tab. The containing app installs and registers the extension but does not own the sign-in session.

The generated ServerToken values identify the exact configuration and activation revisions. If you customize declaration content, regenerate both JSON declarations and synchronize them together; do not retain a token from an earlier payload.

Do not rename, repackage, or modify the downloaded package. Doing so invalidates its code signature and notarization.

RMM

1. Download the installation script from elba.
2. Run it through your RMM platform with the administrative context required by that platform.
3. Keep the downloaded script unchanged so its installation and verification behavior remains intact.
4. Retain the matching rollback script with the deployment record.
5. Review the script result and validate the extension on a pilot endpoint.

Manual installation

Use manual installation for a pilot or when centralized browser management is unavailable. Share the installation link shown in elba, then ask the user to install the extension and sign in. Track completion from the deployment view and send a reminder if needed.

For Safari, manual installation is limited to pilot validation and is not a supported production deployment. Ask the pilot user to download and run the notarized .pkg, open Elba Browser Extension once so macOS registers the embedded extension, then enable it in Safari > Settings > Extensions. The user must allow access to all websites for complete Browser Security coverage. After that, they open the Safari extension, select Sign in, and complete authentication in the dedicated Safari tab. The host app does not auto-update, so reinstall every approved package version for the duration of the pilot. Private Browsing remains unsupported for the managed and manual validation paths.

Validate the deployment

On each representative platform, confirm that:

• The browser's policy page shows the expected managed extension policy where applicable.
• On Safari, the host application and embedded extension have valid signatures and the extension appears in Safari's extension settings.
• The extension is installed and managed as intended.
• Existing policies for unrelated extensions remain intact.
• The user can open the extension and sign in successfully.
• The user's extension status appears correctly in elba.
• The Browser Security capabilities you intend to use behave as expected in your test scope.

If a status does not update immediately, refresh device policy, relaunch the browser, and confirm that the extension has an active connection to elba.

Roll back safely

Plan rollback before broad assignment.

1. Remove or unassign the browser or device policy from the affected group.
2. For Safari, remove the activation declaration first, then the declarative management configuration, before uninstalling the elba host application through your fleet-management workflow.
3. For script-based deployment, use the matching rollback artifact supplied by elba.
4. Remove only the elba extension entry when the policy also manages other extensions.
5. Refresh policy and relaunch the browser.
6. Confirm that the managed policy and extension state match the intended rollback outcome.

For product context, read Browser extension and Browser extension capabilities. For unresolved installation or sign-in issues, continue to Troubleshooting.