Every Intune tenant I have inherited was configured. Most of them were not decided. The difference shows up on the day you hand the environment to someone else and they ask why a setting is the way it is, and the honest answer turns out to be that nobody chose it. This series is about the settings that have to be true before a tenant is finished, and about the larger number of settings that are already true because Microsoft decided them while you were busy.
What a baseline asks that a deployment guide does not
There is already a long deployment guide on this site. It walks the whole product, phase by phase, from tenant foundations through enrollment and provisioning and applications and the Mac estate, and it answers one question thoroughly: how do you build this. That is a different question from the one this series asks. A baseline does not ask how to configure Intune. It asks which of the thousand things Intune can do must be true in a tenant before you are willing to put your name on it, in what order of obligation, and with what evidence that each one is still true a quarter later.
Those questions do not have the same answers. A deployment guide is complete when every capability has been explained. A baseline is complete when every unowned decision has been claimed. You can follow a deployment guide perfectly and end up with a tenant where enrollment restrictions were never assigned, where compliance policies exist but the tenant-wide setting underneath them still reports unmanaged devices as compliant, where nobody has decided who is allowed to rotate a local administrator password. Nothing is broken. Nothing is configured wrong. There are simply a set of live decisions that no human made, and they are working exactly as Microsoft shipped them.
So this series adjudicates rather than teaches. When a baseline item needs a procedure, I point at the deployment guide, which already has it, and I spend the space here on which tier the item belongs in and why. There is one exception, a build sheet on enrollment restrictions, and it exists because the deployment guide genuinely does not have that procedure, which I discovered by inventorying the live site rather than by assuming.
The default policy is the real policy
Here is the observation this whole series is built around, and it is the thing I would want a reader to take away if they read nothing else. In Intune, the configuration that governs most of your estate is frequently not the configuration you wrote.
Start with enrollment restrictions, because the mechanism is documented plainly and almost nobody has read it. Restrictions are assigned to groups, they resolve by priority, and the winning policy applies whole with no merging. All of that is intuitive. What is not intuitive is that the entire model only applies to enrollments that are user-driven. Autopilot in self-deploying or pre-provisioned mode, bulk enrollment through Windows Configuration Designer, co-managed devices, userless Apple automated device enrollment, Azure Virtual Desktop, Windows 365, and Android Enterprise dedicated devices are all outside it. Every one of those paths ignores whatever you assigned to groups and falls back to the default policy instead. In a lot of estates that is not an edge case, it is the majority of the devices, and it means the default policy you never opened is the policy actually deciding who gets in.
The same shape repeats across the product. The tenant-wide compliance setting that decides how to treat a device with no compliance policy assigned still ships set to compliant, which is the permissive value, and Microsoft’s own documentation tells you to change it if you are using Conditional Access. Hotpatching turned itself on for every eligible Autopatch-managed device from the May 2026 security update, with a tenant-level opt-out that arrived a month earlier for anyone who was reading. Scoped role permissions in Intune are currently an opt-in preview that fixes a documented over-granting behaviour, and Microsoft has said that when it reaches general availability it becomes the default for all tenants, which means a set of role assignments you made two years ago will start resolving differently.
A baseline is not a stack of policies you layer on top of a product. It is deliberate ownership of the defaults the product uses when your policies do not apply.
None of that is Microsoft behaving badly. Defaults have to exist, most of them are reasonable, and a platform that shipped every switch unset would be worse. The failure is ours, and it is a failure of attention rather than of skill. We audit what we configured. We rarely audit what we allowed. The practical consequence for this series is an ordering rule that shows up in nearly every article: configure the default correctly first, then layer the exceptions, because the exceptions are the part that only sometimes applies.
Not a security feature, and Microsoft says so
I want to set the register early, because device management guidance has an overclaiming problem and I would rather not contribute to it. Microsoft’s own documentation on enrollment restrictions carries this sentence: they are not security features, compromised devices can misrepresent their character, and the restrictions are a best-effort barrier for non-malicious users. That is unusually candid for product documentation and it is exactly right. It also generalises further than the page it sits on.
Most of what an Intune baseline governs is hygiene, cost control and governance rather than enforcement. Blocking a platform you do not deploy keeps unmanaged devices out of your reporting and your licence count and your support queue. Setting a device limit stops one user quietly consuming fifteen seats. Deciding who may create a scope tag decides who can hide objects from their colleagues. These are real and they matter, and none of them will stop a determined attacker on a compromised endpoint. The enforcement in this estate lives in Conditional Access, which decides what a device may reach, and in Defender for Endpoint, which decides what is happening on it. Intune supplies the signal and the configuration those two act on.
Getting that boundary right is what lets the rest of the series be blunt. If I claim a compliance policy is a security control, the first honest reader will point out that a device can lie, and everything else I say loses a little weight. If I claim it is the signal Conditional Access consumes, and that without a Conditional Access policy consuming it the compliance state changes nothing about access, then the recommendation survives contact with a sceptic. Microsoft states the licensing floor for that plainly: to enforce the compliance rules you create in Intune you need Intune and Entra ID P1 or P2 at minimum. A tenant with compliance policies and no Conditional Access has built a reporting system and called it a control.
What this series covers, and where the how lives
The tiers are the ones this pillar has used since the identity wave, and they are about obligation rather than difficulty. Critical means I will not hand the tenant over without it. Recommended means it is the professional default and deviation should be deliberate and recorded. Optional means reasonable practitioners differ and my job is to lay out the trade rather than pick your side. Nothing about that changes because the product changed.
What the wave covers, in order: the critical tier, which is enrollment restrictions and the compliance floor and disk encryption and Defender onboarding and the seam back into Conditional Access on device state. Then a build sheet on enrollment restrictions, because that is the one place a competent admin needs a reproducible procedure and cannot find one. Then the recommended and optional tiers, which is where security baselines live, along with update rings and Autopatch, app protection for the unenrolled devices you do not manage, and local administrator password management on both Windows and macOS. Then privileged access inside Intune itself, which is the roles and scope tags and multi-admin approval story, and which almost nobody configures. Then licensing, which this year is a genuinely different article than it would have been in January. Then the retirements calendar, and then a checklist that puts every row next to the article that defends it.
Two things I will keep doing that the checklist genre does not. I name durable objects rather than screen positions, so you will get the policy type, the setting as the product actually labels it, and the values it takes, and you will not get a click path that decays before the article does. And every recommendation ends in something you can observe, because a baseline that cannot be verified is a description of how the tenant looked on the afternoon you finished it.
Where we start
We start at the front door, with the decision about which devices are allowed to become your problem in the first place. It is the least glamorous part of an Intune baseline and it is the one I most often find untouched, sitting on a default policy that permits every platform and every ownership type because the tenant was stood up in an afternoon and enrollment worked, so nobody went back. That default is a decision. Somebody should make it deliberately, and it should be you.
Best Practices
‹ Previous: [BP 3.5] The Collaboration Quick Checklist
Next: [BP 4.1] The Intune Baseline: The Critical Tier ›
