Purview DLP or Session Controls: Which Layer Each One Can Actually Reach

The question arrives as a procurement question and it is not one. Somebody has been told that Defender for Cloud Apps can stop downloads to unmanaged devices, somebody else has a Purview DLP programme already running, and the meeting is about which one to buy. On a Microsoft 365 E5 tenant you already own both, and the real question is which layer each of them can reach.

They are not alternatives, and as of 2026 they are not cleanly separated either. Purview DLP is content-aware and lives inside the services, the endpoints and the browser — and it now reaches the browser download that used to belong to session controls alone. Session controls are session-aware and live in the access path, between the identity provider and the app. Each one can still see things the other cannot, and each has documented ceilings. Where they overlap, the Purview managed-app browser policy might not apply. If you choose the Purview path, Microsoft instructs you to exclude those users from overlapping Defender session policies and Endpoint DLP policies for the same managed apps. This article is about all three of those sentences, with the limits printed.

The short answer, before the detail

If you take nothing else from this article, take the three sentences below. They answer the question in the meeting.

Almost every architecture argument I have watched about these two products was really an argument about that third sentence, conducted by people who each had half the requirement in their head.

The two control layers

Both products describe themselves in a line, and the two lines say plainly that they are doing different jobs.

Microsoft Purview DLP "can help protect your organization against unintentional or accidental sharing of sensitive information", and it does so by reading content: "DLP uses deep content analysis—not a simple text scan."

Conditional Access App Control, the feature inside Defender for Cloud Apps that most of this article is about, "enables user app access and sessions to be monitored and controlled in real time based on access and session policies". It reaches that position architecturally: it "uses a reverse proxy architecture and is uniquely integrated with Microsoft Entra Conditional Access".

Where each one intervenes

Three interception points, and the path only runs one way. A file downloaded from a third-party SaaS app to a personal laptop passes layer 2 and nothing else. A file copied from a labelled document onto a USB stick on a corporate laptop passes layer 1 and nothing else. Layer 3 reaches third-party SaaS only through a Defender for Cloud Apps connector, and at rest only in preview.

What the reverse proxy does to the request

It is worth being concrete here, because the mechanism explains most of the limitations later on. When a session is routed through Conditional Access App Control, the app's URL is rewritten — "if the app URL is myapp.com, the app URL is updated to myapp.com.mcas.ms" — and the service "modifies underlying application code". It then "uses patented heuristics to identify and control user activities in the target app".

Two consequences follow directly, and they are the two that surprise people.

First, nothing is installed anywhere: "Conditional Access app control doesn't require you to install anything on the device, so it's ideal when you're monitoring or controlling sessions from unmanaged devices or partner users." That is the whole reason the control exists, and the reason it answers the unmanaged-device question rather than DLP.

Second, it is rewriting somebody else's application. Heuristics against a third party's markup is a fragile place to stand, and Microsoft documents where it breaks: named apps lose deep links, drag-and-drop uploads over-block, and built-in client apps fall outside session control. Those are not teething problems. They are properties of the approach, and they are the reason the limitations section below is the longest in this article.

Which apps each one reaches

The most persistent myth about session controls is that they only work with apps in Microsoft's catalogue. Eligibility is a protocol test, not a catalogue lookup: controls apply to "any interactive single sign-on that uses the SAML 2.0 authentication protocol", to "any interactive single sign-on that uses the OpenID Connect authentication protocol", and to apps published through Entra application proxy. Entra ID apps "are also automatically onboarded".

The catalogue decides something narrower and still important: "only catalog apps have out-of-the-box session controls." For anything else you onboard the app yourself and register its domains, and until you do, "file downloads by the app from domains not associated with the app won't be blocked and the action won't be audited in the activity log". A half-onboarded app is not a half-protected app. On any domain you have not registered it is unprotected, and it still looks protected in the portal.

Purview DLP's reach is a published list of locations rather than a protocol: Exchange Online email, SharePoint sites, OneDrive accounts, Teams chat and channel messages, Devices, on-premises repositories, Fabric and Power BI, Microsoft 365 Copilot in preview, and — the row that matters here — Instances: Microsoft Defender for Cloud Apps. The two products are already wired together at that point, and the wiring is about to change direction.

The comparison that matters

Capability tables of the "feature | product A | product B" shape are not much use here, because the two products do not have overlapping feature lists. What they have is different answers to five questions. These are the five.

Three actions, and what each one actually does

The action list is the fact that reframes the whole comparison, so it is worth quoting in full rather than summarising. A session policy can do exactly three things:

• Audit — "Monitors all activities. Select to explicitly allow download according to the policy filters you set."
• Block — "Blocks file downloads and monitors all activities."
• Protect — "Applies a sensitivity label to the download and monitors all activities. Available only if you'd selected Control file download (with inspection)."

Protect is the interesting one and the one people over-promise. It works on a fixed file-type list — the Office formats and PDF — "PDF files must be labeled with unified labels", it "doesn't support overwriting files with an existing label in session policies", and crucially "the original file remains as it was in the cloud app while the downloaded file is protected". The same control can also "apply custom permissions to the user downloading files, or block the download of specific files". So Protect is protection applied to a copy on the way out. It does not touch the source.

Both use the same classification engine, and that surprises people

A session policy set to Control file download (with inspection) can inspect the file, and it does so with Purview's engine, not a separate one. Microsoft is explicit: you "choose inspection type by selecting the Sensitive information types", you "can also reuse any of your Microsoft 365 custom sensitive information types", and you "can configure your policy to use advanced classification types such as Fingerprints, Exact Data Match, and trainable classifiers". The framing sentence is: "Microsoft Data Classification Service provides a unified information protection experience across Microsoft 365, Microsoft Information Protection, and Microsoft Defender for Cloud Apps."

Two operational notes that do not appear in the marketing. The Data Classification Service inspection method "is only available for the Control file download (with inspection) option" — so uploads get the older Built-in DLP engine. And the integration is regional: "currently available in the US, Europe, Australia, India, Canada, Japan, and APAC", with the instruction that "if the feature isn't available in your region, use the Built-in DLP inspection method".

Which means the honest version of "they use the same SITs" is: on downloads, in supported regions, yes. Anywhere else, no.

When both could act on the same event

There is one documented precedence rule and it is easy to miss, because it lives on a Defender page rather than a Purview one: "Endpoint DLP policies are prioritized and applied if the same context and action are configured for the Endpoint policy and either a Defender for Cloud Apps session policy", and "the Endpoint DLP policy takes priority and is applied".

Between two session policies, "the more restrictive policy wins".

And there is a place where Microsoft's own navigation sends you to two different products for the same job. The Entra Conditional Access session page offers to "Enforce this control with Microsoft Defender for Cloud Apps" and, in the next breath, "For Microsoft Edge for Business, enforce this control with Microsoft Purview Data Loss Prevention". Same screen, same intent, two products. The tiebreaker is the endpoint-DLP precedence sentence above, and it is buried on a third page.

Licensing, which is where the architecture question becomes a procurement one

Only in one direction, and only below E5.

I have not found a Microsoft sentence saying you need both products, and on a Microsoft 365 E5 seat the question dissolves: DLP including endpoint, Defender for Cloud Apps and Entra ID P1 all arrive together. Office 365 E5 is not the same tier here — it carries neither Defender for Cloud Apps nor Entra ID P1, and the Teams chat DLP entitlement column is blank for it. Below Microsoft 365 E5 the two things that bite are the Entra ID P1 requirement for every user in scope of a session policy, and the fact that the two most useful DLP surfaces, endpoint and Teams chat, sit at the higher tier.

One dependency is worth tracing because it crosses the boundary. The Protect session action applies a Purview sensitivity label, and "Sensitivity labels are configured in Microsoft Purview and must be configured to apply encryption for it to appear as an option". So the Defender action depends on Purview configuration, and automatic client-side labelling carries its own entitlement on top. A session policy that labels downloads is three products deep before it does anything.

Five scenarios, and which control answers each

This is the table I actually use in a workshop. The column that earns its place is the last one, because in one row both products answer and interfere with each other, and in another neither answers cleanly.

What the user sees, which decides whether the control survives contact

One user-experience difference is worth calling out because it decides your helpdesk load. DLP has a documented middle gear — block with override, with a captured justification — in Exchange and on devices. Not in Teams, where the documented action list has one entry and "No policy tips are shown for files". Session controls do not. The three actions are audit, block and protect; there is no "block but let them proceed and tell me why". If your rollout method depends on that middle gear, and the validation approach I use for DLP does, then the session-control equivalent has to be built out of audit mode and patience instead.

Where they join, and where the gaps stay open

Two things are true at once: the products are converging at the data plane, and the gap between them at the session plane is not closing.

The convergence: file policies retire on 6 January 2027

If you have documentation that says third-party cloud app DLP is delivered "via Defender for Cloud Apps integration", that sentence is now pointing the wrong way. I have such a sentence in an earlier piece of my own and it needs correcting: the connector is still Defender's, but the policy is becoming Purview's.

What the retirement does not touch is session policies. They are a different object doing a different job, and nothing in the 2026 release notes suggests otherwise. Which brings us to the more awkward observation.

The ceilings, and the switch that decides what happens above them

This is the part of session controls that most deployments discover in production. There are two size limits and they are different numbers.

Microsoft publishes a worked matrix for the inspection ceiling that is worth reproducing mentally: a 1 MB text file with a million characters is scanned; a 2 MB text file with two million is not; a 4 MB Word file with 400,000 characters is scanned; the same 4 MB file with two million characters is not; and a 40 MB Word file with 400,000 characters is not. Three of those five are refused for a reason that has nothing to do with how much sensitive data is in them.

The consequence is that your policy has a fail-open or fail-closed decision in it, whether or not you made it deliberately. Turn on Always apply the selected action even if the data cannot be scanned and every oversized file and every encrypted-label file is blocked. Leave it off and they pass. There are two switches, not one: the per-policy setting decides files between 30 and 50 MB, and the tenant-wide Default behavior under Settings > Conditional Access App Control decides everything above 50 MB — except under Edge in-browser protection with the always-apply setting on, where anything over 50 MB is blocked outright. Three behaviours from two switches and a browser.

The limitations that decide whether this works in your tenant

I would read the known-issues page before designing anything, not after. The ones that change designs:

• Non-interactive tokens punch a hole between related apps. "the Teams client can get a non-interactive token for SharePoint and start a session in SharePoint Online" and "The user isn't asked to sign in again, so session controls can't intercept or enforce policies." The fix is to onboard the whole suite: "onboard all related apps, such as Teams, alongside SPO."
• The Teams desktop client is not covered. "Session controls, such as Block download (preview), don't apply to the Microsoft Teams desktop application", and "If desktop access is allowed, users might be able to download content through the Microsoft Teams desktop application, even when browser session controls are configured." Microsoft's own remedy is blunt: block native clients and allow only browsers.
• B2B guests in Teams are excluded outright. "Session policies don't protect external business-to-business (B2B) collaboration users in Microsoft Teams applications." That is precisely the population most people buy the control for.
• IPv6 silently disables IP rules. "Access and session policies support IPv4 only. If a request is made over IPv6, IP-based policy rules aren't applied." Both paths, proxy and in-browser.
• Drag-and-drop over-blocks. Microsoft's example: "A user tries to upload a selection of 200 nonsensitive files by using a drag-and-drop operation. | Files are blocked." Through the upload dialog instead, "Nonsensitive files are uploaded. Sensitive files are blocked." Same policy, opposite outcome, decided by how the user picked the files.
• Deep links are lost in named apps. Under the proxy, "browsing to a link might result in loss of the link's full path. Typically, the user lands on the home page of the app" — documented for ArcGIS, GitHub, Power Automate, Power Apps, Workplace from Meta, ServiceNow, Workday, Box and Smartsheet. Under in-browser protection, a user switching from another browser gets the same outcome: "the user is directed to the application's homepage in Microsoft Edge."
• Enforcement can outlive the policy. "When a session policy is enforced using Microsoft Edge in-browser protection and the user is later removed from the corresponding Conditional Access (CA) policy, the original session enforcement may still persist" — "due to cached policy data". The documented remedy is to delete mda_store.1.txt from the user's Edge profile, or the work profile itself. Per machine.
• Policies are application-scoped, not file-scoped. "Conditional Access policies are applied at the application level, not at the individual file level. As a result, you can't exclude specific files from the policy settings." This is the sharpest structural contrast with DLP, which is file-scoped by design.
• Google Workspace is out under in-browser protection. "Google Workspace isn't supported with in-browser protection in the Enterprise Microsoft Edge browser", and in Google Workspace "real time DLP files scans aren't supported" with upload, download, cut and copy unsupported.
• Built-in apps and browser extensions get access control, not session control. "It doesn't currently support built-in apps or browser extensions" — "You can choose to either allow access or totally block it." Access controls do reach them: "Built-in apps can be detected heuristically and you can use access policies to monitor or block them." This limitation applies only to reverse-proxy sessions.

And the eight conditions that send a session back to the reverse proxy even when you have deployed in-browser protection: Chrome users; Edge users scoped to a protect-file-download policy; Edge on Android; apps authenticated through OKTA; Edge InPrivate; older Edge versions; B2B guests; and sessions scoped to a Conditional Access policy defined in the Entra portal. Plus the catch-all: "Users that are served by multiple policies, including at least one policy that's not supported … their sessions are always served by the reverse proxy."

Two things Microsoft says that contradict each other

Worth knowing so you do not design around the wrong one.

End-user block emails. The session policy page still says "Block policies also allow you to select to notify users by email", and offers a customisable block message. The release-note archive says: "Effective October 1, 2024, we'll discontinue the feature that notifies end users via email when their action is blocked by session policies." Design for the block page and the replacement file, not for an email.

Preview status, which is genuinely hard to pin down. Several of the capabilities in this article are labelled inconsistently across pages, and the labels move. Here is what the pages said when I checked them, which is the most I would claim:

The distinction that matters most: the Defender in-browser protection layer is in preview, while the Purview DLP policies that ride on it are not labelled as such. Two different objects, two different statuses, one browser. Read the label on the page that documents the feature, not the label on the page that links to it.

The decision tree

Six questions, per requirement rather than per tenant. Question 2 is the one that saves the most time, because it eliminates the product people usually start with.

Question 6 is the one that turns an architecture discussion back into a procurement discussion, and it is the only place where it belongs. On Microsoft 365 E5 the answer is yes, which is why the "which product" framing is usually the wrong question. On Office 365 E5 it is not, and that catches people who assume the two are the same tier.

A phased pattern that limits the blast radius

Four phases. The order matters because the failure modes are different: a DLP mistake generates tickets, a session-control mistake generates lockouts.

• 1ScopeOne app, one group
• 2RouteAccess policy, audit only
• 3InspectSession policy, audit
• 4EnforceBlock, one activity at a time

Phase 1 — scope, and exclude the session controls app. Pick one application and one pilot group. Before anything else, check every existing block-all Conditional Access policy for the session controls application and exclude it. Confirm the pilot users have Entra ID P1. Confirm the app appears on the Conditional Access App Control apps page, remembering that "Entra ID apps only appear on the Conditional Access App Control apps page after they're configured in at least one policy".

Phase 2 — route the traffic with an access policy set to Audit, and change nothing else. The point of this phase is to find out whether the app survives being proxied. Watch for the failure signatures: an App is not recognized page, an Unrecognized domain prompt, lost deep links, a broken certificate chain. If the app is in the catalogue this phase is usually uneventful. If it is not, this is where you find out what you signed up for.

Phase 3 — add a session policy in Audit, and accept that you are not monitoring much. Remember the Monitor-only trap: to see activities beyond sign-in you need at least one block-per-activity policy alongside your monitoring policy. Decide the always apply switch deliberately in this phase, with a real oversized file and a real encrypted-label file, so the fail-open or fail-closed behaviour is a decision and not a discovery.

Phase 4 — enforce one activity at a time. Downloads first, because that is the scenario with a clear user story and a clear message. Print and copy afterwards. Uploads last, because the drag-and-drop over-blocking is the behaviour most likely to look like a bug to a user who is doing nothing wrong.

Three policies, and what the user actually experiences

Concrete configurations rather than patterns, because the user experience is the part that gets missed in a design document.

Policy 1 and policy 3 are the same session control type with a different action, and they behave completely differently under load. Policy 3 falls back to the reverse proxy even for Edge users, because a protect-file-download policy is one of the eight documented fallbacks. If your reason for deploying in-browser protection was to get rid of the proxy, a Protect policy quietly puts it back.

Validating it, and knowing where to look afterwards

Test both controls with the same four outcomes, because a matrix that only records blocks tells you nothing about the false positives you are creating.

The last row is the one people skip and the one that produces the incident. Both products behave differently on content they cannot read, and in both products the behaviour is a setting rather than a default you can assume.

Where the evidence lands, and for how long

Two latency figures worth writing into the runbook. DLP policies "take effect about an hour after being turned on", and alerts have their own clock: "It may take up to 3 hours to generate alerts after you configure or modify existing alerts in a DLP policy." For the MDCA activity log there is no published ingestion SLA at all — the documentation says only that it is updated constantly. Do not put a number on it in a runbook you will be held to.

One asymmetry to design around: MDCA records "activity names and types exactly as received" and "doesn't define or modify them", which makes its log excellent for reconstructing a session and poor for aggregating across apps. DLP records the matched condition, the matched value and the surrounding text, which is the opposite trade. If your requirement is "show me what left", start with DLP. If it is "show me what this user did in that app for the last hour", start with the activity log.

Frequently asked questions

Can Purview DLP block a download to an unmanaged device?

Yes, on one path. The Managed cloud apps location with Restrict browser and network activities > File download > Block does exactly that, and Microsoft publishes the walkthrough. The conditions are the point: it runs in the Edge for Business work profile only, it needs Conditional Access App Control and in-browser protection configured first, and "The DLP policy won't be applied in Edge until all requirements are met." It does not need the device onboarded. Outside Edge, or outside the work profile, the answer is still a session policy or SharePoint's own app-enforced restrictions.

Do session controls work with any SaaS app?

Eligibility is a protocol test: interactive SSO over SAML 2.0 or OpenID Connect, plus apps published through Entra application proxy. But only catalogue apps get out-of-the-box controls; anything else you onboard yourself, and until the app's domains are registered, downloads from unregistered domains are neither blocked nor audited.

Does the proxy slow things down?

Microsoft's own statement is "In general, any proxy adds latency", with no figure published anywhere. In-browser protection is described as delivering apps "without latency or app compatibility issues". If you see a specific millisecond number quoted, it is not first-party.

Does a session policy use the same sensitive information types as DLP?

On the download path, in supported regions, yes — including custom SITs, fingerprints, exact data match and trainable classifiers, through the Data Classification Service. Uploads use the older Built-in DLP inspection method, and so does any region where the Data Classification Service integration is not available.

If both could act on the same event, which wins?

Endpoint DLP. "the Endpoint DLP policy takes priority and is applied" when the same context and action are configured in both. Between two session policies, "the more restrictive policy wins".

Is monitor-only a safe way to pilot session controls?

It is safe and it is nearly blind. "The Monitor only session control type monitors only the Login activity." To see anything else you need at least one block-per-activity policy running alongside it, which is a different risk profile from the one people think they are choosing.

What happens to files that are too big to scan?

Session controls: above 50 MB the tenant default decides, regardless of your policy — unless in-browser protection and the always-apply setting are both on, in which case it is blocked. Between 30 and 50 MB the file is not inspected and the always-apply setting decides. Purview DLP is per-location: two million characters of extractable text and three nested levels apply everywhere, the 64 MB figure is published in the endpoint conditions, and Microsoft does not publish a managed-cloud-app file-size limit in that reference — which is not a guarantee that none applies. Both products need you to decide, explicitly, whether unscannable means allowed or blocked.

Are Defender for Cloud Apps file policies going away?

Yes, on 6 January 2027, with file-based protection moving to Purview. Session policies are a different object and are not part of that retirement. If your design uses MDCA file policies to protect data at rest in a third-party app, that is the part to migrate.

Do I need both licences?

I have not found such a sentence, and on Microsoft 365 E5 the question does not arise — Purview DLP, Defender for Cloud Apps and Entra ID P1 all arrive together. Office 365 E5 is a different answer: no Defender for Cloud Apps, no Entra ID P1. Below that tier the constraint people trip on is the Entra ID P1 requirement for every user in scope, and that endpoint DLP and Teams chat DLP sit at the higher tier.