1. BitLocker recovery keys living somewhere you don’t control
You encrypted the disk. Good. Now ask the harder question: where does the recovery key actually go? On an Entra-joined, Intune-managed device, the key baclup to Entra ID and you can retrieve it centrally.
Open Entra → Devices → Device settings and find “Restrict users from recovering the BitLocker key(s) for their owned devices.”
Out of the box it’s set to No — meaning any user can browse to myaccount.microsoft.com, open their device, and read their own recovery key whenever they like.
De facto, that means every user can decrypt their own device — and a decrypted drive has no defences left. they can pull the disk, mount it on another machine, and copy everything off it. Or they boot into a recovery/offline environment, sidestep Windows entirely, and promote themselves to local admin. From there, every control further down this list is theirs to switch off.
2. Local admin rights = No security
This is where the previous point lands. If your users are local administrators, everything else on this list is optional from their point of view. A local admin can stop services, tamper with the Defender or DLP agent, and disable the very controls you’re relying on. Your policy is only as strong as your users’ inability to switch it off.
Use Windows LAPS to rotate and back up the local admin password automatically — See my Baseline Configuration here
3. Mobile Devices – Endpoint DLP doesn’t live there
This is the big one people miss. Endpoint DLP runs on Windows. Your iOS and Android devices? Those policies do not apply. Your users are reading, downloading and forwarding corporate data on phones where none of your endpoint controls exist.
The answer isn’t Endpoint DLP — it’s a Mobile Application Management (MAM) strategy. App Protection Policies in Intune are what stop save-as to personal storage, block copy-paste out of managed apps, prevent backups, and require encryption inside the app container, all without enrolling the whole device.
Do this: Build App Protection Policies for Outlook, Teams, OneDrive and Edge on both platforms. Pair them with Conditional Access so corporate data only opens in protected apps. Treat mobile as its own DLP perimeter, because it is one.
4. Auto-Forwarding Rules
A user sets an inbox rule: “forward everything to my Gmail.” Now your entire mail flow for that person is replicating to an account you’ll never see, and no label or DLP policy fired because the user had legitimate access to every message.
Do this: Block automatic external forwarding with an outbound anti-spam policy and/or a transport rule. Audit existing forwarding and redirect rules — you’ll usually find a few surprises. Alert on new ones.
5. Unmanaged and BYOD devices reaching your data
Don’t use the Block Downloads Policy to block users from downloading data from BYOD machines. There is an easy bypass for this explained here –> https://github.com/MicrosoftIsDumb/Defender-for-Cloud-Apps-Proxy-Bypass
Do this: Use app-enforced restrictions in Conditional Access to give unmanaged devices browser-only, no-download access. Let them read in the browser; don’t let the file leave it.
Go to Sharepoint navigate to Policies -> Access Control -> Unmanaged Devices
Just exclude iOS and Android from them: those platforms are covered by your MAM / App Protection policies instead, and you don’t want the two approaches fighting each other.
One gap remains. Even with downloads blocked, users can still pull attachments and full emails out of Exchange Online through Outlook on the web. To close that, set OWA to read-only for these sessions:
Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -ConditionalAccessPolicy ReadOnly
Ontdek meer van Rockit One
Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.