Today, Mozilla launched Firefox Enterprise. The first release is Firefox Enterprise 158, which branches off Firefox 158. I’ve been working on it as a product manager since 2025, so it’s good to finally be able to talk about what we’ve been building. This post covers how I ended up working on it, and the decisions I pushed for along the way.

From MDN to Firefox

I joined Mozilla in 2022 as a technical writer on MDN Web Docs. I wrote a lot of HTTP documentation and the Firefox release notes for developers, but the job was wider than writing. I ran content migrations, maintained browser compatibility data, worked with the communities who translate MDN, and helped keep one of the most active projects on GitHub running smoothly.

In 2025, I moved from documenting Firefox to working on it. It turned out writing and reading browser release notes for a few years also gave me a solid understanding of how a browser is built and shipped.

Working on Enterprise means understanding how the whole product fits together: the UI, profile management, networking, preferences, enterprise policies, build and release systems, supporting services, testing infrastructure, and general operational constraints.

What is Firefox Enterprise?

Firefox has been used in organizations for a long time. The Extended Support Release has been around since 2012, and the policy engine (mostly thanks to Mike Kaply) since version 60 of Firefox. Thousands of organizations deploy and manage Firefox with ESR and enterprise policies.

Firefox Enterprise builds on that. There are two parts: a Firefox browser with additional security features built for managed environments, and an Admin Console that you run on your own infrastructure. IT teams use the Admin Console to manage policies and access, and to set controls for how data moves through the browser and how it can be used.

The services Mozilla runs for consumer Firefox can be self-hosted alongside the Admin Console: browser updates, Sync (for history and bookmarks, for example), Remote Settings, telemetry, and crash collection. Security event logging is off by default, and crash reporting can be turned off. When enabled, security events, crash reports, and telemetry go to the customer’s Admin Console, not to Mozilla.

What we landed in 158

The release notes have the full list, but here are some highlights:

• Company sign-in: users must authenticate through their company’s single sign-on (SSO) before browsing, using any OpenID Connect (OIDC) identity provider.
• Device posture: admins can require things like disk encryption or endpoint security for sign-in, and Firefox signs the user out if the device isn’t compliant.
• Watermarking: admins can overlay text such as the user’s email address and a timestamp on the sites they choose, so a leaked screenshot or photo of a sensitive page is attributable.
• Data loss prevention (DLP): admins can block or warn on paste, upload, download, and print on the sites they choose. The built-in checks run on-device.
• Lockdown Mode: admins can apply extra restrictions to specific sites, such as turning off JIT or isolating the site in its own container.
• Access Connector: users can access internal sites from a personal device without a device-wide VPN.
• Central policies: admins manage policies from one place, and many changes apply without restarting the browser.

Building Firefox Enterprise

We needed to know that Firefox Enterprise worked in real environments, and to find the gaps, before customers depended on it. I helped structure that as an internal alpha first, followed by a customer pilot. Working directly with prospective customers showed us what deploying and supporting a browser in an organization involves. I also worked across the browser, Admin Console, infrastructure, and QA teams to manage dependencies and make scope trade-offs.

Here are two product decisions I pushed for.

Building DLP into the browser

For data loss prevention, the usual options are to buy a solution or partner with an existing vendor. I pushed for another option: building it into Firefox Enterprise ourselves. It was the harder path, but I think it was the right bet for two reasons.

First, checks and enforcement happen client-side. The browser evaluates the rules locally rather than sending content to a separate service to decide whether a paste, upload, download, or print is allowed, and DLP works without another agent to deploy. If you already run a DLP agent, you can connect it through Firefox’s existing Content Analysis integration, and Firefox defers to it and turns the built-in checks off.

Second, we keep control over what to build next. Owning DLP end-to-end means our roadmap isn’t blocked by anyone else’s.

Big thanks to Greg Stoll, who built the original Content Analysis integration that lets people hook Firefox up to third-party DLP agents. Greg’s experience with the policy surface and the browser internals was crucial for the built-in checks. Thanks also to Jonathan Mendez for the implementation and the work around it.

Describing policies with schema metadata

With more than 130 policies in the console, we needed something better than a text entry field for hand-written JSON, and designing UX for each policy doesn’t scale.

We already had a schema that describes policies, and my proposal was to make it the single source of truth describing policy capabilities, with enough information in it for multiple types of consumer. Practically, that meant adding richer data, including compatibility data, and using the schema to power a visual, form-based editor in the Admin Console.

The console reads the schema and renders the appropriate fields and validation, without anyone having to build a separate UI for each policy. Where a generated form needs extra care, we can override it with a custom editor.

Here’s an excerpt of the schema entry for the AIControls policy:

"AIControls": {
  "type": "object",
  "x-category": "Content settings",
  "x-compatibility": {
    "firefox": { "version_added": "149.0.2" },
    "firefox_esr": { "version_added": "153" },
    "firefox_enterprise": { "version_added": "149.0.2" }
  },
  // …

One schema covers all of those policies today, and a new policy gets a basic form by extending the schema rather than designing a new screen. People say the documentation is the product. In our case, the metadata is the product: like browser compatibility data, it also powers downstream documentation and enriches other products.

Who can run Firefox Enterprise

Firefox Enterprise is rolling out across Europe, with sales focused on France, Germany, Austria, and Switzerland to begin with. More markets will follow. You need an Admin Console to use it, so the way in is to request a demo.

More to come

Getting a first public release out is only the start of the work, and I’ll write more about the details as we go. If you run Firefox in your organization, or you’d like to and something is stopping you, I’d like to hear about it. You can get in touch on Bluesky or mail me.