The critical tier is what I will not hand a tenant over without. This is everything else worth having an opinion about: which security baseline actually runs, who owns Windows updates now that hotpatching switched itself on, how you protect data on devices you will never manage, and who holds the local administrator password on both platforms. Recommended means it is the professional default and deviation should be deliberate. Optional means reasonable practitioners differ and my job is the trade, not the verdict.
Security baselines, and why I do not run Microsoft’s
Let me put the position first and then defend it, because it is the most contested thing in this article. In almost every engagement I reach for OpenIntuneBaseline rather than the security baselines Intune ships with. The reason is not ideological and it is not about the settings being wrong. It is that the built-in baselines cost more time to modify and duplicate into something usable than a good community baseline costs to implement outright, and the time goes into work that produces nothing durable.
Four specific complaints, and Microsoft’s own documentation supports every one of them.
They are jumbled together and they disagree with each other. Microsoft states it plainly: separate baseline types may include the same settings and use different default values for those settings, followed by the sentence that matters, which is that Intune cannot determine which configuration is best for you. So you have two baselines both asserting a setting, disagreeing about it, and a platform that will not adjudicate. That is not a corner case. It is the Windows baseline and the Defender baseline in the same tenant.
They conflict with the rest of the estate by design. The documentation says in almost all scenarios the default settings in the security baselines are the most restrictive, and instructs you to confirm they do not conflict with other policy settings or features in your environment. That is honest and it is also a substantial piece of unfunded work handed to the reader with no tooling.
They are hard to troubleshoot, and the newer format made that worse rather than better. Since the 2023 move to the CSP-derived format, Intune no longer maintains a per-setting list by name for new-format profiles and defers to the configuration service provider documentation instead. When a setting in a monolithic baseline breaks something, you are now navigating from a policy that will not tell you what its settings mean to a reference organised by a completely different taxonomy.
And the modification tax is structural rather than something you pay once. When a new baseline version ships, profiles built on the old version go read-only for settings. You can still edit the name, the description and the assignments, but not the configuration. So a customised baseline is a fork that you re-do on Microsoft’s release schedule, and the customisation work does not carry forward. That is the whole argument in one mechanic: the effort you spend making the built-in baseline fit your estate is effort you spend again at the next version.
A baseline you cannot troubleshoot or version cleanly is not a baseline you own, and ownership is the entire subject of this pillar.
Two supporting observations. The Defender for Endpoint baseline is still at 24H1 while the Windows baseline has moved to 25H2 and the Edge baseline to v139, which is a family where one member has not versioned in long enough that treating the set as a coherent whole is optimistic. And Microsoft’s own FAQ answers the question of whether the Intune security baselines are CIS or NIST compliant with a flat no, strictly speaking, noting there is no one-to-one mapping. That is a creditable answer and it removes the compliance argument for adopting them.
Now the concession, and I make it early so the rest reads as judgment rather than grievance. For a team with nothing, the built-in baselines are a defensible on-ramp. Microsoft frames them as a starting point rather than an endpoint, says many customers use them as recommendations and then customise, and the same Windows security team that produces the group policy baselines produces these. If the alternative is an unhardened tenant, apply the Windows baseline this afternoon. My position is not that the baselines are wrong. It is that they are a starting point, Microsoft says so, and a starting point is not a thing you operate for three years.
OpenIntuneBaseline is what I run instead, and the reasons are the inverse of the complaints. It is modular per control surface rather than monolithic, so a problem localises to a policy instead of to a wall of settings. It versions per policy, so a release legitimately contains policies at different version suffixes and the suffix tells you when that policy last changed. And it is forkable by name, which keeps the version comparison honest: you never edit an OIB policy in place, you fork it under a new name, and the compare against the upstream release keeps working. The deployment mechanics live in the Intune guide’s baseline articles and I am not going to restate them here.
One new arrival worth knowing about rather than adopting. Intune’s baseline catalogue now includes a Local AI Agent Baseline for OpenClaw, in preview, dated May 2026. Read what it actually is before forming a view: it exists to limit unauthorised local AI agents by disrupting common execution paths, and it does that with two Windows Subsystem for Linux settings and firewall rules blocking outbound TCP from Node.js executables in the user profile. Microsoft’s own caveat is that the settings might not fully block all agent execution paths. This is shadow IT control rather than anything to do with adopting AI, it is adjacent to how you already think about unmanaged application installs, and it is in preview. There is a related compliance capability in development that would mark a Windows device noncompliant when prohibited AI agents are discovered against an admin-configurable list. Both are worth watching. Neither is worth building a position on yet.
The macOS baseline is the same argument in a different accent
For a Mac estate the accelerator I reach for is Microsoft’s own intune-my-macs, a project from the Intune Customer Experience Engineering team that drives Graph from PowerShell and stands up a working configuration quickly: FileVault, firewall, Gatekeeper, login restrictions, time settings, compliance policies, a few scripts and a small application set. It works, it saves a genuinely tedious afternoon, and the Intune guide already covers how to run it.
What the project says about itself is the part that belongs in a baseline article. It is published as a proof of concept, explicitly not for production use, explicitly not a hardened baseline, and provided as-is without warranty or support. That is not a criticism of it. It is the same shape as the Windows argument arriving from the other direction: Microsoft ships starting points, Microsoft says they are starting points, and a baseline is what you own after you have forked one.
So the honest recommendation has two halves. Use it to get a Mac estate from nothing to configured in an afternoon, which is real value. Then treat what it produced as your first draft, own each policy, rename them into your convention, and stop thinking of the repository as your baseline. If your Mac estate is still running unmodified proof-of-concept output a year later, nobody has decided anything; the tool decided, and the tool told you it was not making a decision.
Updates, and the default that changed under everyone
First a vocabulary correction, because the old name is in every set of notes including mine. Windows Update for Business is now Windows Update client policies. Same surface, current name, and worth using so your documentation does not read as three years old.
My default remains Autopatch where the licensing allows it, with manually built update rings as the fallback rather than the aspiration. Autopatch entitlement now reaches further than most notes record: Business Premium and the A3 tier gained it in April 2025 when feature activation was removed. The nuance worth knowing before you promise it to a client is that the entitlement is not uniform. Support requests are available on the E3 and above tiers and on F3, and are not available on Business Premium or A3. Everything else, the update policy management, the Autopatch groups, the reporting, is available across all four. So Business Premium gets the Autopatch product and does not get Autopatch support tickets, which is a small precise fact that belongs in a statement of work.
Then the thing that happened to tenants who did nothing. From the May 2026 security update, hotpatch updates are enabled by default for all eligible devices managed through Windows Autopatch. A tenant-level opt-out arrived in the admin center on 1 April 2026, and a quality update policy can override the tenant setting for a specific group. If nobody in your organisation opened either of those, hotpatching is on, and it is on because Microsoft decided rather than because you did. That is the wave’s thesis expressed as a date, and it is the single best example I have of why a baseline has to include the defaults you inherited.
Eligibility is worth stating correctly, because one Microsoft page is stale on it. Hotpatch needs Windows 11 24H2 or later on the current baseline, virtualisation-based security enabled, Intune managing the deployment through a hotpatch-enabled quality update policy, and one of the qualifying licences. On the CPU question, Arm64 is supported, with the prerequisite that compiled hybrid PE usage has to be disabled because hotpatching is not compatible with servicing CHPE binaries, and Microsoft states there are no plans to support hotpatch on Arm64 devices with CHPE enabled. The reason I say it that carefully is that the Autopatch FAQ contradicts itself on a single page: its eligibility list still requires an x64 processor, and three questions further down the same page it asks whether hotpatch can be used on Arm64 devices and answers yes. Take the answer, not the list, and take the management page over both. The cost of disabling CHPE is that 32-bit x86 applications on those machines can break or slow, which interacts with the separate deadline that 32-bit Microsoft 365 Apps on Windows Arm stop receiving security updates in December 2026.
Two operational notes. A device that is not eligible for hotpatch is simply offered the standard cumulative update instead, so ineligibility is quiet rather than loud. And where Autopatch manages a device, the service creates and maintains its own update rings, so assigning custom rings to Autopatch-managed devices is a good way to produce behaviour nobody can explain.
On WSUS, the position has firmed up. It is deprecated, receiving no new features, and still supported for production deployments, and it ships as a role in Windows Server 2025, so it is not going anywhere on a short timeline. The migration mechanic to know is the Windows scan source policy, which lets you choose per update class whether the device gets that class from WSUS or from Windows Update client policies. Dual scan is dead: the old policy is unsupported on Windows 11 and replaced on Windows 10 by the scan source policy, and Microsoft does not recommend using it. Microsoft’s own framing is that the scan source policy is for the transition from a fully on-premises managed environment to a cloud-supported one, which is exactly the estate most of these engagements are.
App protection for the devices you will never manage
App protection policies are the answer to personal phones, and the tiering question has an unusually clean answer because Microsoft publishes its own three-level framework and its recommendation matches the house position almost word for word. Level 1 is enterprise basic data protection, which Microsoft calls the minimum data protection configuration for an enterprise device. Level 2 is enterprise enhanced, described as applicable to most mobile users accessing work or school data. Level 3 is enterprise high, aimed at users accessing high-risk data and at organisations with a larger or more sophisticated security team.
The house default is Level 2 for the population and Level 3 for high-risk roles, and Microsoft’s own guidance says most organisations should implement the settings defined in Level 2. That is a rare case where I can simply agree in public rather than argue, and I would rather say so than manufacture a distinction.
Platform floors, which decide whether the policy applies at all: app protection policies need iOS or iPadOS 17 and later, and Android 10 and later, and the Company Portal app must be present on Android to receive them. They are not supported on ChromeOS.
App protection on Windows exists and is narrower than people assume. It requires Windows 11 22H2 or later, Intune 2309 or higher, and a current Microsoft Edge, and Edge is the only supported application. More importantly it is for unmanaged devices only: if a device is already managed, MAM enrollment is blocked and the policy settings do not apply, and if a device becomes managed after MAM enrollment the settings stop applying. It is a real capability for the contractor laptop you will never enrol, and it is not a management layer for machines you already own.
Conditional launch is where this section earns its place in a baseline this year, because the settings have not changed but the pressure on them has. There is a January 2026 minimum for the Intune app SDK and app wrapper on iOS, enforced through the minimum SDK version check, and a matching Company Portal minimum on Android. And there is a hard date coming: from 31 October 2026 Intune enforces Google’s stronger Play integrity definition, under which an Android 13 or later device that has not received a security update in the past twelve months drops from strong integrity to device integrity. That will trip conditional launch blocks and compliance failures on real devices in real estates. The named mitigations are the app protection minimum OS version and minimum patch version settings, and the compliance minimum security patch level. If you configure nothing else in this section this year, configure those.
Local administrator passwords, on both platforms
Windows LAPS through Intune is a recommended-tier control that I would push toward critical in any estate where the service desk still knows a shared local administrator password. Intune drives it through the account protection endpoint security policy and the Windows LAPS CSP, and that policy overrides every other source, including group policy and legacy Microsoft LAPS. It manages one account per device, and when the policy does not name an account it manages the built-in administrator account whatever it has been renamed to.
On Windows 11 24H2 and later there is automatic account management, which will create and manage a custom account, randomise its name, enable or disable it, and extend LAPS account tampering protection. On 23H2 and earlier, LAPS can only manage accounts that already exist, and specifying an account name that does not exist has no effect and generates no error. Silent failure on a security control is worth a line in whatever you hand over.
macOS has an equivalent and I was wrong to assume for a long time that it did not. Intune ships macOS local account configuration with LAPS, scoped to automated device enrollment on macOS 12 and later, for devices enrolled through a macOS ADE profile after a factory reset. Enrollment paths that re-initiate ADE from an existing installation are not supported. It provisions a local administrator account with a randomised fifteen-character password stored encrypted by Intune, rotates it automatically every 180 days, and offers a configurable rotation period between 1 and 180 days. You view the password under the device’s passwords and keys view and rotate it with a device action. One platform limitation to know: the account does not receive a secure token.
The permission model repeats on both platforms and it is the reason this control connects to the next article rather than ending here. Rotating a Windows LAPS password is not included in any Intune built-in role, nor in the Entra Intune Administrator role, and requires a custom Intune role. The two macOS equivalents, viewing and rotating the Mac admin password, are likewise in no built-in role and need a custom one. Meanwhile reading a Windows LAPS password is an Entra directory permission rather than an Intune one. Microsoft built this the same way twice, which suggests it is deliberate, and the consequence is that the most sensitive credential operation in the product is invisible to anyone who only reads the built-in roles.
And the trap that spans this article and the last one, stated once more because it is the kind of thing that gets discovered at three in the morning: a macOS compliance policy that requires a password will expire the existing password for every account on the device, including LAPS-created accounts and Platform SSO accounts. Microsoft’s remedy is to manage device passwords with a settings catalog policy instead, with Change At Next Auth set to False. Take the macOS LAPS recommendation from this article and the macOS password floor from the critical tier, apply both without reading this paragraph, and they break each other.
The recommended and optional tiers, collected
| Tier | Setting or decision | Position |
|---|---|---|
| R | Security baseline in use | OpenIntuneBaseline, deployed unassigned then ring-assigned; fork by name, never edit in place |
| O | Microsoft built-in baselines | Reasonable on-ramp for a team with nothing; not a thing to operate long-term |
| R | macOS configuration source | intune-my-macs as an accelerator, then owned and renamed; it is proof-of-concept output by its own statement |
| R | Windows update ownership | Autopatch where licensed; custom rings as fallback and never alongside Autopatch on the same devices |
| R | Hotpatch | Decided rather than inherited; on by default since the May 2026 security update, tenant opt-out available |
| O | CHPE on Arm64 | Disable only if those devices need hotpatch and 32-bit x86 apps are not in the way |
| R | WSUS coexistence | Windows scan source policy per update class; dual scan is dead and unsupported on Windows 11 |
| R | App protection level | Level 2 for the population, Level 3 for high-risk roles, matching Microsoft’s own recommendation |
| R | Android conditional launch | Minimum OS version and minimum patch version set before 31 October 2026 |
| O | App protection on Windows | Edge only, unmanaged devices only; useful for contractor machines, not a management layer |
| R | Windows LAPS | Enabled via account protection policy; automatic account management on 24H2 and later |
| R | macOS LAPS | Enabled on ADE-enrolled Macs; rotation period decided rather than left at 180 days |
| R | LAPS rotation permissions | A custom Intune role exists and is assigned; no built-in role carries it on either platform |
| O | AI agent controls | Watch; the OpenClaw baseline and prohibited-agent compliance detection are preview and in development |
Next is the part of an Intune baseline almost nobody configures, which is the authority model inside Intune itself: who can see which objects, who can change them, and whether anyone has to agree before a change lands.
Best Practices
‹ Previous: [BP 4.1.1] Build Sheet: Enrollment Restrictions and Platform Blocking
Next: [BP 4.3] Privileged Access in Intune: Roles, Scope Tags, and the Second Signature ›
