A few years ago, the question "how do we give this person access?" usually had one of two answers. Either they got a managed laptop, or they got a virtual desktop. Today a growing share of access requests come from people who will never get either: contract developers, offshore support teams, agency partners, seasonal staff, and employees who want to check something from a personal tablet. The device belongs to someone else. The work still belongs to us.
For a lot of that work, the application is a SaaS app or an internal web app. Which means the browser, not the desktop, has become the place where corporate data actually shows up on screen. That shift is why secure enterprise browsers have moved from a niche category to something nearly every security team I talk to is evaluating.
The Numbers Behind the Interest
Gartner's Market Guide for Secure Enterprise Browsers, published in February 2026, predicts that "by 2028, 25% of organizations will augment existing secure remote access tools" with at least one secure enterprise browser technology, "up from approximately 10% today." It also reports roughly 100% year-over-year growth in client inquiries about the category between 2023 and 2025 (summary via Palo Alto Networks).
The word that matters in that prediction is "augment." This is not a story about browsers replacing VDI or VPNs. It is a story about adding a lighter option for the access cases where a full virtual desktop is more than the job needs.
Matching the Tool to the Job
The most useful thing I've seen teams do is stop treating access as a single decision and start sorting it by what the user actually does. In my experience, most access requests fall into a few buckets:
Web and SaaS only. A partner who needs a ticketing system, a wiki and a dashboard. Giving that person a full Windows desktop is expensive and slow to provision, and the experience is worse than a native browser tab. A managed browser with copy, paste, download and print controls covers the real risk.
Legacy or thick-client apps. Anyone who needs a Windows application that will never be rewritten for the web still needs a published app or a virtual desktop. A browser can't run what isn't a web app.
High-sensitivity data on any device. When the data must never leave a controlled environment, regardless of how the app is delivered, VDI or DaaS is still the cleanest answer. Pixels go out, nothing else does.
Most organizations need all three. The program work is deciding which bucket each user population belongs in, and being honest when a group has been given more (or less) than it needs because that was the only option available at the time.
What Goes Wrong in Rollouts
Browser-based access looks simple on a slide. In practice, the rollouts I've watched struggle tend to trip on the same few things.
Policy written in a vacuum. Security drafts a policy that blocks clipboard, downloads and printing for every app. Then the finance contractors discover they can't export the report they were hired to reconcile. Policies need to be set per app and per user group, and the people who do the work should see them before launch.
Ignoring the help desk. A new browser is a new thing to support. Users will call when a site breaks, when an extension won't install, or when single sign-on loops. If the support team hasn't seen the product before launch day, every one of those calls turns into an escalation.
No exit path for edge cases. Some users will genuinely need more than the browser can give. If the only way to get a virtual desktop is to restart a six-week request process, those users will find a workaround, and you're back to shadow IT. A clear, fast path from "browser access" to "full desktop" keeps people inside the governed options.
Measuring the wrong thing. "Number of users onboarded" is easy to count and says little. Better signals are time from request to working access, the number of policy exceptions requested in the first month, and how many users ask to move to a different access tier.
The Program Management Angle
Secure access projects sit across more teams than most people expect. Identity owns single sign-on and conditional access. Security owns data loss policy. The end-user computing team owns the desktop and app delivery side. Procurement and vendor management own the contractor agreements that say what a partner is allowed to do in the first place. Legal has opinions about monitoring personal devices, and those opinions vary by country.
None of those teams can deliver the outcome alone, which is exactly the kind of problem a TPM exists to solve. The work I'd focus on is less about the browser itself and more about the seams: a shared user-segmentation model that everyone agrees on, a single intake path for new access requests, and a review cadence where policy exceptions get looked at as a group rather than one ticket at a time.
I'd also push for a small, real pilot before any broad rollout. Pick one contractor population with mostly web-based work, set up the browser with draft policies, and run it for a few weeks. You will learn more from twenty frustrated contractors than from any vendor demo, and you'll learn it while the blast radius is small.
Where This Is Heading
The pattern I expect is layered access: managed browsers for web work, published apps and virtual desktops for everything else, and identity and device posture deciding which one a user gets on a given day. That is more moving parts than "everyone gets a laptop," but it fits how organizations actually staff work now.
The teams that do this well won't be the ones with the most restrictive policies. They'll be the ones who know their user populations, give each group the lightest tool that covers its real risk, and keep watching whether that choice still fits as the work changes.