Skip to content
← Back to Learn
Gotcha12 Jun 2026· 4 min read

The Endpoint DLP bypass nobody talks about is finally closing

Data Loss Prevention

If a file was never saved to disk, Endpoint DLP could not scan it. Type sensitive data into a new document, save it straight to USB, and no policy fired. Just-in-time protection and the new unsaved file protection close the gap.

The gap

Microsoft's own documentation states it plainly: if data is never saved to a file on the local device, Endpoint DLP cannot scan or classify it.

The bypass this creates is embarrassingly simple. Open a new document, paste in the customer database, and save it directly to a USB stick or network share without ever saving locally. Classification never ran, so no policy fired. The same applies to an existing file with fresh unsaved edits: the sensitive content added since the last save is invisible until autosave or a manual save lands.

Anyone who has run a DLP validation exercise knows this one. It has been the standard demonstration of endpoint DLP's limits for years.

What just-in-time protection does

Just-in-time protection holds egress activities on files that have not been evaluated yet, or whose evaluation has gone stale, until policy evaluation completes. Covered egress includes copying to removable media, copying to a network share, printing, RDP transfers, Bluetooth apps, clipboard (audit by default), and uploads to restricted cloud domains.

It works on Windows 10 and 11 and the three most recent macOS versions.

There is a useful offline behaviour too: with JIT in block mode, a new file created on an offline Windows device stays blocked from sharing until the device reconnects and evaluation completes. The window where offline devices simply could not be evaluated now defaults to caution instead of allowing the transfer. macOS does not get this offline behaviour.

What unsaved file protection adds

JIT protection still needed a saved file to evaluate. Unsaved file protection, currently in preview, extends audit and block to files that have never been saved at all, and to saved files carrying unsaved modifications, including the window before autosave completes.

The scenarios it covers read like the bypass playbook: a new file in a non-Office app saved straight to USB, an edited file saved direct to a network share, a file opened from removable media and updated in place, and even dragging a file out of an archive straight to USB without extracting it locally first.

The user experience differs by action. Print is blocked with a notification telling the user to save first. Copies to USB and network shares need auto-quarantine turned on, which intercepts the file into a protected location and leaves a placeholder. Office apps get a save-as block with a prompt to save a copy and try again.

Rolling it out without pain

Microsoft's own guidance is the right one: start with audit, scoped to a few users. Unsaved file events are a category you have never seen before, and you want to know the volume before anything blocks. Expand the scope as the numbers make sense, then flip the same scope to block.

The practical checklist:

Check the antimalware client version. Unsaved file protection needs 4.18.26040 or later on the device.

Decide on auto-quarantine before enabling block for USB and network share copies, because those scenarios depend on it.

Know your toggles. Unsaved file protection and unclassified file protection are separate features with separate switches under Settings, Data Loss Prevention, Just-in-time protection. You do not need one to use the other.

Update your validation script. If your security testing still relies on the save-as-to-USB trick, it is about to stop working, which is the point.

Design and test DLP policies with What If scenarios before enforcing anything.

Plan your DLP policies

Plan this in a tool

Free planners to design and test this before you deploy. No login.