Some time ago we published a post arguing that the browser is the most dangerous app sitting on most endpoints. It’s where users spend most of their day and the entry point for most malware delivery, yet it’s usually the least governed piece of software in the environment.
That post ended with a quick note about a new product in development to address exactly that gap. Today we’re putting a name to it: Web Access Management, a new addition to the Admin By Request Zero Trust Platform. You can read more about it here.
This post is about what Admin By Request Web Access Management does, and where it fits alongside the tools you already have. Whenever we introduce it to CISOs and security architects, the same question usually comes up: how is this different from what my EDR is already doing? It’s a fair question and it deserves a proper answer, so that’s most of what’s below.
The Short Version
Web Access Management is a policy-and-authorization layer for web browsing and executable downloads, enforced directly on the endpoint by the Admin By Request agent. It governs:
- Which browsers users can run, and at which minimum versions
- Which sites users can access, which are blocked, and which require approval
- Whether executable downloads are allowed, need approval, need a stated reason, or are hard-denied outright
- Whether MFA or Intune compliance is required before a download is released
- Whether downloads are restricted to the device owner
- How files are scanned for malware through OPSWAT MetaDefender before being released to the user
Policy is set centrally in the Admin By Request Portal and enforced at the endpoint, so it follows the device whether the user is on the corporate network, at home, or on hotel Wi-Fi. No proxy, DNS filter, or firewall changes required.

How Web Access Management Works
Many web security products run in the network path, inspecting traffic between the user and the internet and returning a verdict before the request completes. That approach depends on traffic passing through the inspection point, which is a reasonable assumption for office-based users and a less reliable one for remote workers, contractors, and anyone connecting from networks you don’t control.
Web Access Management takes a different approach. The Admin By Request agent, already installed on endpoints as part of our Endpoint Privilege Management solution, handles enforcement locally based on policy pulled from the portal.
When a user tries to browse to a site, the agent evaluates it against the current policy: is this site blocked, pre-approved, or subject to approval rules? When a user tries to download an executable, the agent intercepts the download flow, holds the file in a staging area, checks it against pre-approval rules, blocked rules, MFA requirements, Intune compliance status, and malware scanning, and only then releases it (or blocks it, or quarantines it).
The file does land on the endpoint during this process. It doesn’t sit on a cleaned copy served from a remote sandbox, and it isn’t a reconstructed “safe version” of the original. It’s the actual file, held briefly while policy is evaluated, and released to the user only if policy says yes.
That distinction matters for two reasons. First, users get the genuine software they asked for, not a defanged approximation of it. Second, there’s no dependency on a cloud gateway staying up for users to get work done.
Where It Fits Alongside EDR/XDR
Back to the question CISOs ask us most often: how is this different from what my EDR is already doing?
Short answer: it’s solving a different problem at a different point in the timeline.
EDR and XDR platforms are built around telemetry, detection, investigation, and response. They watch what happens on your endpoints, flag suspicious behavior, correlate signals across devices and identities, and give your SOC the tools to investigate and respond when something goes wrong. That work is indispensable, and our new product is not a replacement for it.
Web Access Management operates earlier in the timeline. It’s asking a different question: should this activity be allowed to happen in the first place? Not “did this file behave maliciously after it ran” but “does this file meet the conditions we’ve set for executable downloads on managed endpoints?”
Imagine it as three layers working together. Web Access Management decides what’s allowed in: which sites, which downloads, under what conditions. Endpoint Privilege Management decides what those downloads can do once they’re on the machine, specifically whether they run with elevated rights. EDR/XDR decides what to do about anything that still gets through: detection, investigation, response.
Each layer handles a job the others are less suited for. A mature security program benefits from all three.
Governing Downloads Without Governing Productivity
The obvious objection to download approval workflows is that they create friction. If every executable download requires a ticket and a human reviewer, IT drowns in approval requests and users find ways around the system. It’s a legitimate concern and one we’ve thought about hard.
Admin By Request Web Access Management handles it in a few ways.
- Pre-approved rules let you whitelist trusted sources without touching users at all. Rules can be based on source URL, specific file checksum, vendor certificate, or a combination of vendor and application name. Developers pulling regularly from GitHub, finance teams using well-known accounting software, IT staff deploying vetted utilities: all of this can flow without an approval step.
- AI-based auto-approval uses application and vendor popularity scores to clear downloads that meet a configurable threshold. A download of widely-used, well-reputed software doesn’t need a human in the loop every time.
- Machine learning auto-approval watches what your admins have manually approved in the past. Once a given application has been approved a defined number of times, future requests for it clear automatically. Your approval decisions teach the system, and the system reduces your workload over time.
The downloads that actually reach a reviewer are the interesting ones: unusual, new, from unfamiliar sources. That’s a very different day than approving Zoom installers for the hundredth time.
Different Rules for Different People
Web Access Management uses a sub-settings model that will feel familiar to anyone already running our Endpoint Privilege Management solution. Global policy acts as the baseline, and specific groups of users or devices can be given their own overrides without duplicating configuration.
A finance team might require approval and MFA for every download. IT staff might have broader latitude and a separate pre-approved list. Shared or kiosk devices might run with browsing restricted to pre-approved sites only and downloads disabled entirely except for the assigned owner.
Each population operates under rules appropriate to its risk profile, and none of it requires separate deployments or separate tenants.

What This Looks Like in Practice
The case for Web Access Management for most security leaders comes down to a simple question: do you know, right now, what your users are downloading and from where, and do you have a policy mechanism to change that answer?
If the honest reply is ‘the EDR will flag anything that behaves badly,’ that’s a detection-based posture. It’s a valid layer, but it leaves you reacting to problems rather than preventing them, and it leaves your users free to install software your organization never approved.
This solution gives you the control layer to shift that posture. You decide:
- which browsers are acceptable, and at which versions
- which sites are off-limits
- which downloads need approval, which need MFA, which need a stated business reason, and which are denied outright
You also get a full audit trail of every decision the system made and every action your users took.
All of this runs on the same agent already handling privilege elevation for your endpoints, managed from the same portal, using the same approval flows your admins already know. For existing EPM customers, turning on Web Access Management doesn’t need any new deployments.
Learn More
Head to this page for the full rundown. Once Web Access Management is generally available, you’ll be able to try it on up to 25 endpoints through our Free Plan, with no time limit and no feature restrictions.

