The critical tier is short on purpose. These are the controls I will not hand a tenant over without, where the cost of being wrong is a breach or a fleet-wide outage, and where I am prepared to argue the point rather than soften it. Four things: who is allowed to enrol, what compliance actually asserts, whether the disks are encrypted and the keys are recoverable, and whether Defender is receiving the endpoints it is supposed to be watching.
The front door: who is allowed to enrol
Intune ships two restriction types and one default policy for each, and the default policies cannot be deleted. That last detail is the design’s most important property and the reason this section leads the tier. You can create up to twenty-five policies of each type, assign them to groups, and order them by priority, where the lowest number wins and the winning policy applies whole with no merging of the losers. All of that is the part people configure. The part that decides more is the default sitting underneath, because a large share of a normal estate never touches the assigned policies at all.
The reason is documented and rarely read. Restrictions apply to user-driven enrollment. Autopilot in self-deploying or pre-provisioned mode, bulk enrollment through Configuration Designer, co-managed devices, userless Apple automated device enrollment, Azure Virtual Desktop, Windows 365 and Android Enterprise dedicated devices all fall through to the default. So the baseline instruction is an ordering instruction: configure the default policy first and correctly, then layer group-targeted exceptions on top of a floor you already trust. Doing it the other way round produces a tenant where the carefully scoped restriction governs the laptops handed out at induction and nothing else.
Two more mechanics belong in the critical tier because getting them wrong looks like a product fault. A restriction assigned to no group has no effect whatsoever, which sounds obvious and is a common finding in an inherited tenant where somebody built the policy and stopped. And edits apply to new enrollments only, never to devices already enrolled, so tightening a restriction does nothing about the estate you already have. If you want the existing devices reassessed you are in compliance, not enrollment. Allow roughly fifteen minutes for group and filter assignment to propagate before you test, because the update between Entra and Intune is not instant and a test run immediately after adding a user to a group will lie to you.
Configure the default first. Everything you assign to a group is an exception to it, and exceptions only sometimes apply.
Blocking personally owned Windows devices is where this gets sharp, because the behaviour is genuinely counter-intuitive and it breaks provisioning if you get the order wrong. Intune classifies automatic MDM enrollment via Entra join during Windows setup as corporate, and then blocks it anyway unless the device is registered with Autopilot, because that path gives the administrator no per-device control. The same is true of Entra join from Windows Settings and of Autopilot for existing devices. So a tenant that provisions with plain Entra join at first sign-in, and then turns on personally-owned blocking because it sounds obviously correct, has just stopped building machines. The paths that survive the block are Autopilot, group policy or Configuration Manager co-management enrollment, a bulk provisioning package, and a device enrollment manager account.
The second trap is the one I would put in bold on the handover document. Uploading Windows corporate identifiers does not simply mark the devices on your list as corporate. It flips the tenant’s default: every enrolling Windows device that does not match all three fields of manufacturer, model and serial is marked personal from that moment. Combine a partial identifier list with personally-owned blocking and you have built a trap that fires on every machine somebody forgot to add to the CSV. The two settings are individually reasonable and jointly a fleet-wide outage, and the only safe order is to prove the identifier list is complete before the block goes on. Note also that on modern Android the identifier mechanism has quietly expired, since IMEI and serial identifiers stop applying above Android 9 for device administrator and Android 11 for personally-owned work profiles. On a current Android estate, ownership comes from the enrollment method or it does not come at all.
Finally, govern the device enrollment manager accounts. A DEM account can enrol devices that a platform restriction would otherwise block, is exempt from device limit restrictions, and can carry up to a thousand devices. It is a documented, first-party bypass of everything above, and a baseline that blocks personal devices without deciding who holds a DEM account has a hole in the middle of it.
The compliance floor, and the setting underneath it
There is a tenant-wide setting called Mark devices with no compliance policy assigned as, and it still ships set to Compliant. Read that literally, because it means what it says: a device that has never been evaluated by any policy reports as compliant, and if Conditional Access is gating on compliance then that device is admitted. Microsoft’s own documentation tells you to change it to Not compliant if you use Conditional Access with compliance policies, and repeats the recommendation on the monitoring page. This is the single highest-value setting in the tier and it takes one click, which is precisely why it is worth an article: the reason it is so often untouched is not difficulty, it is that nothing draws your attention to it.
The companion setting is the compliance status validity period, thirty days by default and configurable between one and a hundred and twenty. It is the answer to a device that has simply stopped reporting. Thirty days is a long time to keep vouching for a laptop nobody has seen, and shortening it is one of the few places where a baseline can make a real difference to the value of the signal without touching a single policy rule.
Then there is what noncompliance does, and the honest answer is that on its own it does very little. Without Conditional Access, a noncompliant device is a row in a report and whatever actions you configured. Compliance is the signal; Conditional Access is the enforcement. Microsoft states the licensing floor for that plainly, saying that to enforce the compliance or password rules you create in Intune you need at minimum Intune and Entra ID P1 or P2. A tenant with elaborate compliance policies and no Conditional Access has built a reporting system and named it a control, and I have seen that misunderstanding survive an audit because the report looked convincing.
Every policy carries Mark device noncompliant as a built-in action scheduled at zero days, meaning immediately. You cannot remove it, only reschedule it, and rescheduling it is how you create a grace period. That is a deliberate decision rather than a default to inherit: zero days means Conditional Access takes effect the moment the device fails, which is correct for a small controlled estate and brutal for a large one mid-rollout. If you pair it with a notification email, know that Microsoft expects those to arrive within six hours of the device being marked, which defeats the naive design where you email on day zero and block on day one.
One caveat the tier has to carry, because it silently removes whole device classes from your enforcement. The Not evaluated state absorbs devices with no policy assigned, devices that have not checked in since the policy changed, Apple devices enrolled without user affinity, Android Enterprise dedicated devices, and anything enrolled by a device enrollment manager account. Those are exactly the shared and kiosk devices most likely to be forgotten. Related, and worth deciding early: devices enrolled with a device-only licence do not support Conditional Access or app protection policies at all. A kiosk estate on device licences cannot be governed by compliance-based Conditional Access, no matter how good the compliance policy is.
As for the rules themselves, I would rather anchor to Microsoft’s own three-level framing than invent a house list, and spend the judgment on where we depart from it. The floor I will not ship without, per platform, is in the recap table at the end. One note for the Mac estate that matters more than it looks: requiring a password in a macOS compliance policy expires the existing password for every account on the device, including accounts created by LAPS and Platform SSO. Microsoft’s own remedy is to manage device passwords with a settings catalog policy instead, with Change At Next Auth set to False. If you take the macOS LAPS recommendation from the recommended tier and the macOS password floor from this one and apply both naively, they break each other.
Encryption, and the three doors that only open one way
Disk encryption belongs in the critical tier for a reason that has nothing to do with sophistication. It is the control most likely to be assumed rather than verified, because a fleet of laptops that were all built the same way tends to be encrypted the same way, right up until the batch that was not. Configure it as policy, escrow the keys where you can retrieve them, and confirm the state rather than the intent.
On Windows the endpoint security disk encryption profile is the surface to use, and silent enablement rests on three settings: Require Device Encryption enabled, Allow Warning For Other Disk Encryption disabled, and Allow Standard User Encryption enabled, which becomes available once the previous one is set and is required if the machines are used by non-administrators. Microsoft attaches an unusually direct warning to the middle one, because disabling the warning means BitLocker proceeds even when other disk encryption software is present, and the documented consequences are data loss from conflicting encryption, boot failures, and recovery scenarios with multiple encryption layers stacked on each other. That is a real one-way door in its own right and the best-sourced hazard in this section. It is also the correct setting for an estate you know is clean, which is the whole reason to inventory before you enable rather than after.
Three behaviours are worth stating precisely, because they are the ones people guess at and guess wrong.
The first: encryption settings are enforced only at the moment encryption starts, and encryption is not restarted when the settings change. Choose the algorithm before the first encryption or you are looking at a decrypt-and-re-encrypt cycle across the fleet to change your mind. This is not a quirk of the older profile format, it is stated at the configuration service provider level, which is what every Intune surface writes to.
The second: removing or disabling the policy does not decrypt anything. Microsoft’s wording is that disabling the policy will not turn off encryption on the system drive, it will only stop prompting the user to turn it on. So unassigning a BitLocker policy is not a rollback, and treating it as one leaves you with an encrypted estate and no policy asserting anything about it.
The third is the one that surprises people, and it is documented on both the retire and delete device actions. If you delete or retire the Intune object for an Entra joined device protected by BitLocker, Intune triggers a sync that removes the key protectors, and that suspends BitLocker on the operating system volume. Microsoft frames it as a safeguard against unrecoverable encryption, which it is, and it also means a routine device cleanup quietly drops machines out of encryption protection. Both retire pages tell you to back up the BitLocker recovery key and the local administrator credentials before retiring an Entra joined device, and that instruction deserves to be in your offboarding runbook rather than discovered in Microsoft’s documentation afterwards. There is a developing softener here worth watching rather than relying on: Entra device soft delete, currently in preview, holds deleted device objects for thirty days with BitLocker recovery keys and LAPS passwords still accessible, after which they are permanently unrecoverable.
Deleting a device object is an encryption decision. Almost nobody treats it as one.
On macOS the equivalent is FileVault, and the surface question has a documented answer. Use the endpoint security disk encryption profile for a standard deployment; use the settings catalog when you need enforcement during Setup Assistant, which is unique to that surface; and do not use the device configuration endpoint protection template, which is deprecated and cannot create new profiles. Encryption is XTS-AES 128-bit and fixed, so there is no algorithm decision to make. What there is instead is a key model to understand: Intune manages personal recovery keys, one per device, displayed to the user exactly once at encryption. There is no institutional recovery key workflow in the current Intune surface.
And then the split that ties this article to the one after it. Administrators can view and manage FileVault recovery keys only for devices marked corporate. On personal devices the key is still escrowed for the user’s own self-service recovery, automatic rotation still runs, but manual rotation is unavailable and no administrator can retrieve the key. Which means the ownership decisions from the front-door section, the corporate identifiers and the enrollment method, are what determine whether your service desk can ever unlock a Mac. Two sections of one article, connected by a consequence that neither of them announces on its own.
One licensing floor to carry into the licensing article: managing BitLocker through the CSP beyond simply enabling and disabling it requires Windows Enterprise or Education licensing, regardless of management platform. Basic on and off is unrestricted. Algorithms, recovery options and PIN rules are not. A Business Premium tenant configuring granular BitLocker policy is outside Microsoft’s stated floor, which is a sentence very few baselines contain.
Defender onboarding, and what Intune is actually supplying
The critical-tier item here is small to state and large to omit: the connector between Intune and Defender for Endpoint is established, endpoints are onboarded through it, and tamper protection is managed from Intune rather than from wherever it happened to be set. The procedure lives in the Defender series, at the Endpoint onboarding build sheet, and I am not going to restate it.
What belongs here is the authority question. Once tamper protection is deployed and managed through Intune, turning it on or off in the Defender portal no longer affects the state on the device; the portal instead restricts the tamper-protected settings to their secure defaults. That is a clean statement of who owns the control, and it is the kind of thing worth writing into a handover document, because the next administrator will otherwise spend an afternoon toggling a switch in the wrong console and concluding the product is broken. There is a preview capability moving in the same direction, controlled configuration, which lets Intune enforce Defender settings over other management channels, and it is worth knowing about before it changes the answer.
The critical tier, collected
| Setting or decision | Value | Why it is critical |
|---|---|---|
| Default device platform restriction | Configured deliberately, per platform, before any group-targeted policy | Seven common enrollment paths bypass assigned policies entirely and use this |
| Default device limit restriction | Set to a defended number, not left at the shipped value | Same bypass list; also the only limit that applies to shared-mode Windows scenarios |
| Personally-owned Windows blocking | Decided, and only after the corporate identifier list is proven complete | Entra join at first sign-in is blocked by it; a partial identifier list breaks provisioning tenant-wide |
| Device enrollment manager accounts | Enumerated and owned | Documented bypass of both restriction types, up to 1,000 devices per account |
Mark devices with no compliance policy assigned as | Not compliant | Ships as Compliant; an unevaluated device is otherwise admitted by Conditional Access |
| Compliance status validity period | Shortened from the 30-day default deliberately | Decides how long a silent device keeps vouching for itself |
Mark device noncompliant schedule | Chosen, not inherited at 0 days | Zero days means Conditional Access acts immediately; the grace period is this setting |
| Conditional Access consuming device state | At least one policy in enforcement | Without it, compliance is reporting; the floor is Intune plus Entra ID P1 or P2 |
Windows: Require Device Encryption | Enabled, with Allow Standard User Encryption enabled | Silent enablement on machines used by non-administrators |
Windows: Allow Warning For Other Disk Encryption | Disabled only on an estate you have inventoried | Documented data loss and boot failure risk where third-party encryption exists |
| Windows: encryption algorithm | Set before first encryption | Settings apply only at encryption start; changing later means decrypt and re-encrypt |
| BitLocker key escrow to Entra ID | Enabled and verified, device Entra joined | Retire and delete remove key protectors and suspend BitLocker on the OS volume |
| macOS: FileVault via endpoint security | Enabled, settings catalog only where Setup Assistant enforcement is needed | The endpoint protection template is deprecated for new profiles |
| macOS: device ownership marked corporate | Decided at enrollment | Administrators can retrieve FileVault keys only for corporate devices |
| macOS: password compliance rule | Only alongside a settings catalog password policy with Change At Next Auth = False | Otherwise it expires every local password including LAPS-managed accounts |
| Defender for Endpoint connector and onboarding | Established, endpoints onboarded | The device signal the rest of the estate consumes |
| Tamper protection | Managed from Intune | Fixes where the control lives; the Defender portal toggle stops affecting device state |
How to know it held, which is the part checklists leave out. For enrollment, the observable is the admin-side failure reason: an enrollment blocked by a restriction records Enrollment restriction not met under enrollment failures, and a test enrollment that does not produce that string did not test what you think it did. For compliance, read the tenant-wide setting itself rather than a policy, because that is where the default lives. For encryption, confirm escrowed keys exist for the devices you believe are encrypted rather than confirming the policy is assigned, since the assignment proves intent and the key proves outcome. For Defender, confirm the device count on the connector rather than the connector’s own status.
The recommended and optional tiers come next, and they are where most of the interesting arguments live: which security baseline to run and why I do not run Microsoft’s, how updates get owned now that hotpatching turned itself on, app protection for the devices you will never manage, and local administrator passwords on both platforms. None of those will keep me from handing a tenant over. All four of these will.
Best Practices
‹ Previous: [BP 4] The Intune Baseline: The Tenant You Hand Over
Next: [BP 4.1.1] Build Sheet: Enrollment Restrictions and Platform Blocking ›
