Five steps to secure the browsers and extensions your employees use
Companies can strengthen browser security while improving productivity using well implemented application control. The bring-your-own-browser model works best when organizations enforce approved browsers and supported versions, block untrusted extensions by default, and provide a practical intake process for new browsers and extensions.
Introduction
A closed corporate browser has an understandable appeal. Put everyone in one environment and apply your controls in a contained environment. But moving people to a different browser creates work of its own. Familiar workflows need to be rebuilt, applications may stop working as expected, and employees have to adjust.
There may be specific environments that justify a dedicated corporate browser. But before arriving on that solution, I would first ask whether we can deliver the controls we need through the browsers employees already use. The answer depends on whether we can marry this choice with the appropriate level of security required to operate with confidence.
The good news is you don’t have to compromise. It is possible to have browser security in a bring-your-own-browser model. With the right level of control, you can give employees a choice among browsers the organization can secure, then enforce the conditions under which those browsers and their extensions can run. This approach protects the business while preserving the tools people already know how to use.
Step 1: Approve the Browser and the Version
Bring your own browser doesn’t mean any browser or version. You must first work to create an approved set of browsers and versions from approved publishers, and versions without known vulnerabilities. An employee might prefer Chrome, Edge, or Firefox, provided the organization can manage that browser and enforce its security requirements.
Once this policy is created, application control policies can be implemented that allow approved browser software to execute and prevent unapproved browsers from running. Furthermore, these rules can be tweaked to cover alternate installations and portable copies on the endpoints in scope.
Approval also needs to account for version. A trusted publisher’s name does not make an old executable safe. Define which supported releases meet your requirements, keep them patched, and retire versions with known vulnerabilities. Properly implemented application control should prevent those retired versions from launching.
Claude Mythos makes the requirement of version support mission critical. In April 2026, Mozilla reported that Firefox 150 included fixes for 271 vulnerabilities identified through an initial evaluation of Claude Mythos Preview. For security teams, the practical lesson is that vulnerability discovery only helps when the fixes reach the software people actually run. Thus, application control policy must be constructed in a way that does not include vulnerable older releases.
Keep patch deployment and application control aligned, ensuring supported update can reach users promptly and is approved to execute. Without that, it’s possible that users are stuck without an approved version of the browser that is able to execute.
Step 2: Deny Untrusted Extensions by Default
Once the browser and version are approved, the next decision is what can run inside it. An extension is another piece of software, with its own publisher, update history, and access to resources and privileges. Approving the browser should not approve everything available in its extension store.
The operating rule should be Deny by Default. Extensions the organization has not trusted should be prevented from running while they are evaluated. Blocking a known bad extension is useful, but it leaves the next unknown extension free to operate. A Deny by Default model makes approval a prerequisite for execution.
Apply that rule to each approved browser. The same tool may have different extension IDs, packages, or requested permissions across browsers. Approval should identify the actual extension and the browser it is approved for. An approval for one store listing should not silently authorize a similarly named extension somewhere else.
Step 3: Review the Purpose and the Publisher
Employees still need a way to request new extensions where needed. Document a clear intake route and tell them what to expect while the request is reviewed. A blocked extension should lead to a decision your team can explain, and, when appropriate, an approved alternative that solves the employee’s problem or a process to consider adding a new extension where needed.
Before adding another extension, check the approved catalog. If an existing tool provides the same functionality with acceptable access, direct the employee to it. If the new tool meets a need the approved option cannot, document that difference and make a deliberate decision. Record the reviewer, permitted scope, and reason for approval or rejection so the next request does not start from scratch.
If a new extension is needed, start intake with what the employee is trying to accomplish. Record the business purpose, intended users, data and permissions involved, along with the exact extension ID, browser, version, and source. A translation tool for public webpages and an assistant operating inside customer records deserve different access decisions.
Then examine who is behind the software. Review publisher identity and reputation, the publisher’s domain, privacy practices, update history, and any ownership changes. Store ratings and installation counts can add context, but they do not establish trust. Use available VirusTotal reports for the extension package, where supported, and associated URLs or domains to inform that assessment. VirusTotal provides threat analysis and reputation information for files and domains; it does not replace verifying the publisher. A report with no detections is one input, rather than proof that an extension is safe.
Assess the permissions against the stated job. Does the extension need to read and change content on every website, or only on one service? Are requests for browsing history, cookies, or downloads necessary for the function the employee wants? Review the declared and optional permissions alongside observed behavior in an isolated test environment. Where access is justified, restrict it to the sites and users that need it using the controls available for that browser.
Step 4: Test the Rollout
Start by ensuring that unapproved browsers and versions can’t execute. This includes looking at workarounds for installation, including portable applications, side loading, and trusted application stores.
Additionally, test whether an unapproved extension is prevented from running, including one already present before the policy was applied. Check profiles and installation routes that could escape management, such as sideloaded or unpacked extensions. If a browser cannot meet the required enforcement standard, it should not remain on the approved list.
Step 5: Maintain and Optimize
Approval also needs maintenance. A publisher can change, a browser version can become compromised, or new extension privileges can alter your assessment. Track those changes and trigger review when the basis for trust changes. Keep the ability to revoke approval, disable the affected extension, and identify the users who had it. An extension that was acceptable last quarter does not get a permanent pass.
Treat browser versions and extensions as part of the same software governance process. Maintain an inventory, assign owners to decisions, and verify that the policy matches what is running. When an incident occurs, your team will be able to easily see which browsers and extensions are present and how to stop the affected software.
Bring-Your-Own-Browser Programs for the Win
When properly implemented, bring-your-own-browser programs can provide the perfect balance of productivity and security. Employees can keep a browser they are comfortable with, while the organization decides which software is trusted to run. The flexibility comes from offering useful choices within a policy your team can enforce and maintain. Nobody has to become an extension security expert to finish their customer proposal.
A practical first step is to select the browsers your organization will support, define how versions lose approval, and establish a Deny by Default extension policy. Build the request process alongside those controls. Test the model with a group of employees whose work depends on the browser, so you can resolve legitimate needs before expanding enforcement.
See Bring-Your-Own-Browser Capabilities in Action
See how Airlock Digital Application Control and Browser Extension Control help organizations enforce trusted software and approved extensions across Chrome, Edge, and Firefox. Talk to our team about supporting a bring-your-own-browser model with Deny by Default controls.