TL;DR: Bring-your-own-browser models can preserve user choice without sacrificing security if organizations enforce approved browser versions, deny untrusted extensions by default, and keep approval decisions current, according to Airlock Digital. Browser governance fails when teams treat the browser as trusted but leave extensions, version drift, and approval workflows outside the control boundary.
At a glance
What this is: This is an analysis of how bring-your-own-browser security depends on controlling approved browser versions, extension execution, and review workflows rather than forcing a single corporate browser.
Why it matters: It matters because browser extensions can become an unmanaged access layer for data, sessions, and credentials unless IAM and endpoint teams govern what is allowed to execute.
Context
Bring-your-own-browser programs create a governance problem, not just an endpoint one. If users can choose their browser, security teams have to decide which publishers, versions, and extensions are allowed to run, and they have to do it without breaking productivity.
The core control issue is application control. Instead of assuming the browser itself is trustworthy, teams need to manage execution at the browser and extension layer, where permissions, update channels, and install paths can all change risk. browser extension security is the natural foundation for that decision.
Key questions
Q: How should security teams govern browser extensions in zero trust environments?
A: Security teams should treat browser extensions as privileged software with access to user data, sessions, and web content. The safest approach is policy based control, with whitelisting for approved extensions, blacklisting for known risky ones, centralized management, and continuous review of extension permissions. Masking sensitive fields and obfuscating inputs also reduce the chance that extensions can read or misuse confidential data.
Q: Why do approved browsers still create risk if extensions are unmanaged?
A: Because the browser becomes a trusted execution surface for code that can read pages, sessions, cookies, and sometimes downloads or history. If extensions are not reviewed separately, an approved browser can still host software that reaches sensitive workflows the organisation never intended to expose.
Q: What are the signs that browser approval policy is failing?
A: Look for users installing unsupported browser versions, sideloaded or unpacked extensions, store listings that do not match approved IDs, and extensions that remain active after the trust basis changes. Those are indicators that policy exists on paper but not in the runtime environment.
Q: Should organisations keep one corporate browser instead of managing user choice?
A: Not necessarily. A forced corporate browser can simplify control, but it often increases workflow friction and adoption problems. A governed bring-your-own-browser model can work better when the organisation can enforce approved versions, block untrusted extensions, and review exceptions quickly.
Technical breakdown
How application control governs browser execution
Application control is the enforcement layer that decides which executables are permitted to run, including alternate installations and portable copies. In a browser program, that means approved browsers and approved versions are on the allow list, while unapproved or retired versions are blocked from launching. This matters because publisher trust alone is not enough. A signed browser can still be vulnerable if the version is out of support or known to be exploitable. The control only works when patch management and execution policy stay aligned, so users cannot fall back to a stale binary after a rollout delay. See the Application Allowlisting Guide.
Practical implication: Tie browser allowlisting to supported version policy so patched releases are approved before older builds lose execution rights.
Why extensions need separate trust decisions
Browser extensions are not just add-ons. They are software components with their own publishers, permissions, update histories, and access to content, cookies, browsing data, and site interactions. A browser approval decision should never auto-approve every extension in the store. Deny by default shifts the burden of proof to the requester and forces security teams to evaluate the actual extension ID, not just a similar name or a store listing. This is especially important across multiple browsers, where the same functionality can appear under different package IDs and permission sets. See the Browser Extension Security Guide.
Practical implication: Maintain a separate approval list for extension IDs and browser-specific packages, and block everything else until reviewed.
How review and testing prevent approval drift
A browser security programme fails when approvals become static. Publishers can change ownership, update models can widen permissions, and a once-acceptable extension can turn risky after a new release. That is why rollout testing has to include sideloaded, unpacked, and pre-existing extensions, not just clean installations. Continuous review is the mechanism that keeps the approval decision matched to reality. Without revocation processes, inventory, and ownership for each approval, teams end up with a policy that says one thing while endpoints run another. See the Endpoint Security Maturity Model.
Practical implication: Test the policy against existing installations and unusual install paths before broad enforcement, then review approvals on a fixed cadence.
Threat narrative
Attacker objective: The attacker wants to exploit browser-level trust to reach user data, sessions, or sensitive workflows through an extension or vulnerable browser build.
- Entry begins when users install an approved browser, but an untrusted extension or outdated version slips past the intended control boundary.
- Credential and data access expand once the extension can read content, sessions, cookies, or browsing history inside the browser context.
- Impact follows when an extension with excessive permissions becomes a persistence or theft path that the organisation never intended to trust.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser extension governance is now part of identity governance. A browser extension can touch sessions, cookies, and authenticated web applications, which means it can influence how human identities are used after login. That makes extension approval a governance decision about access scope, not just a desktop control. Teams that own IAM and endpoint policy need a shared view of which extensions can operate inside business workflows, because browser trust can become identity trust in practice.
Deny by default is the only scalable browser control model. Allowing all extensions and trying to block known bad ones turns governance into a reaction loop. The article’s model is stronger because it requires explicit approval before execution and forces teams to evaluate browser, publisher, version, and permissions together. That shifts the control point from detection after install to authorization before use, which is the right boundary for browser risk.
Version control and extension control should be treated as one policy domain. A browser release and an extension update can each change the attack surface independently, but both affect the same runtime environment. That means approvals must expire, not accumulate, and revocation has to be operationally available when trust changes. The named concept here is browser trust drift: the gap that appears when approved software, permissions, and publisher assumptions are not revalidated after updates or ownership changes. Practitioners should design for drift, not assume trust stays stable.
The real governance problem is not choice, it is unmanaged choice. Bring-your-own-browser can work when the organisation constrains the execution environment tightly enough to preserve both productivity and control. The article shows that security teams should not try to eliminate user choice first; they should govern the software choices users make. That is a more durable operating model for enterprise browser security.
Extension reviews need to be identity-aware when access reaches sensitive workflows. A translation tool for a public site and an extension operating inside customer records are not equivalent, even if both are “just browser add-ons.” browser security controls matter here because the browser is now a boundary where identity, data access, and software trust intersect. Practitioners should classify extension approvals by the business data and sessions they can reach.
What this signals
Browser trust drift: enterprise browser programmes weaken when approved versions, extension permissions, and publisher assumptions are not revalidated after each update cycle. That drift matters because the browser is often the live boundary where authenticated users interact with sensitive web applications.
Security teams should expect extension risk to behave like software supply chain risk inside the browser layer. Approval is not a one-time event, and any model that cannot revoke trust when publisher ownership, update history, or permissions change will eventually drift out of policy.
For practitioners
- Define an approved browser and version list Allow only supported releases from approved publishers and block older versions with known vulnerabilities from executing.
- Enforce deny by default for extensions Require explicit approval before any extension can run, and treat each browser-specific extension ID as a separate decision.
- Build an intake process for new extensions Record the business purpose, users, permissions, exact extension ID, browser, version, and source before deciding whether approval is warranted.
- Test policy against bypass paths Validate that sideloaded, unpacked, portable, and pre-existing extensions cannot escape enforcement on managed endpoints.
- Maintain revocation and reassessment controls Track publisher changes, version changes, and permission changes so approval can be withdrawn when the trust basis changes.
Key takeaways
- Browser security in a bring-your-own-browser model depends on execution control, not just policy statements.
- Extensions deserve separate approval because they operate with their own publishers, permissions, and update histories.
- A working governance model must support review, revocation, and retesting as browser software changes over time.
Related NHI Mgmt Group resources: Browser Extension Security Guide · Enterprise Browser and Browser Security Guide · Top 10 Endpoint Security Risks · Endpoint Security Maturity Model
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Browser extensions can expose sessions, cookies, and credentials through the same trust boundary. |
| Recommendation — Scan browser extension permissions and revoke any extension that can expose secrets outside its intended scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | Browser extension governance affects how authenticated users and their sessions are handled on managed endpoints. |
| Recommendation — Enforce browser approval policies that restrict extension access to approved user workflows and managed accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on controlling what software may execute and what privileges it may gain in the browser. |
| Recommendation — Apply PR.AA-05 to govern browser and extension approvals as entitlements with explicit review and revocation. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Untrusted browser extensions can harvest credentials and session material inside the browser context. |
| Recommendation — Map risky extensions to TA0006 and hunt for browser-based credential exposure paths. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misconfigured browser approval and extension policy creates exploitable execution paths. |
| Recommendation — Remove security misconfigurations in browser allowlists and extension policies before broad deployment. | ||
Key terms
- Browser Trust Drift: The gap that appears when browser approvals, extension permissions, and publisher assumptions are not revalidated after updates or ownership changes. It creates a moving control boundary where software that was once acceptable can become risky without any obvious change in user behaviour.
- Deny By Default: Deny by default is an authorization rule that blocks access unless a policy explicitly permits it. It is the safer baseline for modern identity control because it limits accidental privilege expansion and makes every access grant visible, testable, and easier to review.
- Application control: Application control is the enforcement of which software may run on a device and under what conditions. It is a key governance layer because unauthorized or unsafe code can undermine access assurance even when authentication and device enrolment are in place.
- Browser Extension Security Model: The design pattern of placing sensitive client-side logic inside a browser extension rather than on the server or in page scripts. This approach is used to isolate cryptographic operations, protect keys, and reduce exposure to injection or server compromise in workflows that depend on secure collaboration.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a fit for practitioners who need to connect identity governance to access control decisions across modern environments.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org