TL;DR
- A compliance policy that requires BitLocker doesn't turn BitLocker on. It only checks. You still need a disk-encryption configuration policy assigned to the same devices.
- Encryption takes time. Set the Mark device noncompliant action to a 1–3 day schedule (the "grace period") so devices that are still encrypting aren't flagged right away.
- "Noncompliant" doesn't wipe or lock anything unless you add those actions. Keep them off during the pilot.
- Don't put a require compliant device Conditional Access policy in front of a fleet that's still encrypting. Free rollout checklist: Conditional Access Rollout Checklist.
You turned on a Windows compliance policy that requires BitLocker. Within an hour, half the pilot shows noncompliant. Helpdesk assumes the policy is "broken." The users are fine; their drives are just still encrypting.
Here's the short version of how we handle that gap: configure encryption, measure it with a grace period, and only gate access once the signal is trustworthy.
Why does Intune say BitLocker is required when the device is encrypting?
Because compliance doesn't turn BitLocker on. Three layers, three jobs:
| Layer | Job | Changes the device? |
|---|---|---|
| Configuration | Pushes disk encryption / Defender / update rings | Yes |
| Compliance | Evaluates "is it encrypted yet?" | No. It only marks compliant / noncompliant |
| Conditional Access | Uses "compliant" to allow / require MFA / block sign-ins | Blocks access, not the OS |
If you require BitLocker in compliance but never assign an encryption configuration policy, devices stay noncompliant forever. Fix the configuration first.
How does the Intune compliance grace period work?
BitLocker on a busy laptop isn't instant. In the compliance policy's Actions for noncompliance, the Mark device noncompliant action has a schedule in days. That schedule is your grace period. For a first pilot policy that requires BitLocker, start with 1–3 days (we often use 3 days in the first week), then tighten once the fleet encrypts quickly.
During the grace period, treat the device as "still remediating, don't panic." When it ends, Intune marks the device noncompliant. That mark alone doesn't wipe, retire, or lock the device.
Pilot actions for noncompliance (day one):
- Mark device noncompliant: On (after the grace period)
- Email / notification: optional
- Remote lock / retire / wipe: Off
"Noncompliant" often means "the policy hasn't finished applying," not "compromised."
How do you troubleshoot a BitLocker compliance failure?
Before you escalate to Conditional Access:
- Confirm a disk-encryption configuration policy is assigned to the same pilot scope as the compliance policy.
- On the device (elevated where needed), check the system drive's encryption status (
Get-BitLockerVolume), then sync from Company Portal. - In Intune, open the device's compliance view: which setting failed, and when was the last sync?
- Check recovery key escrow in Intune (or your org's escrow process). Users will ask for the key when something goes sideways later.
- Look for GPO or third-party encryption tools fighting Intune's BitLocker policy.
If the device won't check in at all, that's a sync problem rather than an encryption one. Use the Company Portal can't connect triage order.
Weekly read-only device/compliance CSV snapshots turn "are we healthier than last Monday?" into a 30-second answer. (Here's the snapshot habit. Snapshots export state; they don't change policy or touch devices.)
When is it safe to require a compliant device in Conditional Access?
A Conditional Access grant of Require device to be marked as compliant does exactly what you asked. That includes blocking Outlook on devices that are still encrypting and past their grace period.
Safer order:
- Configuration pushing BitLocker
- Compliance with a grace period, pilot only, mark-noncompliant-only
- Exit criteria (for example ≥90% compliant for several days)
- CA in report-only on the same pilot, then enforce in waves
If Insights shows a pile of "would block" results for expected work, you're not ready to switch it On.
Copy-ready starter decisions
| Decision | Starter choice |
|---|---|
| Scope | Same Intune pilot group as enrollment |
| BitLocker in compliance | Require |
| Grace period (mark noncompliant after) | 3 days in the first week; tighten later |
| Destructive compliance actions | Off |
| CA pairing | Report-only first |
Write these decisions down in a ticket or wiki once. Future you (and 3am you) will thank you.
FAQ
Does a compliance policy enable BitLocker?
No. Compliance only evaluates. Encryption is turned on by a configuration policy (for example, an endpoint security disk encryption policy).
Why is a device still noncompliant after BitLocker finishes?
Usually it just hasn't checked in or re-evaluated yet. Sync it and give it time. Microsoft's documentation also notes that the Require BitLocker compliance setting relies on Windows health attestation, so a restart may be needed before it reports correctly. Check the current docs for your Windows version.
Will a noncompliant device be wiped?
Not by default. Only the actions you add (remote lock, retire) run, and none of them are needed for a pilot.
What grace period should I use?
There's no official number. 1–3 days covers most first-time encryption. Shorten it once your fleet encrypts reliably.
Related reading
- Conditional Access report-only → enforce without lockouts
- Weekly read-only Intune device + compliance CSV snapshots
- Company Portal can't connect / device not syncing: 10-minute triage
Free checklist before you gate access on compliance
When compliance is green and you're ready to require a compliant device, the free Conditional Access Rollout Checklist walks through report-only, What If, the go/no-go call, waves, and rollback triggers. It has a specific check for devices that are still encrypting or haven't checked in.
Want the full compliance side written out? The Intune & M365 Admin Starter Pack includes the full baseline-compliance playbook (grace periods, exit criteria, editing a live policy safely), plus enrollment hygiene, inventory snapshots, M365 admin hygiene, and 7 break/fix cards (including "BitLocker recovery key missing from Intune"). It also comes with three read-only PowerShell scripts: a local enrollment snapshot, a Graph device snapshot, and a compliance policy summary. The scripts only read; they don't wipe, retire, or change policy: Intune & M365 Admin Starter Pack.
Admin Pack Studio. Not affiliated with Microsoft. Operational guidance for admins authorized to manage their tenant. Pilot first.
Top comments (0)