What's the Deal With Enterprise Browsers?
In 1968, Robert Probst, research director for office furniture company Herman Miller, released an office design called the “Action Office II.” It was the culmination of almost a decade studying the psychological core of the corporate workspace. The Action Office II would provide privacy while still fostering communication. It would encourage workers to move more freely and adapt their space to their needs. Its innovative movable walls would make workers happier, healthier, and more productive than ever!
It was a daring, forward-looking plan, but below, we have a picture of what that plan looked like in the real world.
Yup. The Action Office II is now best known for giving us the dreaded cubicle. The bane of the modern office worker. The rat maze of the rat race.
The birth of the cubicle illustrates how workplace technologies often start as exciting ideas, but are then reshaped by managers, executives, and vendors who don’t actually have to use the technology.
By the time they’re done, the version of the tech that employees interact with rarely lives up to the original hype.
In the infosec space, enterprise browsers recently arrived on the scene as an innovative way to protect company data by funneling it through a secure, corporate-managed internet browser. But while the idea behind enterprise browsers is solid–many employees work primarily via browsers, so they should be kept secure–in practice, they tend to make employees feel a bit…boxed in.
Here, we’ll get into what these browsers promise to do, explore how they work in practice, and go over which use cases they’re best suited for.
What Are Enterprise Browsers?
Enterprise browsers are simply internet browsers that are centrally managed by an organization, as opposed to consumer browsers like Firefox, Safari, or Chrome, which are managed by individual users. Enterprise browsers give organizations a way of securing sensitive enterprise data, preventing unsafe or unapproved activity, and monitoring user activity.
When it comes to managing remote workers, there are various chokepoints where a team might try to monitor and secure data. VPNs do it at the network level, device trust solutions do it at the device level, and enterprise browsers do it at the (you guessed it) browser level.
The best argument in favor of enterprise browsers is security, given that the open internet is a pretty dangerous place these days. A user can inadvertently fall for malvertising, download shady browser extensions, and access unapproved Shadow IT tools.
Plus, we’re in an era dominated by web apps. A lot of employees can access everything they need for a whole workday without once leaving their browser.
With all of that in mind, it makes a lot of intuitive sense that IT and security teams want to exercise some control over this hugely important tool. But how?
The idea of giving companies some authority over workers’ browsers isn’t new; browsers like Chrome and Edge have had some security and policy management options built in since at least 2017.
But it wasn’t until late 2021 that the Island and Talon startups first offered the “enterprise browser,” browsers built specifically to secure enterprise data. These are secure browsers that employees must use to access certain sensitive web apps (in theory, an admin can ensure that you can’t access Salesforce from an unsecured browser).
After that, the enterprise browser market got really crowded, really fast. These products include browsers, as well as products designed to make regular internet browsers act more like enterprise browsers. Here are some of the popular enterprise browsers on the market today:
Surf Security’s “Zero Trust Enterprise Browser”
Mammoth Cyber’s “Enterprise Access Browser”
There are also products that operate more like browser extensions, including:
The number of enterprise browsers and related products that have sprung up in just a few years show that there’s clearly interest (and funding) in this space. And these vendors make big promises about the types of problems enterprise browsers can solve. Talon alone claims to “secure third-party access, replace VDI and DaaS, secure BYOD, and more.”
If they can do all that (and we’ll be digging more into the “if”) it explains why Gartner predicts that, “By 2030, enterprise browsers will be the core platform for delivering workforce productivity and security software.”
That’s a bold claim, but remember, Gartner made similar predictions about the metaverse. So before you order all your users to uninstall Firefox, let’s ask some follow-up questions.
How Do Enterprise Browsers Work?
Different enterprise browsers have different capabilities and employ different mechanisms to function. But on the whole, enterprise browsers have three major tactics to improve security and productivity: restriction, monitoring, and isolation.
Restrict
Enterprise browsers allow a company’s IT or security team to restrict what employees do in the browser. Some of the more common restrictions include:
Blocking employees from certain websites or systems.
Preventing employees from downloading or uploading malicious files.
Preventing employees from installing any shady extensions.
Requiring that the browser be updated.
Preventing employees from downloading, storing, screenshotting, screen-sharing, printing, copy-pasting, emailing, or even thinking about sensitive documents.
The reasoning behind these restrictions might be security or productivity. In other words, companies invest in enterprise browsers both to prevent data leakage and to prevent employees from slacking off on social media.
Most enterprise browsers let admins apply different policies according to different groups (contractors have one set of rules, engineers have another). Depending on the browser, policies can get more granular, like allowing employees to only download files that match certain Azure Information Protection tags.
Monitor
To enforce these restrictions and detect unusual activities, enterprise browsers monitor user browser activity.
Talon’s tools “observe web traffic in real-time.”
Island’s browser reports “rich details about the web activity, paired with contextual details like the user identity.” They also take screenshots as users browse.
To be fair, there are other tools that give companies these abilities. Google’s Workspace (including their browser) logs just about all user activity on their various apps, like Google Drive activity and Chrome chat conversations. VPNs monitor all network and browsing activity, and VDIs see everything that happens on their virtual desktop.
But regardless of who is doing this kind of monitoring, it’s important to recognize its potential for misuse and bad employee experiences. It’s a thin line between security tools and bossware, and no one wants to work for a company that won’t let them check their horoscope during their lunch break.
Enterprise browser developers are hardly unaware of the privacy issues. Some, like SURF, try to maintain privacy by “reporting only violations against corporate policies, without recording any personal browsing activities.”
Still, depending on those policies, admins could still get reports about an alarming chunk of browsing. And of course, a lot of enterprise browsers don’t even pretend to distinguish, proudly logging “any and all browser behavior.”
Some browsers, like Island, recommend that users simply have another browser for their personal use. Use the work one for work stuff, and the personal one for personal stuff. It’s simple! But that could cut into any promised productivity gains, since switching between two browsers is almost guaranteed to lead to “Increased Cognitive Load and Context Switching” and “fragmented workflows,” as Kasm puts it.
Also, if employees can use multiple browsers at will, then what’s the point in blocking non work-related websites in the first place?
Isolate
The most powerful capability of enterprise browsers is Remote browser isolation (RBI).
David Strom calls RBI a “sleight-of-hand trick.” As he reported for Silicon Angle, “When the browser is fired up, the user is transported to the vendor’s data center and runs a virtual session, or a complete Linux virtual machine so that any phishing or malware attempt can’t touch the endpoint.”
RBI is a doozy. If an employee tries to open a webpage, the page is first routed to a remote cloud server. That server then streams the webpage back to the employee’s device. The two options for this are:
A filtered mirror of the page. This option filters out some of the more suspicious content on the page and sends the rest back to the user.
A pixel-by-pixel reconstruction of the page that is rendered by the browser and streamed back to the user.
The goal here is that if an employee, say, clicks a link in a phishing email, then it doesn’t really matter. What the employee clicked is just a copy of that webpage, or a filtered out link that’s being streamed to their computer in real(ish) time. Any malware gets downloaded to an isolated server that can’t touch anything else at the company. Then, when the browser’s closed, everything’s gone.
When employees open sensitive web apps on their enterprise browser, then that app is never actually touching the endpoint. And even if they download malware via their personal browser, there’s no way for that malware to infect company systems–at least, not via the enterprise browser.
RBI is a concept that’s existed since at least 2017 (along with earlier versions that predate the cloud). It was initially used by government agencies like the Nuclear Security Administration and the Pentagon. And RBI is kind of the nuclear option when it comes to access control. It’s a very powerful addition to a zero-trust architecture, since it completely stops the browser from communicating with the endpoint.
It’s also…intense. Like a full suit of medieval armor, it makes it pretty hard to stab you, but it also slows you down. A lot.
And historically, RBI options have been painfully slow, expensive, and resource-hungry.
But what many enterprise browsers now promise is a product that uses the techniques of RBI without its sacrifices to usability.
Wow, “nuclear launch code” level security available for any old company without any drawbacks? Sounds pretty great. But wait…how does that make sense?
According to Island, “The Enterprise Browser achieves the same outcomes as RBI…but does so from within the browser itself. This means no added latency for the user.” But why or how would doing RBI from the browser remove the latency issue?
No, seriously, how do enterprise browsers work?
I wish this were an easier question to answer, but very few enterprise browser developers are willing to provide much detail about their behind-the-scenes processes. And for a product that accesses a lot of sensitive company information, we might appreciate a little more transparency.
When I reached out to David Strom, the writer of the Silicon Angle piece, about how he established that these browsers use RBI, he told me: “You can track the originating packets from these browser environments and see that they come from a different TCP/IP network that is geographically distant from the user’s own location. You can also do some browser canvas fingerprinting to get more details.”
What that means is that most enterprise browsers (at least the ones David tested) are using some version of the back-and-forth method of RBI. And RBI is a process that’s going to involve latency. When you route browsing to another server, wait for it to generate a perfect pixel-by-pixel replica of each page, and then wait for it to stream that copy back to your computer, it’s just not going to be that zippy.
It’s possible that enterprise browsers use the mirror rendering RBI option. That one’s less secure, but also faster. It’s also possible that they do some other twist on RBI. SURF’s option, for instance, doesn’t work through the cloud, but provides an “Isolated work environment…locally on the endpoint, by encrypting, sandboxing and rendering content.” Talon’s browser does similar web encryption. But rerouting, encryption, sandboxing, rendering–all of these things, by definition, take more time and processing power than just opening a web page does.
Now, let’s acknowledge that every security tool creates some friction or leads to some loss in performance. In some ways, security is friction! It’s just that there’s a limit to how much a tool can inconvenience its users while still justifying its value to security.
“No added latency” strikes us as an impossible promise. But if enterprise browsers can at least achieve “manageable amounts of latency,” it could still be enough for them to even the scales between RBI’s security benefits and usability costs. Assuming, of course, that they are otherwise pretty user-friendly.
This means that the first question security professionals should ask when considering enterprise browsers is: what’s it like to use them?
What is it Like to Use Enterprise Browsers?
Unfortunately, this is a very difficult question to answer. Because when it comes to enterprise browsers, end-user reviews–positive or negative–are almost bizarrely hard to find.
We can find glowing reviews from C-suite members, but no testimonials from employees.
For instance, one CISO testing Island said, “users aren’t pushing back on it at all.” But that claim seems a little dubious given that his firm has “purchased 4,000 seats, though just 100 employees have so far downloaded.”
Even on Reddit, very few people are talking about enterprise browsers. Still, here are the most common complaints we could find:
(Lack of) speed: One reddit user, in regards to Island, says, “My company uses it and everyone complains that it is slow af.”
Demanding on CPU: Another reddit user says that when their company required an enterprise browser, “it required so much processing power that my 8gb ram laptop was completely unusable. Ended up getting a top of line Mac instead…the bottom line is it slows things down…”
Time-consuming to set up: “talon and island would become a nightmare to manage 100s and thousands of users, cuz each dep/team has different reqs.”
Still, Reddit being the unverified source that it is, we wanted to test these claims ourselves.
The original title of this piece was going to be, “What It’s Like to Use Enterprise Browsers.” If I couldn’t find end-user reviews, I’d make my own. I’d get an enterprise browser demo, have our admin apply some policies and restrictions to my browsing, and then I’d try it out for a week and see how it went.
It did not go well.
Demo attempt 1: Chrome for Enterprise
By and large, enterprise browser vendors don’t offer demos unless you’re actively in the sales process, and they’re (perhaps understandably) not inclined to do favors for blog writers. But, good news! Chrome for Enterprise has a free trial. Since we already use Google products at Kolide, this seemed like the most low-lift, user-friendly option.
I started getting that trial set up with Antigoni, Kolide’s Head of Ops and Google admin. For the experiment to work, she’d have to play panopticop and start monitoring and restricting my Chrome browsing.
“I don’t want to do that!” she said.
Like many normal people, she found the idea of monitoring someone’s browsing to be weird and creepy. I, too, found the idea of having my browsing monitored to be weird and creepy.
Nonetheless, we were willing to make that sacrifice. For you, the reader.
When it comes to Chrome enterprise management, there are two options:
Chrome Browser Cloud management, which lets Chrome admins manage and monitor enrolled Chrome browsers.
Chrome Enterprise Upgrade, which adds additional features to manage device posture on ChromeOS devices.
We don’t use ChromeOS at Kolide, so Antigoni and I started with Chrome Browser Cloud Management. This service is free for companies that already use Chrome browsers.
I expected it to be fairly simple. Robert Shield, Director of Engineering, Chrome Enterprise, made things sound easy enough in this podcast, talking about how much admins could do with “all with these built-in controls in the browser.”
It wasn’t simple.
As our head of ops, Antigoni has ushered Kolide through processes as complex as achieving SOC 2 certification. She’s no slouch at managing rollouts. But Chrome’s cloud management instructions and documentation are labyrinthine, often outdated, and (in my professional opinion), poorly written and difficult to follow.
We enrolled in the trial for Chrome’s paid “Enterprise Upgrade,” thinking that even though it’s geared toward Chromebooks, it might still offer simplified processes for enrolling browsers.
Not really.
The most significant challenge we came across, quite early on, was adding me to my own group. We very much did not want to roll out monitoring and restrictions to everyone at Kolide, especially without their knowledge. We tried creating a new gmail address, re-registering my Chrome, creating a child organization within Kolide, and a host of other things to try to get me, one little writer, monitored.
But in the end, this fundamental early step of the process stymied us. And looking through Chrome’s documents for applying policies, it was clear that each individual policy would require its own fair share of busy-work; some are as easy as flicking a switch, some require some light coding, and some are just tedious. (They also let you stop users from playing the dinosaur game when Chrome is offline, which just feels cruel.)
We gave it a good faith effort, but after a couple of hours of frustration, we gave up. It would be too much of a trial to get this trial going. We needed to devote that time to more important things, and Antigoni had a spanakopita in the oven.
Demo attempt 2: Red Access
Setting up Chrome for Enterprise was a bust (and we aren’t the only ones who feel that way). But Google’s enterprise browser option probably isn’t the top priority of a company with so much else going on.
Next, I got a Zoom product demo from a vendor focused exclusively on browser security: Red Access.
Naturally, no vendor is going to show off their flaws in their own demo, but deploying Red Access seemed much easier than what we saw with enterprise Chrome, with some pre-set policies, advised blocklists, and toggles for different SaaS apps.
It’s worth noting that, technically, Red Access isn’t an enterprise browser. Their promise is to “turn any browser into a secure enterprise browser” through what the CEO called an “injectable agent that gets presence on the endpoint during the session.”
Essentially, their option is an agentless combination between the abilities of an SSE and an enterprise browser. In practice, this means that browsing is only rerouted from within certain browser profiles.
Your work Chrome profile will launch a virtual remote session even while your personal profile stays unmonitored (to the point that two Chrome windows, open on the same device, access data from different IP addresses). They also don’t do RBI proper, instead rerouting browsing with something more akin to a lightweight corporate VPN.
Red Access isn’t necessarily representative of enterprise browsers as a whole, and they were eager to highlight some of their competitive advantages, such as:
Unimpacted streaming speeds.
Lightweight CPU requirements.
They don’t see the security patch delays of other enterprise browsers (most of which are built on Chromium).
That final point is worth repeating. The majority of these browsers are built using Chromium. Unlike Chrome itself, Chromium often requires manual patching. As Gregg Keizer wrote for Computerworld, “The omission of an update service is the single greatest security threat to Chromium.”
What Are the Potential Use-Cases for Enterprise Browsers?
From what we can tell, enterprise browsers have somewhat limited use-cases. They’re expensive (as opposed to consumer browsers, which are free), time-consuming to maintain, and, it’s safe to assume, unpopular with end users.
To even start considering enterprise browsers, you need to clear a couple bars:
They make the most sense for workers who do most or all of their jobs via the browser. This means that they’ll rarely work for a whole company’s workforce, since many workers (like developers) have to use standalone programs with no web apps.
They’re much more useful for managing remote employees than on-prem. The problems they solve are typically already solved on the network level, or are just less of a concern, in an on-premises environment.
For companies with those needs, the question is: when is this option worth considering? And when is it still not worth it?
To replace VDI, DaaS, or VPN
Virtual desktop infrastructures (VDI), desktop as a service (DaaS), and virtual private networks (VPNs) all solve some of the same problems that enterprise browsers do. VDI and DaaS work similarly to enterprise browsers in terms of creating a sandboxed work environment, but they apply to multiple applications, not just the browser. VPNs create secure tunnels through which data is encrypted and inspected. All three secure cloud data and make some provisions around how employees can access sensitive information.
They also come with some of the same drawbacks; they monitor user activity and often slow down internet speed as well.
In terms of trading one of these for an enterprise browser, it will come down to your security needs, your end-users, and your budget (it’s hard to find consistent price estimates for enterprise browsers, but they are likely a cheaper option).
Contractor devices
Evginiy Kharam, a CISO, told the Adopting Zero Trust podcast, “right now I feel the perfect use case [for enterprise browsers] is the part-time contractor.”
Imagine, for example, a company that outsources customer service to a call center. These call center workers only need to do a few, repetitive tasks, which they can accomplish via the browser alone. Issue a fleet of Chromebooks equipped with the Chrome enterprise browser, and you’ve basically got security covered for those workers.
They’re similarly useful with third-party vendors–assuming they agree to use them. This could prevent attacks like the one made against Boston hospitals, where hackers first hacked an HVAC vendor who had hospital blueprint copies floating around in their systems. An enterprise browser could have prevented the vendor from downloading that file in the first place…though they may have objected that they needed to download it in order to do their job.
Of course, all these use cases only work if we assume you have a successful deployment and are able to ensure that workers can only access company resources via the enterprise browser. That shouldn’t be a huge hurdle if you have Google as your identity provider, and Chrome as your browser and OS, since those products are designed to be integrated. But if you’re using Okta for identity, Island as your browser, and macOS, you should make sure these disparate systems will play nicely together.
BYOD
Most of these browsers (save obvious exceptions like Microsoft Edge for Business) are platform-agnostic. That means that they’re genuinely useful for managing a varied BYOD scenario, since you don’t have to manage a whole fleet of devices, just the browser. In a couple of podcasts, hosts and experts discuss how these browsers could let employees hop onto their kid’s school chromebook to get a few things done in a pinch.
However, just because you can use enterprise browsers this way, doesn’t mean you should. Overly lax BYOD policies can bring a lot of security issues, and you’d be hard-pressed to find an enterprise browser saying they should be your only point of security. In the call with Red Access, for instance, they fully admit that their solution should be combined with other tools, like firewall and device authentication. “Cybersecurity works in layers,” as they put it.
Generally, letting people access company systems on otherwise unsecured devices could make it a bit too easy for threat actors, especially if logging into the browser requires nothing but phishable, credential-based authentication.
Productivity
We highly doubt that these browsers will improve employee productivity. You’ll be lucky if they don’t hinder it.
Employees (even contractors) are adults who know what they need to be productive. And it’s pretty telling that Google’s enterprise policies are the same ones used to monitor school chromebooks. Treating employees like literal children isn’t likely to boost morale (or productivity).
You can’t justify invasive monitoring by expecting people to totally compartmentalize their personal and work activities on separate browsers; that’s just not how people work. And monitoring employees damages productivity and general well-being precisely because people resent a workplace that doesn’t trust them.
Bottom line: at some point you have to trust the people you hired to do their jobs. If you’re concerned about productivity, there are other ways to measure it (like how much work they get done). And if you’re concerned about unsafe behaviors on the browser, there are ways to block unsafe browser extensions and detect malware that let users maintain more agency and privacy.
Security training
On the Security Weekly podcast, Robert Shield from Chrome Enterprise described a policy to get around “employee frustration.” With this policy, certain actions like downloading or printing will be “automatically approved” once employees request permission and fill out a log.
If actions are reaching the point of auto-approval, you’re not worried about stopping malicious users. This kind of policy is clearly aimed more to reinforce employees’ best data practices and encourage them to be thoughtful about what they download and print (it could also annoy them a lot).
Island claims to provide security education “at the moment it’s relevant,” by providing “a clear message explaining why the action was prevented. Showing this type of information in context…makes it more effective than alternatives like a company-wide email message.”
We agree with the spirit of this claim, but Island’s example leaves much to be desired.
“We are pleased to offer you to use…” isn’t what we call the clearest message. This also feels less like education on why AI is risky, and more like a reminder that “we’re watching you.”
In general, the restriction and monitoring aspects of enterprise browsers are more likely to annoy your good employees than to stop a truly determined bad actor.
For instance, a policy against screenshots could remind a well-intentioned remote employee that they shouldn’t have copies of sensitive docs floating around on their device. But a malicious insider can get around this by simply taking a picture of their computer screen with their phone.
Not to mention, it’s not like education requires invasive monitoring. At Kolide, we’re pretty proud of our ability to educate employees about security while still enforcing a lot of data principles and posture checks.
And we do it without monitoring browsing history.
Enterprise Browsers Are Rarely Worth It
Before the 1960s, offices were inspired by factory floors. Regimented rows of desks were crammed so tightly together that employees bumped shoulders as they worked. Only managers had private offices, with large windows to let them peer out over their workers.
This is the environment that inspired the “movable privacy walls” of Robert Probst’s cubicles. But what that bold design taught us was that “kind of private” isn’t the same as “actually private.” And, that companies are a little too eager to cram employees into boxes.
Enterprise browsers suit specific uses. RBI is a powerful tool for companies that really want to secure data that passes through web apps. And focusing security at the browser level is a simple and cost-effective approach for large teams of remote workers who only need the browser to do their jobs (like in the call center example).
But for the average organization, the drawbacks of enterprise browsers are too extreme, the benefits are too few, and the products are too opaque and untested to justify tampering with such a vital tool.
Want more original and curated stories about IT and security? Subscribe to the Kolide newsletter.
