The USB stick, the print job, the clipboard, the browser upload, all of them are visible to it. Anything that was never written to a file is not.
This carries Purview data loss prevention onto Windows 10 and 11, the supported Windows Server builds, and the three most recent macOS releases. One documented limit ought to shape your whole policy design: where data is never written to a file on the local machine, there is nothing for Endpoint DLP to scan or classify.

- 12 activitiesUSB, print, clipboard, browser, RDP and more
- Windows and macOSPlus supported Windows Server versions
- User and deviceBoth must be in scope for enforcement
- Defender onboardingAlready-onboarded devices appear automatically
Eight things worth knowing before anybody writes the first rule.
Removable media, with forensic detail
A copy onto removable media can be blocked outright, warned on, or simply recorded. What makes this activity worth understanding is the evidence trail behind it, which is unusually detailed: the activity type, where the file was written, when, its name, extension and size, which sensitive information type matched, both the SHA1 and SHA256 hashes, the application that did the copying, and the manufacturer, model and serial number of the drive itself. That final detail is what lets an incident become an actual investigation.
Browser uploads and unallowed browsers
Uploads heading to a restricted service domain get blocked, warned on or audited according to your allowed and unallowed domain lists. Where the browser itself is not permitted, the documented behavior is that the upload is stopped and the person is redirected into Microsoft Edge, which then makes the allow or block decision by policy. Pasting into a supported browser is watched separately, and the evaluation runs against the pasted content itself rather than against however the source file happened to be classified.
Clipboard, with a behavior worth knowing in advance
Set to Block, or Block with override, and copying is stopped whenever the source content is sensitive, with one exception: pasting into the same Microsoft 365 Office application is allowed. A second behavior generates far more support calls than the first. While a file covered by a blocking rule is open, copying from any other file inside that same application is restricted too, including files that carry no rules at all.
Print, network shares and virtual desktop paths
Printing and copying to a network share each carry the same three options, block, warn or audit. Both extend into Azure Virtual Desktop with Windows 365, which brings redirected printers, redirected clipboards and redirected USB devices presenting themselves as network shares into scope. Any American business running virtual desktops for contractors should look hard at those redirected paths, because they are consistently the routes nobody thought about.
Bluetooth, RDP and restricted applications
Three further activities are watched: copying into a Bluetooth application that is not permitted, copying or moving over RDP, and access by anything on the restricted apps list. RDP coverage exists on Windows and, according to the published table, does not exist on macOS. Creating a file and renaming a file can both be audited but neither can be restricted, which makes them evidence for an investigation rather than a means of prevention.
Classification happens on create, modify and read
Every time a file is created or changed, it gets a full scan for sensitive information types and labels, then gets evaluated against your policies and rules. Reading a file that has already been classified works differently: the service checks whether the policies, rules or sensitive information types have changed, re-evaluates if they have, and does not go back and re-extract the text. Knowing that distinction is what keeps performance discussions grounded in fact.
Offline behavior, which differs by platform
Take a Windows machine offline and the policies it already holds keep being enforced against the files already on it. Just-in-time protection running in block mode still stops a newly created file being shared until evaluation can complete once the device reconnects. Any policy you changed while it was away does not reach it until it comes back, and the older policy stays in force until then. On macOS none of this offline behavior is supported.
Servers are supported, with three real caveats
Windows Server 2019 and later can be onboarded, though onboarding alone does not switch Endpoint DLP on for a server. There is a further wrinkle worth planning around: installing the supported Windows Server updates turns off the classification feature on that server, so anything created afterwards goes unclassified while files classified before the update keep their protection. Domain controllers and Core Server installations are outside support entirely.
A file saved directly onto a USB stick never passes in front of Endpoint DLP at all.
It is stated plainly in the documentation, and no other limit on this product matters as much. Working around it is a question of policy design rather than of configuration.
- The wording is unambiguous. Where data is never written to a file on the local device, there is nothing for Endpoint DLP to scan or classify. The example given is somebody opening a document in Word and saving it straight onto a USB device without it ever touching the local disk.
- Which means the removable media rule cannot stand on its own. Something has to govern the hardware as well as the file, and that something is Defender for Endpoint device control for removable storage. The documentation sends you there deliberately.
- Every other exit route where data never lands on local disk has the same problem. Build your coverage assumptions on file activity alone and the hole will sit precisely in the scenario that worried you enough to buy the product.
- What works in practice is three layers doing different jobs. Device control decides whether removable storage can be used at all. Endpoint DLP governs what happens to files that genuinely exist on disk. And sensitivity labeling keeps the classification attached to the document wherever it ends up.
Four things that determine whether this survives its first week in front of real users.
We watch before we block
Here is a detail worth exploiting. Once a device is onboarded, audited activity starts arriving in Activity Explorer before you have configured a single policy with devices as a location. That window of free visibility is the most valuable phase of the whole project, because it shows you which exit routes people genuinely use, and that set almost never matches what anyone predicted in the planning meeting.
We get the scoping right, both halves of it
Two statements in the documentation sit next to each other and explain most of the confusion we get called in to untangle. The first is that enforcement on an endpoint requires both the user and the device to be in scope. The second is that every device onboarded into Purview gets scanned whether or not the user is in scope, on the grounds that one machine can carry several accounts.
It gets deployed alongside device control instead of being sold as complete on its own
Since data that never touches local disk is invisible to Endpoint DLP, removable media needs something underneath it. The documentation points at Defender for Endpoint device control for removable storage, and the sensible split is that device control settles whether the port works at all while DLP handles the content of files that genuinely exist on the machine.
The policy tips get as much attention from us as the rules themselves
As far as your staff are concerned, the policy tip is the product. Business justification within those tips works on Windows and on macOS, and written well it turns a block into a decision the person records and stands behind. Written badly it produces a ticket, then an exception, then a permanent gap in your coverage.
Six US situations where endpoint DLP is the right control.
A financial firm under GLBA and FTC Safeguards obligations
Customer financial data sitting on an analyst laptop is entirely legitimate. The same data uploaded into a personal cloud storage account is not. Browser and domain restrictions, driven by your allowed and unallowed service domain lists, address that gap directly, and the handling of unallowed browsers pushes people into Edge where the policy can actually take effect. Firms under NYDFS Part 500 end up with exactly the monitoring evidence their filings already claim exists.
A consulting firm in the last week of a client engagement
No window carries more risk than a consultant working their notice with entirely legitimate access to client material. Three paths matter: copy to USB, copy to a network share, and print. The evidence captured on a USB copy runs all the way down to the serial number of the drive, and that level of detail is what makes an investigation conclusive instead of merely suggestive.
A healthcare provider handling patient records
Clinical staff have to print, and they have to move files between systems that were never built to speak to one another. A blanket block collapses within a day. What works is rules that understand content, warn mode carrying a business justification, and audit-only on the routes that are genuinely necessary to patient care. That gives clinicians something they can work with and gives a HIPAA security risk analysis something concrete to cite.
An engineering business protecting drawings and designs
Design files often arrive in formats that DLP cannot classify by looking at their content, which is where the file extension and unsupported file extension controls earn their place, along with restricted app groups. The archive formats that are monitored happen to cover the usual exfiltration wrapper, since nobody copies a folder full of drawings without zipping it first. For manufacturers in the defense supply chain, the same evidence supports what CMMC and NIST 800-171 expect around media protection.
A company running virtual desktops for contractors
Bring in Azure Virtual Desktop or Windows 365 and you inherit redirected clipboards, redirected printers and redirected USB devices that appear to the system as network shares. All three are covered. Businesses that adopted virtual desktops precisely to contain contractor access have usually never checked whether those particular routes were closed.
An organization preparing for a SOC 2 or data protection audit
What Activity Explorer gives you is a record of what genuinely happens to sensitive data on your endpoints, and that answers an auditor far better than a policy document ever will. Since auditing starts the moment devices are onboarded, that record can already exist before anybody has decided what to enforce.
How US organizations control data leaving endpoints.
| Feature | Endpoint DLP with policy | USB blocked, nothing else | No endpoint controls |
|---|---|---|---|
USB copies controlled by content | Yes | Blanket only | No |
Browser uploads controlled | Yes | No | No |
Printing controlled | Yes | No | No |
Clipboard controlled | Yes | No | No |
Network share copies controlled | Yes | No | No |
Virtual desktop redirected paths covered | Yes | No | No |
Activity visible before enforcement | Yes | No | No |
Forensic detail on an incident | Yes | Minimal | None |
Users told why they were blocked | Yes | No | Not applicable |
Business disruption | Managed | High where USB is needed | None |
Twelve activities, and which ones you can actually block.
Activity
Upload to restricted domain or unallowed browser
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable and restrictable
Activity
Paste to supported browsers
- Windows
- Supported
- macOS
- Preview
- Auditable or restrictable
- Auditable and restrictable
Activity
Copy to clipboard
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable and restrictable
Activity
Copy to USB removable device
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable and restrictable
Activity
Copy to a network share
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable and restrictable
Activity
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable and restrictable
Activity
Copy or move using unallowed Bluetooth app
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable and restrictable
Activity
Copy or move using RDP
- Windows
- Supported
- macOS
- Not supported
- Auditable or restrictable
- Auditable and restrictable
Activity
Create an item
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable only
Activity
Rename an item
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Auditable only
Activity
Access by restricted apps
- Windows
- Supported
- macOS
- Supported
- Auditable or restrictable
- Detection of access attempts
Activity
Create Windows Recall snapshots, in preview
- Windows
- Supported on x64
- macOS
- Not supported
- Auditable or restrictable
- Auditable and restrictable
Five steps, and it is the phase spent watching that produces most of the value.
- 1
Onboard devices and turn on monitoring
Devices already onboarded through Defender for Endpoint turn up in Purview on their own and need nothing beyond device monitoring being switched on. Everything else comes in one of five ways: a local script for up to ten machines, group policy, Configuration Manager 1610 or later, Intune, or the VDI scripts written for non-persistent machines. Windows servers are the exception, needing Endpoint DLP explicitly enabled after they onboard.
- 2
Watch Activity Explorer before writing rules
Audited activity arrives before any device-scoped policy has been written. We spend that period working out which exit routes are genuinely in use, who is using them and how often. That is the difference between a policy set built around your business and one lifted from a template.
- 3
Design narrow policies with correct scoping
We begin with a single clearly defined sensitive information type against a single activity, rather than switching on everything and hoping. Enforcement needs both the user and the device inside policy scope, so both get verified rather than assumed. The policy tip wording and the business justification text are written at this stage, not added afterwards once complaints start.
- 4
Run in audit, then warn, then block
Activities graduate one at a time instead of moving as a block. For routes the business genuinely depends on, warn with business justification is frequently the right permanent setting, since it captures a decision without halting anybody. Block gets reserved for the paths that have no legitimate purpose at all.
- 5
Operationalize the alerts and the exceptions
Alerts get reviewed in the DLP alerts dashboard or investigated through Defender XDR, false positives reach somebody with the authority to change the rule, and every exception carries a named owner and a review date. We also verify that the offline behavior and the server behavior actually match what your policy assumes, because both differ from the ordinary online Windows workstation.
What US organizations ask about Endpoint DLP.
Fifteen checks that stand between a rollout and a full support queue.
Coverage
- Which devices are already Defender-onboarded?They appear in Purview automatically.
- Are macOS devices in scope?Three latest major versions, and RDP is not covered.
- Any Windows servers in scope?Not domain controllers, not Core installations.
- Is device monitoring turned on?Onboarding alone is not enough.
- Is Azure Virtual Desktop or Windows 365 in use?Redirected paths are covered.
Scoping
- Which users are in policy scope?Policies are scoped to users.
- Which devices are in policy scope?Both must match for enforcement.
- Are shared devices handled?A device can carry several users' policies.
- Which sensitive information types matter?Start narrow and specific.
- Are labels part of the condition?Labels and types can both trigger.
User experience
- Block, warn, or block with override?Override needs a justification design.
- Are policy tips written in plain language?The tip is the whole user experience.
- Does the clipboard behavior need explaining?Same-app restriction surprises people.
- Who handles a false positive?There will be some in week one.
- Have you told users before enforcing?Silent blocking generates tickets, not compliance.
The pages around this one.
DLP solutions
Data loss prevention seen across email, cloud and endpoints without tying it to one vendor.
Microsoft Purview
The classification and labeling suite endpoint policy conditions draw from.
Defender for Endpoint
The onboarding route most estates already own, plus the device control that covers everything DLP is unable to see.
Put a pilot group through onboarding, then read what your own staff are already doing.
Because audited activity arrives in Activity Explorer before a single policy exists, the first useful output costs you nothing beyond a little time. Nearly every organization spots at least one exit route in that data that had never occurred to anyone.
Related Services
Explore more solutions that work great with this service
DLP Solutions
Data Loss Prevention implementation for US businesses via Microsoft
Learn moreMicrosoft Purview
Data governance and compliance solutions
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreEndpoint Security
Endpoint security for US businesses using Microsoft Defender for
Learn moreMicrosoft Security Services
The Microsoft security stack deployed and managed end to end
Learn moreIT Compliance
HIPAA, SOC 2, NIST, CMMC, CCPA readiness
Learn more