The browser is EDR's blind spot: where endpoint tools stop and browser controls start

EDR watches what runs on a device, including processes, files, scripts, and the changes they make. Many of today's attacks never do any of that. They happen inside a browser session the end user legitimately opened, on real websites, using the browser exactly as designed. To EDR, a phished login, a stolen session, and company data pasted into a personal AI account looks like an end user browsing the web. That's not a flaw in EDR. It's a different layer, and it needs its own control.

What does EDR actually see?

EDR is built around the operating system. It records which processes start, what launched them, what command lines they ran, which files and registry keys they touched, and which network connections each process opened. It's very good at spotting malware running, ransomware encrypting files, attackers moving between machines, and tools that try to persist. No MSP should run without it.

Now look at the browser from EDR's point of view. It sees chrome.exe or msedge.exe, a signed and trusted process, opening encrypted connections to hundreds of websites all day. With web protection turned on, it can see which domains those are, and some suites can list the extensions installed. What it generally can't see is which tab made a request, which account the end user was signed in to, what they typed, what a page displayed, or what an extension did inside that page. All of that lives inside the browser, above the level EDR watches.

For years that didn't matter much, because the valuable data lived on the device and attacks had to run code there. Now the valuable data lives in SaaS apps, the browser is how end users reach it, and attackers have followed.

Which attacks slip past EDR?

The ones that never need to run anything on the device. Five patterns account for most of them.

Real-time phishing kits. The end user lands on a fake sign-in page that relays everything to the real one, completes MFA, and hands the attacker a live session. Nothing is downloaded or installed. These kits are sold as a service at enormous scale. Before Microsoft and Europol disrupted it in early 2026, a single kit, Tycoon2FA, was sending tens of millions of phishing messages a month that reached more than 500,000 organizations.

Stolen sessions replayed elsewhere. Once the attacker has a session cookie, they use it from their own machine. The client's EDR never sees the replay because it doesn't happen on the client's device.

Consent and device-code phishing. The end user is tricked into approving an attacker's app or entering a code on a real Microsoft page. The attacker gets ongoing access straight from the identity provider, and resetting the password doesn't remove it. Again, nothing runs locally.

Malicious browser extensions. A hijacked or malicious extension runs inside the trusted browser process, reading pages and cookies and sending data out over normal HTTPS. There's often no new executable to flag.

Data leaving through legitimate apps. An end user pastes client records into a personal AI account or uploads a file to personal cloud storage. Verizon's 2026 breach report found that 67% of users accessing AI services on company devices did so with non-corporate accounts. To EDR, that's an approved browser talking to a popular website.

In every case the device is healthy. The risk is in what happens inside the session.

Where does EDR stop and browser security start?

Think of it as two layers with a thin overlap. EDR owns the device. Browser controls own the session, meaning which sites end users reach, which accounts they use, what extensions do, and where data goes once it's on screen.

The overlap is where the most instructive attacks live. In a ClickFix attack, a web page tricks the end user into pasting a command into Windows. The browser sees the lure but not the command. EDR sees the command but not the page that caused it. Each layer catches half the story, which is exactly why you want both.

How should MSPs layer EDR and browser controls?

The goal isn't another console full of alerts. It's covering the session layer with as few new moving parts as possible, and feeding it into the workflow you already run.

1. Keep EDR doing what it's good at. Don't stretch it to cover the browser, and don't let a browser tool talk you into dropping it. Infostealers, ransomware, and the payload half of ClickFix still land on the device.
2. Close the session gaps in order of impact. For most clients that means phishing-resistant MFA and compliant-device requirements first, so sessions are much harder to steal. MFA doesn't stop device-code or consent phishing, so block device-code sign-in and restrict user app consent where clients don't need them. Then block lookalike sign-in pages, control which extensions can run, and separate personal from business accounts on AI and file-sharing apps.
3. Start in warn mode, then block. Browser controls touch what end users do all day. Warning before blocking shows you what's normal for each client and keeps the help desk quiet while you tune.
4. Send browser alerts where EDR alerts already go. One ticket queue, one triage process. A visit to a ClickFix lure page next to an EDR alert for a suspicious PowerShell command is a much clearer story than either alone.
5. Be honest with clients about coverage. "We run EDR" is a strong answer about devices and an incomplete one about SaaS data. Showing where each layer stops makes the case for the browser layer better than any statistic.

Browser security platforms such as Atakama are built for this layer, with allow, warn, and block decisions on sites, separating personal from business sign-ins, controlling pastes and uploads to unapproved apps, and sending alerts into the PSA, set per client from one console. Whichever tool you choose, judge it on whether it covers the session without adding a second job for your technicians.

FAQ

Does EDR stop browser-based attacks?

It stops the ones that run code on the device, such as a malware download or the command a ClickFix page tricks an end user into running. It generally can't see attacks that stay inside the browser session, like a phished login, a replayed session cookie, or data pasted into a personal AI account.

Is browser security a replacement for EDR?

No. They cover different layers. EDR watches processes and files on the device. Browser security watches sites, accounts, extensions, and data inside the session. Most MSP clients need both.

Is browser security the same as endpoint DLP?

Not quite. Endpoint DLP focuses on sensitive files and content leaving the device, and some tools can watch or block uploads of sensitive files in supported browsers. Browser security works at the session level, covering which site, which account, which extension, and what happens on the page. They overlap on uploads and pastes, so check which one you rely on for each.

What is browser detection and response?

A term some vendors use for tools that detect and respond to threats inside the browser, the way EDR does for the device. The category is still settling, so judge tools on what they actually see and control rather than the label.

Why can't EDR see a stolen session being used?

The attacker replays it from their own machine. Nothing happens on the victim's device, so there's nothing for the victim's EDR to record. Identity risk detection can flag a replayed session, and revoking sessions shuts it down.

Keep reading

For more on attacks that start in the browser, see why MFA alone doesn't stop session hijacking, how ClickFix and fake AI installers work, how browser extension takeovers work, and our pages on phishing protection, credential theft prevention, and extension management.

Sources

• Verizon, 2026 Data Breach Investigations Report
• Microsoft Security, Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale, March 2026
• Microsoft Security, From cookie theft to BEC: attackers use AiTM phishing sites as entry point to further financial fraud, July 2022