Microsoft Purview DLP | Browser & Web Protection

In the past, data security was simple: You put a firewall or proxy at the perimeter and blocked URLs like dropbox.com or wetransfer.com . When the traffic left the corporate tunnel, it was controlled. This model is architecturally dead today.

Why? In a world of "work from anywhere", your clients are often located outside the company network. A VPN is not a permanent guarantee, and modern protocols such as DNS-over-HTTPS (DoH) or QUIC make it increasingly difficult for classic network appliances to inspect traffic in depth. Therefore, control must move directly to the point of origin of the data: to the end device and to the browser.

Microsoft Purview Endpoint DLP starts right here: Instead of cracking the encrypted tunnel, it latches directly onto the operating system (Windows 10/11) and the browser. The system understands the context of an action – such as copying credit card data into a web form or uploading a classified file to an unsanctioned cloud – before encryption takes effect. You build a logical security barrier that travels with the device, regardless of the network it's on.

Here's the architecture of how to configure this "Last Mile of Defense".

Before you even define a single rule, you need to understand the infrastructure. The most common misconception is looking for a dedicated "DLP agent". There is no such thing.

Microsoft Purview Endpoint DLP leverages Microsoft Defender for Endpoint (MDE) as a launcher. In concrete terms, the service MsSense.exe is the eye and ear of the system. For your architecture, this means that you have to onboard the devices in MDE, even if you don't use Defender as your primary antivirus protection.

If you are already using a third-party EPP (Endpoint Protection Platform), you must not simply "arm" MDE, as two real-time scanners would block each other.

Manual onboarding via local script is only acceptable for POCs (Proof of Concepts). In production, Microsoft Intune (Endpoint Manager) is the default way because it enforces state cyclically.

A green tick in the portal is not enough for an architect. The latency between onboarding and visibility in the compliance portal can be up to 24 hours. Therefore, check directly on the client whether the heartbeat works.

To do this, run the following PowerShell command on the endpoint (or via remote shell):

In addition, you check whether the device is properly registered in the Entra ID (Azure AD), as DLP policies are often based on user and device groups. To do this, use:

In the output, pay attention to AzureAdJoined : YES and WamDefaultSet : YES. If the connection is missing, the policy cannot be synchronized from the cloud controller to the client.

Architecture Note: As soon as the onboarding is complete, the client pulls the so-called "policy blob" in the background. This is relevant locally under C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection (path may vary depending on the OS build). If users complain that a new rule doesn't take effect yet: The sync cycle is asynchronous. Restarting the Senseservice can force the pull.

This is where the worlds differ. Microsoft Edge is an "enlightened app", it understands DLP natively. Chrome and Firefox, on the other hand, are "blind" to the operating system. As a result , we have to build a bridge so that Purview can see what's happening in the tab.

DLP must not be a lawnmower. You don't want to block every upload (or legitimate business apps won't work), you only want to block uploads to unsafe destinations.

Now let's put the components together. A policy in the endpoint context does not check the contents of the file on the server, but the action with the file on the client.

A hard block without explanation generates tickets. The UX must educate the user ("nudging").

Implementing Endpoint DLP in the browser is one of the most powerful levers to get a grip on "Shadow IT" without completely nailing the device shut. You move the security boundary from the unreliable network perimeter directly to the data layer.

Technically, the solution is elegant because it is built on top of Windows' native APIs. Unlike heavy 3rd-party DLP agents, which dig deep into the kernel and often cause blue screens or performance issues, the "performance tax" here is minimal. Since Edge has natively integrated the engine and Chrome only uses a lean extension, browser performance remains stable.

Architect Warning:

Never start directly in block mode. You don't know all the web services that your departments use. A "silent audit" over 2-4 weeks is mandatory. Analyze the logs in the Activity Explorer: What data goes where? Often, you'll discover legitimate business processes (e.g., a marketing agency that receives data via Dropbox) that you need to whitelist before lowering the barriers.

DLP is not a project that you "turn on" once. It is a process of continuous refinement. But with browser integration, you close one of the biggest exfiltration holes of modern IT architectures.