How to Build an Enterprise Browser

#browser #enterprisebrowser #zerotrust #chromium

Originally posted on Medium

The concept of an enterprise browser was something I hadn’t paid much attention to until recently, when I found myself in discussions with teams building these systems.

Having worked as a contractor for over ten years, I’ve frequently used managed browsers such as Chrome and Edge. Yet I rarely considered what actually goes into making them “enterprise-ready.” My work has primarily involved Chromium engine internals, including the content layer, Blink, and hardware integration, rather than the browser application layer itself.

During those discussions, I realized how interesting enterprise browsers are, especially in safety-critical environments. I recalled multiple situations in my career where a hardened enterprise browser would have been far more practical than the complicated stacks of VPNs, VDI setups, and jump hosts required just to access secure development environments.

The Enterprise Browser Blueprint

Before tearing down the Chromium source code, we must define what “enterprise-grade” actually means. It boils down to five core pillars:

Centralized Policy Enforcement Engine: A remotely managed control plane that defines, distributes, and enforces browser behavior across all managed instances.
Identity- and Context-Aware Access Control: An identity-integrated runtime that evaluates access decisions based on user identity, device posture, network context, and real-time risk signals.
Data Loss Prevention (DLP): A protection layer that monitors and restricts sensitive data flows within and between web applications.
Insights and Reporting: Centralized telemetry and proactive security event reporting for visibility and auditability.
Zero Trust Engine: A continuous verification model enforcing least-privilege access by validating identity and session risk throughout the lifecycle of a session. “Never Trust, Always Verify.”

An enterprise browser is not simply a hardened browser; it is security infrastructure.

Managed Standard Browsers vs. Commercial Solutions

Managed Standard Browsers (Chrome & Edge)

These are “enterprise-light” versions of everyday browsers. They are essentially consumer Chromium binaries with management hooks.

Google Chrome Enterprise: Managed via Chrome Browser Cloud Management (CBCM).
Microsoft Edge for Business: Deeply integrated with Microsoft Entra ID and Microsoft ecosystem.
Policy & DLP Capabilities: Both provide an extensive set of enterprise policies, built-in data loss prevention capabilities, Safe Browsing integration, identity-based access controls, and centralized reporting through their respective management platforms.
Enterprise Connectors: These are integration frameworks that allow the browser to send telemetry and content (such as file uploads or clipboard data) to third-party security providers for real-time analysis.

Commercial Enterprise Browsers

These are typically hardened Chromium derivatives or wrapper-based architectures designed specifically for security boundaries.

Granular Policy Extensions: Hyper-specific controls over browser internals.
Enhanced Data Loss Prevention: These tools implement advanced content inspection to redact sensitive data in real-time and prevent unauthorized data movement between applications via the clipboard or file uploads.
“Last Mile” Visibility: By enforcing policies within the browser runtime and renderer process, these solutions gain visibility into the DOM and user interactions that are invisible to network-level security tools.
Full control over the browser runtime: The ability to modify or instrument components of the rendering engine and JavaScript execution environment when necessary.
Tailored per client: The entire browser lifecycle and feature set can be customized to meet the specific compliance or operational needs of a single customer.

Why Build a Custom Enterprise Browser?

n my case, this project is driven by curiosity and the fact that no open-source project currently provides a full enterprise browser stack. However, for organizations in high-stakes industries such as Defense, Intelligence, or High-Frequency Trading, the reasoning goes far deeper than curiosity.

The Sovereignty Gap

While Chrome and Edge offer a vast number of security, reporting, and policy enforcement features, they are fundamentally designed to operate within the Google or Microsoft ecosystems. For organizations with extreme security requirements, this creates a “Sovereignty Gap” that only a custom-built solution can bridge.

Building a custom browser allows us to achieve:

De-Google the Core: Completely strip proprietary Google service dependencies that standard browsers require for background tasks, sync, and telemetry.
Google Services are Not Allowed: Ensure that no part of the browser attempts to communicate with Google-owned endpoints, eliminating “phone-home” traffic.
External Cloud is Forbidden: Architect the management and reporting plane to exist entirely within a private, air-gapped, or sovereign cloud environment.
Deep Runtime Instrumentation: Inject advanced controls deep into the renderer and JavaScript engine to monitor and block malicious behavior at the instruction level.
Per-client Hardened Runtime: Tailor the specific security surface area such as disabling specific Web APIs or hardware acceleration based on the unique risk profile of a specific client or mission.
Traceability & Determinism: Achieve full source-level auditability and deterministic builds, ensuring that every binary can be verified and every runtime decision can be traced back to a specific line of code.

Building a Custom Enterprise Browser

Almost every enterprise browser is Chromium-based. There is a good reason for that: it provides many necessary building blocks out of the box. Even when full implementations are not available, the necessary interfaces usually are. Therefore, it is significantly more practical to build on top of Chromium than to start from scratch, especially considering that for many users, the word “browser” effectively means Chrome.

To make it a true enterprise tool, several components must be implemented:

Cloud Management
Device Management and Reporting Servers
Secure Browsing Services
Zero Trust Engine

From a Chromium integration perspective, the following require extension or replacement:

Cloud Service Integration: Connecting the browser to the management plane.
Policy Handlers: Implementing specialized handlers for proprietary security constraints.
DLP Logic: Enhanced data loss prevention mechanisms integrated into the runtime.
“Last-mile” Control: Advanced controls injected deep into the Chromium engine.

Implementing the Foundation

There are many approaches to implementing an enterprise browser, and there is no single correct path. It requires significant effort on both the cloud and browser sides. However, given the AI tooling available today, the barrier to entry is significantly lower than it was just a few years ago.

My approach leverages Chromium’s modular architecture while maintaining a clean “downstream” build model:

Protocol Compatibility: Use Chromium’s existing protobuf interfaces for management services.
Identity: Rely on a third-party IdP (Identity Provider), as identity management is its own domain.
De-Google: Gradually remove Google service dependencies from Chromium components, replacing them with custom implementations.
Branding: Apply custom branding to establish a unique identity.
Build System: Instead of a messy fork, I use a sibling browser layer model to manage downstream updates.

The “eb” Build Tool

I created the eb (Enterprise Browser) build tool, heavily inspired by Brave’s tooling. It pulls a specific Chromium tag and patches the source to include the enterprise_browser layer as a sibling to the standard /chrome directory.

Enterprise Browser Cloud Management (EBCM)

This is where policy rules are defined and assigned to users via JIT (Just-In-Time) provisioning. EBCM integrates with a third-party IdP to provide user authentication and maps policies to specific user roles.

Enterprise Browser Device Management Server (EBDM Server)

The EBDM acts as the backend authority:

OIDC Authentication: The browser presents a signed ID token issued by the IdP to prove identity.
Policy Fetching: The server sends a protobuf payload containing settings (e.g., “Disable Incognito”).

Sign-in & Policy

I adapted Chromium’s OIDC authentication interceptor to authenticate users directly against my EBCM via the IdP. Currently, the system supports global policy settings driven through Chromium’s device management protobuf definitions.