Over the last few days, we have had some major chaos around Intune Security Baselines. It started because of a known issue you can read about here. Basically, if you created a baseline for 23H2 and deviated from the recommended settings, then the wheels would fall off when upgrading the baseline to 24H2. The nerd rage has started to ensue all over the place in all social media channels as these things tend to do. This feels like a great opportunity to cover baselines overall with Intune. Today we will cover:
- What exactly are Security Baselines?
- The Many Ways of Deploying Security Baselines
- Discussing Security Baselinegate
- Best Practices with Security Baselines
What Are Security Baselines
Security is really hard right? Security Teams are also ridiculous right?
Many groups create ideal security recommendations like Microsoft or CIS on how something should be configured. I discussed this briefly last year in my article about security best practices. Security baselines are a collection of best practice security recommendations one of these governing bodies creates to say “this is how to make your stuff less bad.” Aka this is how we secure a thing.
You might say: “wtf, I can figure this out myself it’s not that hard.” I have news for you, it is that hard. There’s like 3000+ group policy settings for Windows and its hard to know what is important. The security baseline gives you, you guessed it a BASELINE of where you should start. Sometimes you might need to make changes to fit your organization, but the principles are the same.
Speaking of principles, there’s a few to be aware of:
- Baselines are for orgs where users don’t have admin rights.
- Those orgs should be well-managed and security-conscious.
- Baselines enforce settings that mitigate security threats that cause more good than harm. (e.g. disabling SMBv1)
- Baselines enforce defaults so they can’t be set to an insecure state by a user.
Now, that we sort of get it, let’s talk about the ways we can do them.
The Many Ways of Deploying Security Baselines
We have a few different ways of creating security baselines. Some of them are good and others not so much.
We will look at these options:
- Intune Built-In Security Baselines
- Importing Security Baselines
- 3rd Party Security Baseline Platforms
Intune Built-In Security Baselines
The direct link to security baselines can be found here.
Within Intune’s Endpoint Security area, you find all of these fun little security baselines like you can see below for things like Microsoft 365 Apps, Defender, Edge, Windows, HoloLens 2, and Windows 365. They all look pretty much the same fundamentally, but let’s discuss this a little bit:

You click on the baseline for Windows 10 for example and create a new policy:

Once you name the policy, you find yourself in a configuration settings area like if you were building a settings catalog policy. Inside of there, you will find numerous default settings for the baseline like you can see below:

One of the many things that make them stupid is an inability to add additional settings to the baseline, which makes it very fragmented. For example, it sets a single setting for LAPS or Windows Hello For Business, but you can’t build the rest. AKA, it’s dumb. I can’t stress enough how stupid that is, but that’s the way they work.
After that, you click through scopes, assignments, and save.
The consensus is using these is sort of terrible and only leads you to “Conflict City”, which is a city that requires a full-time therapist and probably more cigarettes and scotch than you feel comfortable with.
Importing Security Baselines
The real best practice, outside of using a 3rd party tool or framework like James Robinson’s OIB (Open Intune Baseline) (we’ll discuss this in the next section), is to download the security baseline and import it to Intune.
We start by going to the Microsoft Security Compliance Toolkit to download the Windows 11 24H2 (for example) security baseline and unzip it. Navigate to the GPOs folder, and you will find all of these folders with GUIDs:

Now, you copy the gpreport.xml for each of the policies to a new folder and get ready to import them into our friend, Microsoft Intune:

To simplify, you can run this PS script as long as you extract to C:\temp:
# Set the root path
$basePath = "C:\Temp\Windows 11 v24H2 Security Baseline\Windows 11 v24H2 Security Baseline\GPOs"
# Set the output directory (change this if you want them somewhere else)
$outputPath = "$basePath\..\ExportedReports"
New-Item -ItemType Directory -Path $outputPath -Force | Out-Null
# Get all subfolders under the base path
Get-ChildItem -Path $basePath -Directory | ForEach-Object {
$subfolder = $_
$gpreportPath = Join-Path -Path $subfolder.FullName -ChildPath "gpreport.xml"
if (Test-Path $gpreportPath) {
$destinationFile = Join-Path -Path $outputPath -ChildPath ($subfolder.Name + ".xml")
Copy-Item -Path $gpreportPath -Destination $destinationFile -Force
Write-Host "Copied and renamed $gpreportPath to $destinationFile"
} else {
Write-Warning "No gpreport.xml found in $($subfolder.FullName)"
}
}
You can navigate here to go to the GP Analytics area within Intune to import those policies you just extracted. You just click “Import” and you can select all of those nice XML files you just collected:

From there, you can review the policies you just imported and pull them into Intune as configuration policies:

The really nice thing about this is your ability to modify those baselines you imported that add in additional capabilities that are applicable to your organization. Pliability is huge and lets you avoid most of the nonsense around conflicts, which is where you want to be. Check out my video below that shows you how to import those 3rd party ADMXs.
3rd Party Security Baseline Platforms
Now, if you want to take things a step further, you can use one of the many great 3rd party options. Truthfully, it starts with the gold standard with James Robinson’s “OpenIntuneBaseline” aka OIB. James has been cultivating this since 2021, which many consultants and organizations use as their baseline.
Simply, he maintains it, you download and import his best practices, which are an artisanal approach to security baseline configurations for Windows and much more as you can see below:

I’d suggest reading more about it on his GitHub, which I referenced above. You also have MSP management platforms for Intune like the freshly minted Tenant Manager by Software Central by the amazing Andy Taylor. That product lets you do many things, but I will be covering it in detail in a few weeks.
For now, I’ll reference that you can deploy a variety of baseline collections like “EUC Toolbox (Andy’s amazing community tool), CIS baselines, and more):

The gist is, you elevate a standard security baseline to a managed, cultivated, artisanal baseline because of the expertise of various vendors or Microsoft MVPs to simplify things even farther. Just another reminder, DO NOT USE the built-in baselines.
Discussing Security Baselinegate
As you read earlier, you create those built-in baselines, which are super fun. You can see in this graphic below, this is the flow that broke things and caused the trolls to descend upon Microsoft with Crowdstrike-like fury:


Basically, you have a security baseline on 23H2, and you go to update it to 24H2 and step-through that workflow. That is currently broken. If you made ANY changes that deviated from the recommended settings, they get reverted. The anger over this is semi-hilarious, yet here we are. The thing that makes it funny is people really shouldn’t have been using them to begin with. You can do much better, and as MVPs we need to get that word out more and BETTER.
One final note: THIS IS NOT CROWDSTRIKE. Please stop acting like it is. It’s a small gap that people only run into if they are changing the version to 24H2. Sure, it’s a bug, but let’s stop inciting chaos.
Best Practices with Security Baselines
Let’s sum things up now that we discussed all of this “fun.”
A short list of security baseline best practices:
- PLEASE do NOT use the built-in security baselines. I mean they’re “fiiine” but they really aren’t.
- Grab a copy of them and import them at a minimum.
- 3rd party solutions are even better, especially with the ability to leverage things like CIS baselines to have a stronger security posture.
- Measure twice, cut once when it comes to deviating from recommended settings. Make sure you truly need those changes.
- If you have other security settings, internal GPOs that you migrated, converge them to a single security policy. Less complexity means less nonsense.
- Conflicts suck, be better to yourself. It’s not iOS, you don’t need one policy per category or setting. Achieve simplification
- Implement Config Refresh. Rudy has written some great stuff on this here.
- Keep it simple!
