PROSFINITYBrowser Security

Security platform operational

Defend every browser.
Control every risk.

Monitor threats, enforce policy and protect every managed browser from one security console.

24/7Threat visibility
UnifiedPolicy response

✓ Enterprise-grade browser protection

ViewGuard Browser Detection and Response

Secure access

Welcome back

Enter your credentials to access the BDR security console.

Security verification helps protect your account from automated sign-in attempts.

or Sign in with company SSO

◆ Protected by encrypted authentication

ViewGuard Browser Detection and Response

PROSFINITY

ViewGuard BDR Browser Security
Signed in user Viewer

Security Overview

Home

WorkspaceLoading…
Checking API
Total Devices0Saved endpoints
Online0Checked in within 15 min
Offline0Needs attention
Coverage0%Online fleet
Policies0Tenant policies
Alerts Today0Since midnight
Blocked Today0Prevented actions
Pending Events0Awaiting completion

Last 24 Hours · HKT

Security Activity

Monitor · Block

Fleet

Device Health

Policy Analytics

Policy Effectiveness

Alert hits

Alert Queue

Status Breakdown

Loading
0 visible alerts
0 open
0 investigating
0 acknowledged
0 closed

Policy

Mode Distribution

Loading

DLP Analytics

Top Hit Rules

Loading analytics

DLP Analytics

Top Egress Domains

Browser Context

Extension Health

Alert Queue

Recent Critical Events

Identity Provider

Directory Sync · SCIM 2.0

Loading

Provision, update and disable tenant users from Microsoft Entra ID, Okta or another SCIM 2.0 provider. The bearer token is shown once only.

Select an alert to inspect evidence.

Policy

Create Policy

Ready
Use Domain / URL for a specific website, or AI Web Tool for built-in AI destinations. If neither is set, the policy applies to any external website that matches the other conditions.

Conditions

Match when all selected conditions are true

Examples: Domain / URL = chat.openai.com, Domain / URL = https://example.com/upload, AI Web Tool = ChatGPT.

Policy

Rules

Loading policies

Identity Source

Users

Loading users

Assign telemetry user IDs and devices to real company people. Managed groups and roles are used by policy scope matching.

Bulk Mapping

Excel Import Template

Download the template, fill only the fields you have, then upload the saved CSV to match people with extension device IDs.

owner_name owner_email department role device_id notes active
Template fields can be left blank.

Browser Context

Extension Inventory

Loading inventory

Inventory shows the latest Chrome endpoint snapshot per device, user, and profile. New snapshots replace older rows in this view; deleting a row clears the stored snapshots for that endpoint, not the actual Chrome extensions.

Notifications

Email Alerts

Delivery control for newly created HIGH and MEDIUM security alerts.

Loading status
Delivery service Checking… Azure Communication Services
Recipients Checking… Tenant-level setting
Active delivery Checking… Required before delivery
Alert scope HIGH + MEDIUM LOW, INFO and ordinary events are excluded

Recipient list

Add delivery address

…
Loading email alert status

Checking the saved recipient and delivery configuration.

We will send a verification link valid for 24 hours. Delivery starts only after the address is verified.

Setup flow

How email delivery works

  1. 1
    Enter a recipient

    This is separate from the optional portal account email.

  2. 2
    Verify the address

    Open the ACS email link within 24 hours.

  3. 3
    Add as many as needed

    Each verified address independently receives new HIGH and MEDIUM alerts.

Last portal check Not checked yet

Portal Admin

Portal Users

Loading settings

Manage local portal accounts for this dashboard. Browser extension ingestion and policy sync are separate from portal login.

Total users
0
Active users
0
Administrators
0

Access

Portal Users

Loading users

Access

Add Portal User

Create a local account with a temporary password.

Account Security

Reset user password?

Set a temporary password. The user must change it after their next sign-in.

Portal user
Existing sessions will be revoked and the user must choose a new password after signing in. Share the temporary password through an approved secure channel; it is never written to the audit log.

Identity Provider

OpenID Connect

Loading SSO settings

Configure a tenant IdP such as Keycloak, Microsoft Entra ID or Okta. Enforce SSO only after testing and assigning a protected local break-glass Admin.

Test SSO Login

Platform Administration

Tenant Management

Admin only

Create and manage customer tenants and their initial Super Admin accounts. This page is restricted to tenant_demo Admins and Super Admins.

Total tenants
0
Active tenants
0
Devices
0

Tenant Directory

Manage Existing Tenants

Rename, license or change access

Disabling a tenant blocks its access without deleting its users, policies, or history.

Platform Administration

Add Tenant

Create the customer workspace and its first Super Admin in one step.

An account activation email will be sent to this address after the tenant and initial Super Admin are created. The temporary password is not included in the email.

Subscription

License Usage

Loading usage

License usage counts unique devices seen within the last 30 days. Online is tracked separately using a 30-minute check-in window; exceeding the assigned limit raises a warning without interrupting endpoint protection.

Account Security

Two-Factor Authentication

Protect your account with a TOTP authenticator app. There is no SMS or recurring fee.

Authenticator 2FA

Not enabled

Use a time-based one-time password from your authenticator app when signing in. No email or SMS code is sent.

Private enrollment: this QR code, secret and recovery codes belong only to you. Administrators cannot enroll 2FA for another user.
Authenticator QR code

Step 1

Scan with your authenticator app

Google Authenticator, Microsoft Authenticator, 1Password and other TOTP apps are supported.

Manual setup key

Step 2

Enter the current 6-digit code


              


              

                
01
Self enrollment
Only you can scan and confirm your authenticator.

                
02
Admin recovery
Admins can disable 2FA, never enable it for you.

                
03
Recovery codes
One-time codes provide an emergency sign-in path.

              

            

          

        


        

          

            

              

                
Audit

                
Portal Activity

              

              

                Loading audit
                
              

            

            

              Review administrative changes, policy edits, extension package activity, and operator actions in one dedicated audit view.
            

            

          

        


        

          

            

              

                
Extension Security

                
Browser Extension Management

              

              Loading security
            

            

              Choose a browser to manage its developer package and company deployment. Each browser keeps its own extension identity, release files, and deployment settings.
            

            

              
              
              
            

          


          

            

              
Selected browser
Google Chrome

              

                
                
              

            


          

          

            

              

                

                  
Token

                  
Generate Token

                

              

              

                
                
                
                

              

            


            

              

                

                  
Chrome

                  
Build Extension

                

              

              

                
                
                
                
                
                

                  Set a default token below to build without choosing every time. The extension generates its endpoint ID and Portal maps that endpoint to the assigned managed user from inventory.
                

                
                

                

              

            

          


          

            

              

                
Tokens

                
Extension Tokens

              

              Loading tokens
            

            

          

          


          

            

              

                
Private Distribution

                
Force deploy ViewGuard to managed browsers

                
Generate a tenant-specific ZIP with two explicit controls: force installation and tenant configuration. Employees receive the signed CRX silently; the selected token assigns every deployed browser to the correct tenant.

              

              

                Signed CRX→Customer policy→Managed Chrome
              

            

            

              

                
Release
Self-hosted package
Private

                

                  
                  
                  
Provided by Prosfinity from the protected offline signing key. Customer IT copies this value; it is not tenant-generated or customer-supplied.

                  
                  
                  
                  
The tenant default token is selected automatically. Only active reusable tokens are shown.

                  
                  
                  
                  

                

              

              

                
Customer IT handoff
What the tenant ZIP is for

                
This ZIP is a confidential, tenant-specific policy pack—not a universal one-click installer. Customer IT chooses one managed-Chrome method below and uses only the matching artifact. The same pack must never be shared with another tenant.

                

                  
Google Admin Console · viewguard-google-admin-…jsonUpload the JSON under Policy for extensions, or paste its complete contents if Upload is unavailable. It supplies only apiBaseUrl and the tenant apiToken; OU/group, custom extension, Extension ID, update manifest URL, Force install and Save remain manual Admin Console steps.

                  
Windows GPO · viewguard-chrome-….regUse the registry file as the exact Chrome policy source. Customer IT should translate or push those HKLM values through its managed Group Policy process; it is not a GPO backup and employees should not double-click it.

                  
Windows Intune · viewguard-chrome-….regUse the registry file as the authoritative values for a customer-approved PowerShell, Win32 app or remediation deployment. A .reg file cannot be imported directly as an Intune configuration profile.

                  
macOS MDM · viewguard-chrome-….mobileconfigUpload and assign the configuration profile through the customer's MDM at device/system scope. Pilot it first; do not ask employees to install the profile manually.

                  
deployment-pack.json and README.txtReference metadata, release URLs, validation checks and rollback notes for customer IT. deployment-pack.json is not uploaded to Google Admin, Intune or MDM.

                

                
Follow the complete method-specific steps in Documentation: Windows GPO, Windows Intune, macOS MDM, or Google Admin Console.

                
Signing key is never generated or stored in Portal. Sign every CRX release offline with the same protected key to preserve the Extension ID.

              

            


            

              

                

                  
Installation guidelines

                  
Deploy Google Chrome across the company

                

                Customer IT steps
              

              
Generate the tenant deployment ZIP above first. Give it only to the customer IT administrator: it contains the selected tenant configuration and must not be shared between customers.


              

                

                  

                    
                      
                    
                    
Windows
Intune or Active Directory GPO

                  

                  
    
                    
  1. 01
    Confirm Chrome is managed
    Enroll the pilot devices in Microsoft Intune, Active Directory Group Policy, or Chrome Enterprise Core. Verify chrome://management says the browser is managed.
    2. 
                    
  2. 02
    Apply force installation
    Import the Windows registry policy from the tenant ZIP, or add its Extension ID and update manifest URL to ExtensionInstallForcelist / ExtensionSettings.
    3. 
                    
  3. 03
    Apply the tenant configuration
    Deploy the included extension managed-policy registry values for apiBaseUrl and apiToken. Use only the pack generated for this tenant.
    4. 
                    
  4. 04
    Sync a pilot group
    Assign both policies to the same user or device scope. On a pilot device, open chrome://policy, select Reload policies, then fully quit and reopen Chrome.
    5. 
                    
  5. 05
    Verify before broad rollout
    Confirm the extension is force-installed and cannot be disabled, then check API Connected, the expected tenant, policy sync, Device ID, and Online inventory in Portal.
    6. 
                  

                


                

                  

                    
                      
                    
                    
macOS
MDM or Chrome Enterprise Core

                  

                  
    
                    
  1. 01
    Confirm Chrome is managed
    Enroll the pilot Mac through the customer's MDM or Chrome Enterprise Core. Verify the device appears under Managed browsers and chrome://management.
    2. 
                    
  2. 02
    Install the tenant profile
    Deploy the included .mobileconfig through MDM. For a pilot Mac only, open it in System Settings → General → Device Management, then choose Install or Replace.
    3. 
                    
  3. 03
    Approve the system prompt
    Enter a local administrator password when macOS requests it. A downloaded profile is not installed until it appears in the Device Management profile list.
    4. 
                    
  4. 04
    Reload Chrome policy
    Open chrome://policy, select Reload policies, and confirm the production Extension ID is valid. Fully quit Google Chrome—not just its window—then reopen it.
    5. 
                    
  5. 05
    Verify tenant connectivity
    Confirm the extension remains installed after restart, cannot be disabled, and shows API Connected, the correct tenant, policy synced, a Device ID, and an Online Portal inventory record.
    6. 
                  

                

              


              

                
Required verification
Do not mark deployment complete until all checks pass

                

                  Production Extension IDForce installedCannot disableTenant correctHTTP 200Policy syncedInventory onlineTest alert received
                

              


              

                Troubleshooting: installation, token, or policy is not working
                

                  
Extension is missing after restartCheck chrome://policy for blocked or invalid force-install entries. Remove conflicting local test profiles and confirm the CRX plus update manifest return HTTP 200.

                  
HTTP 401 / token missing / tenant unknownThe CRX is installed but the tenant managed policy is absent. Reapply the same tenant pack and verify apiBaseUrl and apiToken appear under the production extension policy.

                  
Policy shows pending or never syncedReload policies, fully quit Chrome, reopen it, and confirm the force-install and tenant configuration target the same browser, organizational unit, and device or user scope.

                  
Portal has no alertFirst confirm the production Device ID is Online, then trigger a supported test action and match that exact Device ID in Inventory, Recent Activity, and Alert Detail.

                

              

            

          

          

        


        

          

            

              
Portal user guide

              Documentation home
              Network & Firewall Allowlist
              Overview
              Alerts
              Policies
              Users · Directory & Import
              Inventory
              General Settings
              Company SSO · OIDC
              Multi Authentication · 2FA
              Audit
              Data Retention
              Extension Security
              
Deployment guides

              Chrome Installation Guideline
              Windows GPO
              Windows Intune
              macOS MDM
              Google Admin Console
              Edge Installation Guideline
              Windows GPO
              Windows Intune
              macOS MDM
              Firefox Installation Guideline
              Windows GPO
              Windows Intune
              macOS MDM
              Verification & troubleshooting
            


            

              

                
ViewGuard documentation

                
Portal User Guide

                
Use these guides to operate every item in the Portal sidebar. Each feature has its own page with purpose, access requirements, operating steps, expected results, and safety notes.

                

                  MonitorOverview, Alerts, Policies and Inventory
                  Manage accessUsers, imports, accounts and 2FA
                  Configure company SSOOIDC onboarding, testing, enforcement and recovery
                  Understand retentionLog lifetimes, record limits and data excluded from automatic deletion
                  Manage extensionTokens, builds and tenant deployment packs
                  Prepare the networkFirewall, proxy and TLS requirements
                  Install browser extensionsSeparate Chrome, Edge and Firefox guides
                

              


              

                
Network · Security · IT

                
Firewall and proxy allowlist

                
Permit the minimum outbound destinations below before deploying ViewGuard. Configure rules by FQDN, protocol and port; do not pin cloud or CDN services to resolved IP addresses.


                
Required destinations

                

                  

                    
DestinationProtocol / portRequired byPurpose

                    
                      
bdr.prosfinity.comHTTPS / TCP 443Portal browsersPortal sign-in, application content, API requests and audit or administration workflows.

                      
bdr.prosfinity.comHTTPS / TCP 443Chrome, Edge and Firefox extensionsTenant enrolment, policy retrieval, inventory check-in, telemetry and alert delivery.

                      
bdr.prosfinity.comHTTPS / TCP 443Managed browsers and deployment systemsPrivate CRX, XPI and update-manifest download paths under /extension/.

                      
challenges.cloudflare.comHTTPS / TCP 443Portal sign-in browsersCloudflare Turnstile verification required by the interactive login page.

                    
                  

                


                
Optional administration destinations

                

                  

                    
DestinationProtocol / portWhen neededPurpose

                    
                      
Customer IdP hostnameHTTPS / TCP 443Company SSO is enabledOIDC discovery, authorisation, token and signing-key traffic. Use the exact issuer hostname configured for the tenant.

                      
Customer SCIM client → bdr.prosfinity.comHTTPS / TCP 443Directory Sync is enabledOutbound SCIM provisioning from the customer identity platform to the tenant-specific BDR SCIM endpoint.

                    
                  

                


                
Proxy and TLS requirements

                
    
                  
  • Only outbound, client-initiated traffic is required. Do not open inbound firewall ports to employee devices.
    • 
                  
  • Preserve TLS 1.2 or later, SNI and certificate validation. Pilot TLS inspection first; exclude bdr.prosfinity.com if extension certificate validation or update downloads fail.
    • 
                  
  • Authenticated proxies must permit the managed browser and extension context without an interactive proxy prompt.
    • 
                  
  • Use the exact FQDNs above. A broad *.prosfinity.com rule is not required.
    • 
                

                
Separate controlsA firewall allow rule only permits BDR service connectivity. It does not add a website to a DLP policy allowlist or bypass protection rules.


                
Validation checklist

                
    
                  
  1. Test Portal access.Open https://bdr.prosfinity.com/dashboard, complete Turnstile and sign in from the target user network.
    2. 
                  
  2. Test service health.Confirm https://bdr.prosfinity.com/health responds without a proxy block page or certificate warning.
    3. 
                  
  3. Test a pilot browser.Force-install the extension, apply apiBaseUrl and apiToken, then confirm the browser appears in Inventory with a recent check-in.
    4. 
                  
  4. Test updates.Confirm the browser can retrieve the applicable update manifest and package path under /extension/.
    5. 
                  
  5. Review network logs.Resolve denied requests, TLS interception errors and proxy authentication prompts before wider rollout.
    6. 
                

              


              

                
Overview
Read the security posture at a glance

                
  1. Check fleet health.Review Total Devices, Online, Offline and Coverage. Investigate offline devices before treating alert counts as complete.
  2. Review activity.Use Security Activity, Device Health and Policy Effectiveness to identify changes, noisy rules and coverage gaps.
  3. Open the queue.Status Breakdown summarises Open, Investigating, Acknowledged and Closed alerts. Select Alerts in the sidebar for investigation.
  4. Refresh when needed.Select Refresh after a deployment, policy edit or investigation update to request the latest Portal data.

                
Interpretation noteOverview is a summary, not an investigation record. Confirm important findings in Alerts, Inventory and Audit.

              


              

                
Alerts
Investigate and resolve security events

                
  1. Filter the queue.Use status tabs, search and available filters to reduce the queue. Saved filters can preserve frequently used views.
  2. Open Alert Detail.Check rule, severity, event time, user, device ID, URL or destination, evidence and enforcement result before changing status.
  3. Move through the workflow.Use Open for untriaged work, Investigating while gathering evidence, Acknowledged when accepted or assigned, and Closed only after a documented outcome.
  4. Delete only after closure.A Portal Admin can permanently delete Closed alerts individually from Alert Detail or select multiple records in the Closed queue and use Bulk Delete. Deletion also removes analyst notes and response actions and cannot be undone. Open, Investigating and Acknowledged alerts cannot be deleted.
  5. Use bulk actions carefully.Select only visible alerts you have reviewed. A bulk status change or bulk deletion affects every selected record.
  6. Export when authorised.Export CSV for approved analysis or reporting. Alert exports may contain customer and browsing context and must be handled as sensitive data.

              


              

                
Policies
Create, test and maintain DLP policy

                
  1. Choose a clear rule name and scope.Define the users, groups, destinations or browser activity the rule covers so another operator can audit its intent.
  2. Select the operating mode.Use Observe to collect evidence, Alert to notify without stopping the action, and Block only after pilot results show acceptable false-positive risk.
  3. Configure conditions.Add the supported detection and destination conditions shown by the form. Keep rules focused instead of combining unrelated risks.
  4. Save and verify sync.Confirm the policy appears in the list, then verify a pilot managed browser receives the updated policy before wider rollout.
  5. Review outcomes.Use Policy Effectiveness and Alerts to tune noisy rules. Record material edits in the change process and use Audit to verify who changed what.

                
Safe rolloutStart new or materially changed rules in Observe or Alert. Move to Block only with an approved test result and rollback plan.

              


              

                
Users
Maintain the managed-user directory

                
  1. Use Directory for current records.Search and review the identities used for assignment and reporting. Portal login accounts are managed separately under General Settings.
  2. Assign devices deliberately.Match the browser Device ID in Inventory before assigning it to a managed user; do not rely only on a display name.
  3. Prepare an import.Open Users → Import, download the current template, preserve its column names and add one supported user record per row.
  4. Validate before committing.Review rejected, duplicate or malformed rows and correct the source file. Confirm the tenant and expected row count before import.
  5. Verify the result.Return to Directory and confirm the imported users and assignments. Never use this page to create Portal sign-in credentials.

              


              

                
Inventory
Confirm managed browser coverage

                
  1. Find the endpoint.Use the stable Device ID to correlate a browser with Alerts and Recent Activity.
  2. Check connectivity.Online indicates a recent check-in; Offline means the browser has not checked in within the displayed health window.
  3. Confirm tenant and user.Validate that the endpoint belongs to the expected tenant and, where used, is assigned to the correct managed user.
  4. Troubleshoot missing devices.Check force installation, managed apiBaseUrl/apiToken policy, Chrome policy errors, browser restart and API connectivity.
  5. Do not infer deletion.An offline or absent endpoint needs investigation; it does not by itself prove that the extension was removed.

              


              

                
Settings · General · Admin only
Create and manage Portal accounts

                
  1. Understand the hierarchy.The first account created for a tenant is its Super Admin. A Super Admin can manage Admins and Viewers, but cannot control another Super Admin. An Admin has tenant administration access and can manage Viewers, but cannot control Admin or Super Admin accounts.
  2. Create the account.Enter username, display name, role and a temporary password. Viewer is read-oriented. Only a Super Admin can create or promote an Admin; Super Admin cannot be assigned from this form.
  3. Deliver access securely.Send the username and temporary password through an approved channel and require the user to set up 2FA immediately.
  4. Manage existing users.Review role and status before disabling 2FA or changing an account. Same-level and higher-level accounts are protected by the API as well as the Portal UI.
  5. Handle 2FA recovery.A Super Admin can disable an Admin or Viewer's 2FA; an Admin can disable a Viewer's 2FA after verifying identity. Neither can control a same-level or higher-level account. Only the account owner can enroll 2FA again.
  6. Verify in Audit.Confirm account and authentication administration appears in the Audit page.

              


              

                
IdP · OpenID Connect · Admin only
Company SSO · OpenID Connect

                
Use this runbook to onboard a customer IdP, validate the complete sign-in flow, and enable SSO enforcement without locking administrators out. Company SSO protects Portal access only; browser extension deployment tokens remain separate.


                
Customer information required

                
    
                  
  • Issuer URL matching the IdP discovery document exactly.
    • 
                  
  • OIDC Client ID and Client Secret, transferred through an approved secret channel.
    • 
                  
  • The Portal Callback URL registered as an allowed redirect URI in the IdP application.
    • 
                  
  • A non-production test user assigned to the application and a named customer IdP owner.
    • 
                  
  • Default JIT role approval. Use Viewer unless elevated access is explicitly approved.
    • 
                

                
Protect the secretNever place the Client Secret in tickets, chat, screenshots, or documentation. The Portal encrypts the saved value and does not display it again.


                
Initial setup and connection test

                
    
                  
  1. Create the customer OIDC application.Customer IT creates the app, assigns the test user, and registers the exact Callback URL displayed under IdP → OpenID Connect.
    2. 
                  
  2. Save the tenant configuration.Enter Issuer URL, Client ID and Client Secret; select Viewer as the default JIT role. Keep Enable SSO and Enforce SSO off during initial configuration.
    3. 
                  
  3. Run Test Connection.Confirm Connection verified. This checks discovery, issuer, authorization endpoint, token endpoint and signing keys; it does not prove that a real user can sign in.
    4. 
                  
  4. Retest after changes.Changing Issuer, Client ID or Client Secret invalidates the previous result. Save and run Test Connection again.
    5. 
                


                
End-to-end SSO validation

                
    
                  
  1. Enable company SSO.After Test Connection succeeds, enable SSO but leave Enforce SSO off so local password access remains available.
    2. 
                  
  2. Run Test SSO Login.Sign in at the customer IdP with the assigned test user and confirm the browser returns to the correct BDR tenant.
    3. 
                  
  3. Verify JIT provisioning.Confirm the user is active, bound to OIDC, belongs to the correct tenant, has the approved role, and a repeat login does not create a duplicate.
    4. 
                  
  4. Check Audit.Confirm successful and controlled failed attempts appear as SSO login events. Use Audit → Export CSV for authorised evidence sharing.
    5. 
                


                
Safely enable Enforce SSO

                
    
                  
  1. Prepare a break-glass Admin.Select a dedicated active local-password Admin with tested 2FA. Store and control the emergency credential according to the customer access procedure.
    2. 
                  
  2. Test emergency access.In a private browser window, verify password plus 2FA before selecting that account in Company SSO.
    3. 
                  
  3. Enable enforcement.Select the verified break-glass Admin, enable Enforce SSO, review the confirmation, and save.
    4. 
                  
  4. Validate both paths.Confirm a normal local user's password login is blocked and directed to SSO, while the break-glass Admin can still sign in with password and 2FA.
    5. 
                

                
Protected emergency accountWhile enforcement is active, the selected break-glass Admin cannot have 2FA disabled, be downgraded, deactivated, or deleted. Disable enforcement or select another eligible account first.


                
Go-live checklist

                
    
                  
  • Production Callback URL is registered and Test Connection succeeds.
    • 
                  
  • A real assigned test user completes SSO and receives the correct tenant and role.
    • 
                  
  • Repeat login reuses the same identity; success and failure events appear in Audit.
    • 
                  
  • The local break-glass Admin is active, Admin, and protected by tested 2FA.
    • 
                  
  • Password blocking and emergency access are both tested before go-live approval.
    • 
                  
  • The customer IdP owner and Client Secret rotation or expiry date are recorded.
    • 
                


                
SCIM lifecycle provisioning

                
    
                  
  1. Open Directory Sync.Go to IdP → Directory Sync and copy the tenant-specific SCIM Base URL. Production URLs use https://bdr.prosfinity.com/scim/v2/<tenant-id>.
    2. 
                  
  2. Generate the bearer token.Give each token a purpose-specific name, choose an optional expiry, select Generate Token and copy it immediately. It is displayed once only. Each tenant can keep at most two active tokens.
    3. 
                  
  3. Configure the IdP.Enter the exact SCIM Base URL and bearer token in Microsoft Entra ID, Okta, or another SCIM 2.0 provider. Enable user provisioning, updates, and deactivation.
    4. 
                  
  4. Validate lifecycle changes.Provision a test user, update an attribute, then deactivate the user. Confirm the same tenant user is created, updated, and disabled, and review the matching SCIM events in Audit.
    5. 
                  
  5. Rotate or revoke safely.For zero-downtime rotation, generate a second token, update and test the IdP, then independently revoke the old token. Revoked history remains visible and access stops immediately.
    6. 
                

                
OIDC and SCIM work togetherOIDC provides interactive sign-in and JIT identity binding. SCIM provides directory-driven user creation, updates, and deactivation. SCIM does not replace Extension device pairing.


                
Failure and recovery

                
    
                  
  1. Confirm the scope.Test with a known assigned user and review Audit before changing production configuration.
    2. 
                  
  2. Check the IdP.Verify service status, app assignment, secret validity, exact redirect URI and Issuer URL.
    3. 
                  
  3. Use break-glass access.Sign in with the designated local Admin and 2FA. Disable Enforce SSO if required while retaining the OIDC configuration for diagnosis.
    4. 
                  
  4. Recover and retest.Correct the setting, run Test Connection, complete a real Test SSO Login, then re-enable enforcement only after both normal SSO and break-glass paths pass.
    5. 
                


                
Current scopeOIDC, JIT provisioning, and SCIM 2.0 user lifecycle provisioning are supported. SAML and IdP group-to-role mapping are not currently available. A production Portal requires an internet-reachable HTTPS IdP.

              


              

                
Multi Authentication
Enable TOTP two-factor authentication

                
  1. Sign in as yourself.Only the account owner can start or confirm enrollment. A Portal admin cannot view another user's QR code, secret, or recovery codes.
  2. Select Set up 2FA.Open Settings → Multi Authentication while signed in to the account being protected.
  3. Add it to an authenticator.Scan the QR code or enter the manual key in an approved TOTP app.
  4. Confirm the code.Enter the current 6-digit code and select Confirm and enable.
  5. Store recovery codes.Save the displayed recovery codes in an approved password manager. They may not be displayed again.
  6. Recover securely.If access is lost, a Portal admin may disable 2FA once. The account owner must then sign in and complete a new self-enrollment.

              


              

                
Audit · Admin only
Review administrative activity

                
  1. Identify the actor and time.Start with who performed the action and when it occurred.
  2. Review the object and action.Correlate policy edits, user administration, extension package activity and operator actions with the relevant Portal record.
  3. Investigate unexpected changes.Confirm the change with the actor and approved change record. Rotate affected credentials or reverse policy only through the authorised response process.
  4. Preserve evidence.Do not edit operational data merely to make an audit entry disappear. Export or capture records only under the customer's retention process.

              


              

                
Data Retention · Logs and operational records

                
Know how long BDR keeps each record

                
BDR provides short-term operational visibility. It is not a long-term log archive, evidence vault, backup service, or SIEM. The limits below apply separately to each tenant.


                
Logs subject to automatic retention

                

                  

                    
Record typeRetention periodRecord limitDeletion rule

                    
                      
General telemetry events7 daysUp to 1,000 events per tenantIncludes routine browser activity and historical inventory snapshots. The oldest record is permanently removed when either limit is reached.

                      
Security, DLP and blocked-response events30 daysIncluded in the 1,000-event tenant limitSecurity event classification extends the time window, but the shared event record limit still applies.

                      
Open, Investigating or Acknowledged alertsUntil the alert is ClosedNot included in the closed-alert limitActive alerts are not deleted by age. Close an alert only after the investigation and required notes are complete.

                      
Closed alerts30 days after the last status changeUp to 2,000 closed alerts per tenantThe oldest Closed alert is permanently removed when either limit is reached.

                      
Case comments and response actionsSame as the associated alertFollow the associated tenant and alertThey remain while the alert remains and are permanently removed with that alert, preventing orphan case data.

                      
Audit logs90 daysUp to 5,000 records per tenantIncludes sign-in, policy, user, alert-status, token and other administrative actions. The oldest record is permanently removed when either limit is reached.

                    
                  

                

                
The first limit reached applies.A record can be deleted before the stated number of days if its per-tenant record limit is reached. Deleted records cannot be restored by BDR.


                
Product data not subject to log retention

                

                  

                    
Data categoryExamplesHow long it remains

                    
                      
Policy and detection configurationPolicies, custom rules, policy overrides and deleted-rule stateUntil an authorised administrator changes or deletes it.

                      
Tenant and user stateTenant records, Portal users, managed users, archived user state and user mappingsUntil changed or deleted through an authorised lifecycle action.

                      
Current device inventoryThe current managed-browser device registry and latest device stateUntil the device is explicitly removed. Historical inventory snapshot events remain subject to the 7-day event policy.

                      
Extension security configurationActive extension tokens, default token mapping and current package configurationUntil rotated, revoked, replaced or deleted by an authorised administrator.

                      
Identity configurationOIDC and SCIM configurationUntil changed or deleted by an authorised administrator.

                    
                  

                


                
Customer responsibility

                
    
                  
  • Export required Alerts or Audit records before the applicable time or record limit is reached.
    • 
                  
  • Store long-term records in the customer's own approved SIEM, archive, or evidence system.
    • 
                  
  • Do not rely on an active alert as a backup of every underlying telemetry event.
    • 
                  
  • Closing an alert starts its 30-day retention period and also governs its case comments and response actions.
    • 
                

                
No BDR archive or restore.BDR does not provide archive, restore, or legal-hold storage for expired logs. Customers with longer retention or compliance requirements must export records before expiry.

              


              

                
Extension Security · Admin only
Manage tokens, builds and company deployment

                
  1. Choose the target browser.Chrome, Edge and Firefox have separate Developer Build and Company Deployment artifacts. Never deploy one browser's pack to another browser.
  2. Use Developer Build for controlled testing.Generate or select a tenant token, confirm the API Base URL, build the matching browser package and keep the raw token confidential.
  3. Use Company Deployment for managed fleets.Confirm the browser-specific Extension ID, signed CRX or XPI URL, API URL and tenant token, then generate that browser's tenant-specific ZIP.
  4. Use a supported management channel.Chrome supports GPO, Intune, macOS MDM and Google Admin. Edge and Firefox support GPO, Intune and macOS MDM; Google Admin does not manage those browsers.
  5. Rotate safely.When replacing a token, deploy the new managed policy and verify endpoints before revoking the old token.

                
Secret handlingA tenant deployment token grants extension ingestion for that tenant. Do not put it in tickets, public chat, screenshots or another customer's pack.

              


              

                
ViewGuard documentation
Chrome Installation Guideline

                
Choose the browser-management method already used by the customer. Customer IT is responsible for enrolling and managing Chrome; Prosfinity provides the signed ViewGuard extension, tenant policy pack, deployment values, and end-to-end validation steps.

                
The deployment ZIP is useful.Generate it once for the correct tenant under Settings → Extension Security → Company Deployment. It contains the Windows registry policy, macOS mobileconfig, Google Admin JSON, release manifest, validation checklist, and rollback notes. Treat it as confidential because it contains the tenant extension token.

                
Windows GPOActive Directory managed Windows devicesWindows IntuneMicrosoft Intune managed Windows devicesmacOS MDMMDM-enrolled Mac computersGoogle Admin ConsoleChrome Enterprise managed browsers

              


              

                
Before you begin
Information supplied by Prosfinity

                

                  
Extension IDinalpegloaagicplciefkhpdilbaeeli

                  
Update manifest URLhttps://bdr.prosfinity.com/extension/updates.xml

                  
BDR API URLhttps://bdr.prosfinity.com

                  
Installation policyForce install

                  
Managed configurationapiBaseUrl + tenant-specific apiToken

                

                
The same signed CRX is used by every customer. The tenant-specific apiToken assigns browsers to the correct tenant and must never be reused across customers. Do not paste a token into a ticket, email thread, or public chat.

              


              

                
Method 1
Windows — Active Directory Group Policy

                
Use this method when Windows computers are domain joined and customer IT manages Chrome through Active Directory GPO.

                
    
                  
  1. Prepare a pilot OU.Confirm Google Chrome is installed, the computer is domain joined, and a small pilot computer group or OU is available. Remove or reconcile older local registry, GPO, MDM, or cloud policies for the same extension; device-level policy can override a conflicting cloud/user policy.
    2. 
                  
  2. Install Google Chrome policy templates.Customer IT adds the current Google Chrome Enterprise ADMX/ADML templates to the domain Central Store, then opens Group Policy Management.
    3. 
                  
  3. Create and scope a computer GPO.Link a new ViewGuard Chrome policy to the pilot OU. Do not target production users until the pilot passes.
    4. 
                  
  4. Force-install ViewGuard.Go to Computer Configuration → Policies → Administrative Templates → Google → Google Chrome → Extensions → Configure the list of force-installed apps and extensions. Enable it and add inalpegloaagicplciefkhpdilbaeeli;https://bdr.prosfinity.com/extension/updates.xml.
    5. 
                  
  5. Apply tenant managed policy.Use Group Policy Preferences → Windows Settings → Registry, with the tenant ZIP registry file as the exact reference. Under HKLM\Software\Policies\Google\Chrome\3rdparty\extensions\inalpegloaagicplciefkhpdilbaeeli\policy, create string values apiBaseUrl and apiToken using the values from that tenant's ZIP. Do not ask end users to double-click the confidential .reg file.
    6. 
                  
  6. Update and test.Run gpupdate /force on a pilot device, open chrome://policy, select Reload policies, fully quit Chrome, and reopen it.
    7. 
                  
  7. Validate, then expand scope.Complete every check in the verification section before linking the GPO to broader OUs.
    8. 
                

                
ZIP files usedThe tenant .reg file provides the exact force-install and managed-policy registry values. Review it before applying through GPO.

              


              

                
Method 2
Windows — Microsoft Intune

                
Use this method when Windows devices are Entra joined or registered and enrolled in Microsoft Intune.

                
    
                  
  1. Create a pilot device group.Confirm the devices are Intune enrolled, Chrome is installed, and the same pilot group will receive both installation and tenant policies. Check for an existing GPO, registry script, MDM profile, or Google cloud policy affecting the same extension before assignment.
    2. 
                  
  2. Create the Chrome force-install profile.In Intune admin center, use Devices → Configuration and the available Chrome Settings Catalog or imported Google Chrome ADMX settings. Configure the force-install list with inalpegloaagicplciefkhpdilbaeeli;https://bdr.prosfinity.com/extension/updates.xml.
    3. 
                  
  3. Deploy the tenant managed policy.Deploy the two HKLM string values from the tenant ZIP under Software\Policies\Google\Chrome\3rdparty\extensions\inalpegloaagicplciefkhpdilbaeeli\policy. Use the customer's approved Intune method, such as a reviewed PowerShell/Win32 package or remediation. A .reg file is a reference artifact; it is not directly importable as an Intune configuration profile.
    4. 
                  
  4. Assign both controls to the same pilot group.The extension can install without becoming tenant connected if the managed configuration is assigned to a different scope.
    5. 
                  
  5. Force an Intune sync.From Company Portal or Windows Settings, sync the device. Then open chrome://policy, reload policies, fully quit Chrome, and reopen it.
    6. 
                  
  6. Review Intune status.Confirm both profiles report success for the pilot device, complete the ViewGuard verification, then phase the assignment to production groups.
    7. 
                

                
ZIP files usedUse the tenant .reg as the source of truth for registry paths and values. Convert or wrap it only through the customer's approved Intune deployment process.

              


              

                
Method 3
macOS — Mobile Device Management

                
Use this method when customer Macs are enrolled in Jamf, Kandji, Microsoft Intune, Mosyle, or another MDM that can deploy configuration profiles.

                
    
                  
  1. Create a pilot smart group.Confirm each Mac is MDM enrolled, Google Chrome is installed, and chrome://management reports that the browser is managed. Remove or reconcile any old local com.google.Chrome plist/profile or cloud policy for the same extension before testing.
    2. 
                  
  2. Generate the correct tenant ZIP.Download and inspect viewguard-chrome-<extension-id>.mobileconfig. It contains both Chrome force installation and tenant managed configuration.
    3. 
                  
  3. Upload the profile to MDM.Create a custom configuration profile in the customer's MDM, upload the supplied .mobileconfig, and assign it at device/system scope to the pilot group.
    4. 
                  
  4. Resolve conflicts before rollout.Do not deploy another profile with different Chrome extension settings to the same devices. Confirm the MDM reports the profile as installed.
    5. 
                  
  5. Reload Chrome.Open chrome://policy, select Reload policies, verify the production Extension ID and extension policy, then fully quit and reopen Chrome.
    6. 
                  
  6. Validate, then expand scope.Complete the verification checklist before assigning the configuration profile to the production Mac fleet.
    7. 
                

                
ZIP files usedUpload the tenant-specific .mobileconfig. For a pilot only, it can also be reviewed in System Settings → General → Device Management; production deployment should remain MDM controlled.

              


              

                
Method 4
Google Admin Console — Chrome Enterprise

                
Use this method when customer IT already manages Chrome browsers or managed Google users from Google Admin Console.

                
    
                  
  1. Prepare one pilot OU or group.In Google Admin Console, place the pilot users or enrolled browsers in the intended organizational unit or group and enable Chrome browser management for that scope.
    2. 
                  
  2. Open Apps & extensions.Go to Devices → Chrome → Apps & extensions → Users & browsers, then select the pilot OU or group.
    3. 
                  
  3. Add the private extension.Choose Add Chrome app or extension by ID, enter inalpegloaagicplciefkhpdilbaeeli, choose From a custom URL, enter https://bdr.prosfinity.com/extension/updates.xml, and save.
    4. 
                  
  4. Set the installation policy.Open the ViewGuard extension settings and choose Force install. Users must not be allowed to remove or disable it.
    5. 
                  
  5. Apply the tenant JSON.For the same extension and exact same OU/group, open Policy for extensions. If the panel shows Upload, upload viewguard-google-admin-<extension-id>.json from that tenant's ZIP. Otherwise open the file and paste its complete valid JSON into the text field. Confirm there is no validation error and that it contains apiBaseUrl and that tenant's apiToken.
    6. 
                  
  6. Understand what JSON does not do.Uploading or pasting the JSON only delivers ViewGuard managed policy. Customer IT must still select the OU/group, add the self-hosted extension, enter the Extension ID and custom update manifest URL, choose Force install, and save.
    7. 
                  
  7. Save and reload policy.Allow Google policy propagation, then on a pilot device open chrome://policy, select Reload policies, fully quit Chrome, and reopen it.
    8. 
                  
  8. Validate, then roll out.Confirm installation and tenant policy separately. Only after every verification passes should customer IT apply the settings to a broader OU/group.
    9. 
                

                
Two controls are required.Force install installs the CRX. Managed configuration connects it to the correct tenant. A successful installation alone is not a completed deployment.

                
ZIP file usedUse viewguard-google-admin-<extension-id>.json from the correct tenant pack. Upload that JSON where the Admin panel offers Upload, or paste its complete contents into Policy for extensions. Never upload the whole ZIP. Older packs should be regenerated before deployment.

              


              

                
ViewGuard documentation
Edge Installation Guideline

                
Generate an Edge Company Deployment pack and use only the Edge artifacts. The signed Edge CRX, Extension ID, update manifest and managed-policy paths are different from Chrome.

                
Windows GPOMicrosoft Edge policies on domain-managed WindowsWindows IntuneIntune-managed Windows devicesmacOS MDMMDM-managed Microsoft Edge on Mac

                
Google Admin is not an Edge deployment method.Google Admin Console manages Chrome apps and extensions. Use Microsoft Edge enterprise policy through GPO, Intune or macOS MDM for Edge.

              


              

                
Before you begin
Edge deployment values

                
Extension IDpgnnnpinccfeldgmimjkhjdeikokgpkm
Update manifesthttps://bdr.prosfinity.com/extension/edge-updates.xml
BDR API URLhttps://bdr.prosfinity.com
Managed configurationapiBaseUrl + tenant-specific apiToken

                
Use the Edge tenant pack.Generate it under Settings → Extension Security → Company Deployment with Microsoft Edge selected. The ZIP contains viewguard-edge-<extension-id>.reg, viewguard-edge-<extension-id>.mobileconfig, release details, validation checks and rollback notes. It contains a tenant token and must be handled as confidential.

                
The Chrome and Edge extensions have different IDs, signed CRX files, update manifests and policy roots. Do not reuse a Chrome registry file, mobileconfig or Extension ID for Edge.

              


              

                
Edge · Method 1
Windows — Active Directory Group Policy

                
Use this method for domain-joined Windows devices managed through Active Directory.

                
Group Policy provides the most consistent deployment model for a traditional Windows domain because the extension installation policy and its tenant configuration can be applied at computer scope. ViewGuard is installed silently from the Prosfinity update service, while the managed values bind that installation to the correct customer tenant. End users do not need local administrator access and cannot remove a force-installed extension.

                
Keep both controls in one computer GPO wherever possible. Splitting installation and configuration across unrelated GPOs makes scope, precedence and troubleshooting harder to audit, particularly when devices move between organisational units.

                
  1. Prepare a pilot OU.Confirm Microsoft Edge is installed and managed, then identify a small computer OU. Find and resolve any existing Edge cloud, GPO, MDM or local registry policy for the same Extension ID before deployment.
  2. Install Microsoft Edge policy templates.Add the current MSEdge.admx and matching language ADML files to the domain Central Store, then open Group Policy Management.
  3. Create and scope a computer GPO.Link a ViewGuard Edge GPO only to the pilot OU. Keep installation and tenant configuration in the same device scope.
  4. Force-install ViewGuard.Go to Computer Configuration → Policies → Administrative Templates → Microsoft Edge → Extensions → Control which extensions are installed silently. Enable it and add pgnnnpinccfeldgmimjkhjdeikokgpkm;https://bdr.prosfinity.com/extension/edge-updates.xml.
  5. Apply the tenant configuration.Using Group Policy Preferences → Windows Settings → Registry, create apiBaseUrl and apiToken as string values under HKLM\Software\Policies\Microsoft\Edge\3rdparty\extensions\pgnnnpinccfeldgmimjkhjdeikokgpkm\policy. Copy the exact values from the Edge tenant .reg; do not ask users to import the confidential file.
  6. Refresh the pilot.Run gpupdate /force, open edge://policy, select Reload policies, fully quit every Edge process and reopen Edge.
  7. Validate and phase rollout.Confirm ExtensionInstallForcelist, both managed values, tenant connectivity, inventory and a monitor-mode test alert before expanding the GPO.

                
A successful result has two independently verifiable parts: Edge reports ViewGuard as installed by enterprise policy, and the Portal reports the pilot device Online in the intended tenant. Do not expand the GPO if only one of those checks succeeds.

                
ZIP file usedviewguard-edge-<extension-id>.reg is the exact reference for both Edge force-install and tenant managed-storage paths.

              


              

                
Edge · Method 2
Windows — Microsoft Intune

                
Use this method for Entra joined or registered Windows devices enrolled in Microsoft Intune.

                
Intune deployment uses the native Microsoft Edge policy catalog for silent installation and a separately managed Windows delivery for the tenant values. This separation is expected: the catalog controls browser behaviour, whereas the tenant configuration is stored in Edge's extension-managed policy registry path.

                
Treat the two assignments as one release. They should use the same device-based pilot and production groups, the same change window and the same rollback decision. This prevents an apparently healthy CRX installation from remaining unregistered or reporting to the wrong tenant.

                
  1. Create a pilot device group.Confirm Edge is installed and the devices are Intune enrolled. Check whether GPO, security baselines or another configuration profile already manages Edge extensions.
  2. Create the force-install profile.In Intune admin center go to Devices → Configuration, create a Settings Catalog profile for Microsoft Edge, and configure Control which extensions are installed silently with pgnnnpinccfeldgmimjkhjdeikokgpkm;https://bdr.prosfinity.com/extension/edge-updates.xml.
  3. Deploy managed storage.Deploy the apiBaseUrl and apiToken string values from the Edge tenant .reg under HKLM\Software\Policies\Microsoft\Edge\3rdparty\extensions\pgnnnpinccfeldgmimjkhjdeikokgpkm\policy. Use an approved PowerShell script, Win32 package or remediation; a .reg file is not directly importable as an Intune configuration profile.
  4. Align assignments.Assign the force-install profile and managed-storage delivery to the same pilot device group. Installing the CRX without both managed values does not connect the browser to a tenant.
  5. Sync and inspect status.Trigger an Intune device sync, confirm both assignments report success, then reload edge://policy and restart Edge completely.
  6. Validate and expand.Confirm the expected ID and version in edge://extensions, both policies in edge://policy, Portal inventory and a monitor-mode test alert before production assignment.

                
Intune reporting confirms that a policy reached Windows; it does not by itself prove that Edge loaded the policy or that ViewGuard authenticated successfully. Browser-side and Portal-side verification remain mandatory.

                
ZIP file usedUse viewguard-edge-<extension-id>.reg as the source of truth when implementing the registry values through the customer's approved Intune method.

              


              

                
Edge · Method 3
macOS — Mobile Device Management

                
Use this method for Macs enrolled in Jamf, Kandji, Intune, Mosyle or another MDM that supports custom configuration profiles.

                
The supplied configuration profile contains two coordinated payloads: Microsoft Edge receives the force-install instruction, and the extension-specific managed preference domain receives the tenant connection values. Deploying the complete profile at system scope keeps both controls under MDM ownership and applies them consistently to every user of the Mac.

                
Do not copy individual keys into an existing browser profile unless the customer has reviewed payload identifiers, precedence and removal behaviour. Uploading the generated tenant profile as a distinct managed object gives administrators a clearer audit trail and a safer rollback path.

                
  1. Prepare a pilot smart group.Confirm each Mac is MDM enrolled, Edge is installed, and edge://management reports the browser as managed. Resolve any existing com.microsoft.Edge profiles that set conflicting extension policies.
  2. Generate and inspect the Edge pack.Use viewguard-edge-<extension-id>.mobileconfig, never the Chrome profile. It contains an ExtensionInstallForcelist payload for com.microsoft.Edge and a tenant managed-storage payload for com.microsoft.Edge.extensions.pgnnnpinccfeldgmimjkhjdeikokgpkm.
  3. Upload at system scope.Create a custom configuration profile in MDM, upload the supplied file and assign it at device/system scope to the pilot smart group.
  4. Confirm profile delivery.Wait for MDM to report the profile installed. Do not assign another profile with a different update URL or tenant token to the same Macs.
  5. Reload and inspect Edge.Open edge://policy, reload policies, confirm the force-install entry plus apiBaseUrl/apiToken, then fully quit and reopen Edge.
  6. Validate and roll out.Confirm the extension cannot be disabled, the browser appears Online in the correct Portal tenant, and a monitor-mode test alert arrives before expanding scope.

                
Removing the MDM profile withdraws the managed settings and force-install requirement. Follow the documented rollback order so the tenant token is removed from endpoints before it is revoked in the Portal.

                
ZIP file usedUpload the tenant-specific viewguard-edge-<extension-id>.mobileconfig through MDM; production users should not install it manually.

              


              

                
ViewGuard documentation
Firefox Installation Guideline

                
Firefox uses a Mozilla-signed XPI and Firefox Enterprise Policies. Generate a Firefox Company Deployment pack and use its policies.json, Windows registry or macOS MDM artifact.

                
Windows GPOMozilla enterprise policy on domain-managed WindowsWindows IntuneIntune-managed Firefox on WindowsmacOS MDMMDM-managed Firefox on Mac

                
Google Admin is not a Firefox deployment method.Use Mozilla Enterprise Policies through GPO, Intune or macOS MDM. Do not upload Firefox artifacts to Google Admin Console.

              


              

                
Before you begin
Firefox deployment values

                
Extension IDviewguard-bdr@prosfinity.com
Signed packagehttps://bdr.prosfinity.com/extension/viewguard-firefox.xpi
BDR API URLhttps://bdr.prosfinity.com
Policy engineMozilla Enterprise Policies

                
Use the Firefox tenant pack.It contains viewguard-firefox-<extension-id>-policies.json, a Windows .reg, a macOS .mobileconfig, release details and validation notes. All three deliver both forced XPI installation and tenant managed configuration.

                
Only deploy the Mozilla-signed XPI. The add-on ID inside the XPI and the ID used by ExtensionSettings and 3rdparty.Extensions must all be viewguard-bdr@prosfinity.com.

              


              

                
Firefox · Method 1
Windows — Active Directory Group Policy

                
Use this method for domain-joined Windows devices where Firefox is managed by Active Directory.

                
Firefox Enterprise Policies provide the equivalent of a browser force-install policy, but the policy names and storage model differ from Chromium browsers. ExtensionSettings installs and locks the Mozilla-signed XPI, while 3rdparty.Extensions supplies the managed values that connect ViewGuard to the customer's tenant.

                
Use the registry artifact as a reviewed source for centrally managed computer policy, not as an end-user installer. Keeping the settings in Active Directory ensures they are reapplied, auditable and removable through the customer's normal change process.

                
  1. Prepare a pilot OU.Confirm Firefox is installed and identify a small computer OU. Remove or reconcile an existing distribution/policies.json, local registry, GPO or MDM policy for the same add-on before testing.
  2. Install Mozilla policy templates.Add the current Firefox ADMX/ADML templates to the domain Central Store and create a computer GPO scoped to the pilot OU.
  3. Use the generated policy values.The tenant .reg writes the JSON ExtensionSettings policy to HKLM\Software\Policies\Mozilla\Firefox. It force-installs viewguard-bdr@prosfinity.com from https://bdr.prosfinity.com/extension/viewguard-firefox.xpi.
  4. Deliver tenant managed storage.Under HKLM\Software\Policies\Mozilla\Firefox\3rdparty\Extensions\viewguard-bdr@prosfinity.com, deploy string values apiBaseUrl and apiToken exactly as supplied in the tenant .reg.
  5. Apply through managed GPO.Translate or deploy the reviewed values through Group Policy Preferences. Do not ask employees to import the confidential registry file directly.
  6. Refresh and inspect.Run gpupdate /force, fully restart Firefox, then open about:policies. The Active tab must show ExtensionSettings and 3rdparty without errors.
  7. Validate and phase rollout.Confirm the add-on is locked, both managed values are available, the browser appears in the expected tenant and a monitor-mode test alert arrives.

                
Firefox must show both policy branches under about:policies without an Errors entry. An installed add-on alone is incomplete because it may not yet have received its tenant configuration.

                
ZIP files usedUse viewguard-firefox-<extension-id>.reg for Windows GPO. The supplied policies.json is a readable cross-platform reference, not a substitute for centrally managed GPO unless customer IT deliberately manages Firefox's distribution directory.

              


              

                
Firefox · Method 2
Windows — Microsoft Intune

                
Use this method for Intune-enrolled Windows devices running Mozilla Firefox.

                
Unlike Microsoft Edge, Firefox settings may not be available as native entries in every Intune tenant and service release. Customer IT therefore chooses one supported delivery pattern—imported Mozilla administrative templates or a managed script/package—and uses it consistently for both forced installation and tenant configuration.

                
The generated registry and JSON artifacts describe the same intended Firefox policy in different forms. They are reference inputs for the customer's chosen Intune implementation; assigning the raw files without an appropriate configuration or packaging workflow is not a complete deployment.

                
  1. Create a pilot device group.Confirm Firefox is installed and devices are Intune enrolled. Check for an existing Firefox ADMX profile, script, Win32 app or local policies.json that could conflict.
  2. Choose the approved Intune delivery method.Customer IT can import Mozilla's Firefox ADMX/ADML templates or deploy the reviewed registry values through PowerShell, a Win32 app or remediation. Use one authoritative method for the same settings.
  3. Configure forced XPI installation.Deliver the generated ExtensionSettings JSON for viewguard-bdr@prosfinity.com, with installation_mode set to force_installed and install_url set to the signed ViewGuard XPI URL.
  4. Configure tenant managed storage.Deploy apiBaseUrl and apiToken from viewguard-firefox-<extension-id>.reg under HKLM\Software\Policies\Mozilla\Firefox\3rdparty\Extensions\viewguard-bdr@prosfinity.com.
  5. Align assignments.Target forced installation and tenant configuration to the same pilot device group. A successful XPI install without 3rdparty values is not a completed deployment.
  6. Sync and troubleshoot policy.Force an Intune sync, review device configuration status, restart Firefox and inspect both Active and Errors in about:policies.
  7. Validate and expand.Confirm the correct tenant, online inventory and a test alert before broader assignment. Use the common rollback steps if either policy fails.

                
Record which Intune delivery method owns these settings. Two overlapping methods can report success independently while repeatedly overwriting each other on the endpoint.

                
ZIP files usedThe Firefox .reg is the exact Windows value reference; policies.json shows the complete expected ExtensionSettings and 3rdparty structure. Neither file is directly importable as an Intune configuration profile without the customer's chosen packaging method.

              


              

                
Firefox · Method 3
macOS — Mobile Device Management

                
Use this method for MDM-enrolled Macs running Mozilla Firefox.

                
Firefox reads managed macOS preferences from the org.mozilla.firefox payload. The tenant-specific profile combines the enterprise policy that installs the signed XPI with the third-party extension values required for portal registration, allowing MDM to manage the full deployment as one configuration object.

                
Apply the profile at device scope so its behaviour does not depend on which user is signed in. A dedicated pilot smart group should receive the profile first, giving administrators time to confirm Firefox policy parsing, add-on installation and Portal connectivity before broad assignment.

                
  1. Prepare a pilot smart group.Confirm Firefox is installed and the Mac is MDM enrolled. Resolve any existing org.mozilla.firefox profile or local distribution/policies.json that sets conflicting extension policy.
  2. Generate and inspect the Firefox pack.Use viewguard-firefox-<extension-id>.mobileconfig; Chrome and Edge profiles are not interchangeable. The profile uses payload type org.mozilla.firefox and enables enterprise policies.
  3. Confirm both controls are present.The profile must contain ExtensionSettings for forced installation and 3rdparty → Extensions → viewguard-bdr@prosfinity.com with apiBaseUrl and apiToken.
  4. Upload at system scope.Create a custom configuration profile in Jamf, Kandji, Intune, Mosyle or the customer's MDM, upload the supplied file and assign it to the pilot smart group.
  5. Confirm MDM delivery.Wait for the profile to report installed, fully restart Firefox, then inspect Active and Errors in about:policies.
  6. Validate and roll out.Confirm the Mozilla-signed XPI is locked, the extension is tenant connected, inventory is Online and a monitor-mode alert reaches the correct tenant before expanding scope.

                
MDM installation status proves that macOS accepted the profile, not that Firefox parsed every key. Always check about:policies and the Portal before promoting the profile beyond the pilot group.

                
ZIP file usedUpload viewguard-firefox-<extension-id>.mobileconfig at device/system scope. Do not distribute the profile or its embedded tenant token to end users.

              


              

                
Required for every method
Verification, rollout, and troubleshooting

                
    
                  
  • The installed ID matches the selected browser: Chrome inalpegloaagicplciefkhpdilbaeeli, Edge pgnnnpinccfeldgmimjkhjdeikokgpkm, or Firefox viewguard-bdr@prosfinity.com.
  • Extension is force-installed and cannot be disabled.
  • chrome://policy, edge://policy, or about:policies shows the browser-specific policy without errors.
  • The extension policy shows both apiBaseUrl and apiToken.
  • Extension reports API connected / HTTP 200 and the expected tenant.
  • A Device ID appears and the browser is Online in Portal Inventory.
  • A supported test action creates an alert for the same Device ID.
    • 
                

                

                  
Extension is missing or blockedCheck device/browser enrollment, policy scope, the browser-specific Extension ID and package URL, and errors in chrome://policy, edge://policy, or about:policies. Remove conflicting cloud, registry, plist, GPO, MDM, or local policies before retesting.

                  
HTTP 401 or tenant unknownThe tenant managed policy is missing, incorrect, or revoked. Reapply the pack generated for the correct tenant.

                  
Installed but no Portal deviceConfirm apiBaseUrl and apiToken appear under the production extension policy, then fully restart the selected browser.

                  
RollbackRemove the force-install assignment and tenant managed policy from the same scope. Confirm the browser removes the extension, then revoke the old tenant token only after all devices have migrated.

                

                
Official references: Chrome ExtensionInstallForcelist · Google Admin apps & extensions · Chrome Windows registry policies · Microsoft Edge ExtensionInstallForcelist · Manage Edge extensions · Mozilla policy templates · Firefox Group Policy · Apple device management profiles