← No. 05Intune Security Baselines vs CIS Benchmarks

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Microsoft 365

Intune Security Baselines vs CIS Benchmarks

Compare Intune security baselines against CIS benchmarks with a PowerShell export-and-diff workflow: ASR deployment and deviation tracking included.

By Paul Bentley24 March 2026Updated 15 September 202619 min read

On this page

What Microsoft's security baselines actually are
What they get right
Where they fall short
What CIS benchmarks offer instead
Structure
The trade-off
How to compare Intune baselines against CIS benchmarks
Step 1: export the Microsoft baseline
Step 2: map CIS recommendations
Step 3: diff the two
Step 4: document your deviations
Automate this with BaselineForge
Microsoft baseline vs CIS: which should you use?
Option 1: deploy Microsoft's baseline as-is
Option 2: use CIS as your primary framework
Option 3: hybrid (my recommendation for most organisations)
Attack surface reduction: Intune's most underdeployed security feature
Intune ASR rules: priority order for deployment
The phased rollout
Handling baseline conflicts in Intune
Common conflict scenarios
Detection
Resolution
Implementing CIS benchmarks in Intune: building Settings Catalog profiles
Create a Settings Catalog profile
Profile naming convention
Maintaining your baseline over time
Quarterly review cycle
Drift detection
Intune security baseline implementation timeline
Next steps: Conditional Access, ASR and your security stack

If you'd rather do this interactively than in PowerShell, BaselineForge is the companion tool for this post: load your Intune configuration, compare it against Microsoft's baseline, NCSC guidance and our curated recommendations, then export deployable Intune policies. Everything runs in your browser, and your security configuration never leaves your machine.

Microsoft's Intune security baselines are one of those features that sound like the answer to a question nobody asked properly. "We need to secure our endpoints." "Great, deploy the baseline." Three months later, you're troubleshooting why a line-of-business application crashes on launch, a printer driver refuses to install, and a team of developers can't run unsigned scripts. Nobody can explain which settings caused which problems, because nobody reviewed what the baseline actually contains before deploying it.

The alternative is to understand what baselines are and aren't, then decide deliberately whether to adopt one wholesale, cherry-pick settings from it, or build your own from a framework like CIS. Document that decision, whichever way it goes.

This post provides the methodology for a structured security baseline comparison. We'll export Microsoft's baselines, compare them against CIS benchmarks, identify the deviations that matter, and build a decision framework your team can apply consistently. If you're already running a Configuration as Code practice, these profiles slot directly into your pipeline. If you're not, the standardisation post covers why you should be.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

The scripts in this post use the Microsoft Graph PowerShell SDK v2.x with PowerShell 7 or later. For Graph API patterns, see Graph API for Architects.

What Microsoft's security baselines actually are

A security baseline in Intune is a pre-configured set of Windows settings that Microsoft considers a reasonable security posture for enterprise devices. It's published as an Intune profile template that you can deploy as-is or customise before deployment. Together, these templates form Microsoft's layered approach to endpoint hardening in Intune.

There are several baseline types:

Baseline	Scope	Update cadence
Windows Security Baseline	OS hardening (BitLocker, Defender AV, credential guard, audit policy, user rights)	Updated periodically alongside Windows releases
Microsoft Defender for Endpoint Baseline	EDR-specific settings (cloud protection, sample submission, ASR rules, network protection)	Updated with Defender feature releases
Microsoft Edge Baseline	Browser security (SmartScreen, extensions, site isolation)	Updated periodically with Edge releases
Microsoft 365 Apps Baseline	Office application security (macro policy, ActiveX, add-in management)	Updated with M365 Apps releases
Windows 365 Security Baseline	Baseline settings for Cloud PCs, scoped separately from the Windows Security Baseline above	Updated periodically, versioned like the other baselines

Microsoft also ships two HoloLens 2 baselines and a STIG audit baseline. The STIG baseline assesses Windows 11 devices against DISA's Security Technical Implementation Guide recommendations rather than configuring them, and it's available only to GCC High tenants with Advanced Analytics licensing.

The Windows Security Baseline is the one that gets the most attention and causes the most trouble.

What they get right

Microsoft's baselines aren't bad. They represent a genuine security engineering effort, and they have several real advantages:

They exist. For organisations starting from nothing, a curated set of endpoint hardening settings is better than the Windows defaults. The difference between "we deployed the baseline" and "we have no endpoint hardening" is enormous.
They're tested against Microsoft's own compatibility data. Microsoft tests these settings against its application compatibility matrix, and a CIS benchmark author doesn't have access to the same data that Microsoft's internal teams do.
They version alongside the OS. When a new Windows release changes a security default or adds a new capability, the baseline updates to reflect it. You don't have to track those changes yourself.
They deploy through Intune natively. No custom OMA-URI settings, no ADMX ingestion, no Settings Catalog spelunking. The baseline template surfaces the settings with descriptions and recommended values in a single profile.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Where they fall short

They're opaque about rationale. The baseline tells you what to set, not why. When PreventInstallationOfMatchingDeviceIDs is enabled, is that protecting against BadUSB attacks, preventing users from installing unauthorised peripherals, or both? Without rationale, you can't decide whether to keep, modify, or remove a setting for your environment.
They bundle too many settings together. The Windows Security Baseline contains over 300 individual settings. Deploying all 300 as a single profile means you can't isolate which setting caused a problem. When something breaks, you're left binary-searching through hundreds of settings to find the culprit.
They don't align to a published framework, with one exception. The baselines are Microsoft's own opinion, not mapped to CIS, NIST 800-53, or DISA STIG. That's not a criticism of their quality, but it's a problem for organisations that need to demonstrate compliance against one of those frameworks: an auditor asking "show me your CIS Level 1 compliance" won't accept "we deployed Microsoft's baseline" as evidence without a mapping exercise. Microsoft does ship a STIG-aligned baseline, but only for GCC High tenants with Advanced Analytics licensing, and it assesses devices against DISA's STIG rather than configuring them, so the point still stands for everyone else.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

They can conflict with other profiles. If you deploy the security baseline and separately configure Defender AV settings through an endpoint security profile, the overlapping settings create a conflict. Intune marks conflicting settings with a "Conflict" status in the device report, and neither value is applied until the conflict is resolved. The device is left in its current or default state for those settings. The portal can still show both profiles as "applied" at the profile level, which masks the fact that individual settings within them are not being enforced.
Version upgrades need attention, even with the built-in option. Intune now lets you change the version of a baseline on an existing profile, so you don't always have to create a new profile from the new template. But if you leave a profile on an old version, its settings become read-only once a newer version is available. Either way, check your customised settings against the new version before you move.

What CIS benchmarks offer instead

The Center for Internet Security (CIS) publishes detailed benchmarks for Windows, covering the same ground as Microsoft's baselines but with critical differences in approach.

Structure

CIS benchmarks are organised into two levels:

Level 1 covers settings that improve security without a significant effect on functionality, and is intended for all systems.
Level 2 adds hardening for environments where security takes priority over usability; expect compatibility issues with some applications.

Each setting in a CIS benchmark includes:

Field	What it contains
Description	What the setting does
Rationale	Why it matters, what attack it mitigates
Impact	What breaks if you enable it
Audit	How to verify it's applied (registry key, PowerShell command)
Remediation	How to set it (Group Policy path, registry path, and increasingly Intune CSP paths in newer benchmark versions)
CIS Controls mapping	Which CIS Control (v8.1) the setting satisfies
Default value	What Windows ships with by default

This is the documentation that Microsoft's baselines lack. When a setting causes a problem, the CIS impact statement tells you what to expect. When an auditor asks why a setting is configured, the rationale provides the answer.

The trade-off

CIS benchmarks are more work to implement. You can't deploy them as a single Intune template. Each setting must be configured individually through the Settings Catalog, endpoint security profiles, or custom OMA-URI policies. For an organisation without automation, implementing CIS Level 1 (over 400 recommendations for Windows 11) is a significant manual effort.

Configuration as Code pays for itself here. If your security profiles are defined in code and deployed through a pipeline, the effort to implement CIS is the same as implementing Microsoft's baseline: define the settings, test them, deploy them. The ongoing maintenance burden is lower, because CIS provides version-to-version changelogs that tell you exactly what changed.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

How to compare Intune baselines against CIS benchmarks

The question isn't "Microsoft or CIS?" in the abstract. It's "where do they agree, where do they differ, and do the differences matter for my environment?" Here's the methodology I use to answer that.

Step 1: export the Microsoft baseline

The most reliable way to export baseline settings is from a deployed baseline instance (an "intent" in Graph API terms), not from the template definition. Deploy the baseline to a test group first, then export its configured settings.

Microsoft has been migrating security baselines from the legacy "intents" format to a new format, a migration it began rolling out in May 2023. Baselines released in the new format won't appear via the /intents endpoint below; for those, use /beta/deviceManagement/configurationPolicies?$filter=templateReference/templateFamily eq 'baseline' instead. The companion repo handles both formats.

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
 
# Get all security baseline templates
$templates = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/templates?`$filter=templateType eq 'securityBaseline'"
 
$templates.value | Select-Object id, displayName, publishedDateTime |
    Format-Table -AutoSize
 
# Get deployed baseline instances (intents)
$intents = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/intents"
 
# Find the Windows Security Baseline intent
$baselineIntent = $intents.value | Where-Object {
    $_.displayName -like "*Windows*Security*"
} | Select-Object -First 1
 
# Export settings from the deployed instance
$categories = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/intents/$($baselineIntent.id)/categories"
 
$allSettings = foreach ($category in $categories.value) {
    $settings = Invoke-MgGraphRequest -Method GET `
        -Uri "https://graph.microsoft.com/beta/deviceManagement/intents/$($baselineIntent.id)/categories/$($category.id)/settings"
 
    foreach ($setting in $settings.value) {
        [PSCustomObject]@{
            Category        = $category.displayName
            DefinitionId    = $setting.definitionId
            ConfiguredValue = $setting.valueJson
        }
    }
}
 
$allSettings | Export-Csv "$env:TEMP\MSBaseline_Export.csv" -NoTypeInformation
Write-Host "Exported $($allSettings.Count) baseline settings"

Step 2: map CIS recommendations

CIS benchmark content, its recommendation titles, descriptions and values, is copyrighted by the Center for Internet Security, and we can't redistribute it. That's why the companion repo ships a blank mapping template rather than a populated one. The methodology in this post works with any CIS data you supply: get your own copy of the benchmark, the free PDF or the SecureSuite Excel, and populate the mapping yourself. The scripts and comparison logic are yours to use; the CIS data isn't ours to give.

CIS benchmarks are published as PDF and Excel. The Excel version (available to CIS SecureSuite members) is what you want for comparison. If you don't have SecureSuite access, the free PDF works but requires manual extraction. (Hint: give the PDF to Copilot or Claude and tell it to extract the recommendations for you.)

The mapping key is the Windows CSP (Configuration Service Provider) path. Both Microsoft's baseline and CIS reference the same underlying CSP settings, but they use different naming conventions. A lookup table bridges the gap:

# Build a mapping between CIS recommendations and Intune CSP paths
# This is a simplified example showing the mapping format
# The companion repo has a blank template (mappings/cis-mapping-template.csv)
# Populate it from your CIS SecureSuite export or manual PDF extraction
 
$cisMapping = @(
    @{
        CISId          = "1.1.1"
        CISTitle       = "Password history requirement (24+)"
        CISLevel       = 1
        DefinitionId   = "deviceConfiguration--windows10GeneralConfiguration_passwordPreviousPasswordBlockCount"
        CISValue       = "24"
        CISRationale   = "Prevents password reuse across 24 changes"
    },
    @{
        CISId          = "2.3.1.1"
        CISTitle       = "Block Microsoft account sign-in"
        CISLevel       = 1
        DefinitionId   = "deviceConfiguration--windows10EndpointProtectionConfiguration_localSecurityOptionsBlockMicrosoftAccounts"
        CISValue       = "true"
        CISRationale   = "Prevents users from adding Microsoft accounts for application auth"
    }
    # Populate from your CIS SecureSuite export using the template
    # in the companion repo (mappings/cis-mapping-template.csv)
)
 
$cisMapping | ForEach-Object { [PSCustomObject]$_ } |
    Export-Csv "$env:TEMP\CISMapping.csv" -NoTypeInformation

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Step 3: diff the two

This is where the value lives. Comparing the Microsoft baseline against CIS reveals three categories of settings:

param(
    [string]$MSBaselinePath = "$env:TEMP\MSBaseline_Export.csv",
    [string]$CISMappingPath = "$env:TEMP\CISMapping.csv"
)
 
$msBaseline = Import-Csv $MSBaselinePath
$cisMapping = Import-Csv $CISMappingPath
 
# Use explicit definitionId matching for reliability
# The companion repo includes a complete mapping table
$comparison = foreach ($cis in $cisMapping) {
    $msMatch = $msBaseline | Where-Object {
        $_.DefinitionId -eq $cis.DefinitionId
    }
 
    $status = if (-not $msMatch) {
        "CIS Only"
    } elseif ($msMatch.ConfiguredValue -eq $cis.CISValue) {
        "Aligned"
    } else {
        "Differs"
    }
 
    [PSCustomObject]@{
        CISId          = $cis.CISId
        CISTitle       = $cis.CISTitle
        CISLevel       = $cis.CISLevel
        CISValue       = $cis.CISValue
        MSValue        = $msMatch.ConfiguredValue
        Status         = $status
        Rationale      = $cis.CISRationale
    }
}
 
$comparison | Group-Object Status |
    ForEach-Object { Write-Host "$($_.Name): $($_.Count) settings" }
 
# Export deviations for review
$comparison | Where-Object { $_.Status -ne "Aligned" } |
    Export-Csv "$env:TEMP\BaselineDeviations.csv" -NoTypeInformation
 
Write-Host "`nDeviations exported to $env:TEMP\BaselineDeviations.csv"

The output falls into three buckets:

Category	What it means
Aligned	Both Microsoft and CIS recommend the same value. Deploy these with confidence: in practice, 60 to 70% of settings fall into this category.
Differs	Microsoft and CIS recommend different values for the same setting. Document whether you follow Microsoft's recommendation, CIS's recommendation, or your own value, and why.
CIS only	CIS recommends a setting that Microsoft's baseline doesn't include, typically a more aggressive hardening measure. Evaluate each one against your application compatibility requirements.

Step 4: document your deviations

Documenting deviations is the step most organisations skip, and it's the most important one. Every deviation from either baseline needs a documented justification:

# Deviation tracker template
$deviationTracker = @(
    @{
        CISId          = "18.9.27.1"
        Setting        = "Configure Attack Surface Reduction rules"
        CISRecommends  = "Block all Office applications from creating child processes"
        MSRecommends   = "Audit mode"
        OurValue       = "Audit mode (Phase 1), Block (Phase 2 after 90 days)"
        Justification  = "Finance team uses Excel macros that spawn helper processes. Audit mode first to identify impact, block after remediation."
        Owner          = "Security Team"
        ReviewDate     = "2026-06-24"
        TicketRef      = "SEC-1234"
    }
)
 
$deviationTracker | ForEach-Object { [PSCustomObject]$_ } |
    Export-Csv "$env:TEMP\DeviationTracker.csv" -NoTypeInformation

The deviation tracker is your audit evidence. When a compliance assessor asks "why is this CIS Level 1 setting not enforced?", the answer is a documented, reviewed, time-bound decision with an owner and a review date. That's fundamentally different from "we didn't know about it."

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Automate this with BaselineForge

The methodology above works, but it involves a lot of PowerShell, CSV manipulation, and manual comparison. If you want to do this interactively, BaselineForge is the companion tool for this post. It automates exporting your configuration, comparing it, deciding what to change, and exporting the result, entirely in your browser.

BaselineForge does the following:

Loads your Intune configuration (CSV or JSON from the export script above) and compares it against multiple baselines at once
Ships a curated "BaselineForge Recommended" baseline with independent rationale for every setting, covering the same ground as CIS Level 1
Compares against Microsoft's baseline, so you can see where they agree and where they differ
Maps NCSC Device Security Guidance principles to your settings, showing compliance at the principle level
Accepts your CIS Excel (SecureSuite format) as an optional overlay for formal CIS compliance mapping
Lets you document deviations inline, with justification, owner, review date, and ticket reference
Exports deployable Intune JSON grouped by category, ready for Invoke-MgGraphRequest

Everything runs client-side. Your security configuration never leaves your browser. There is no server, no account, no telemetry. The tool processes your data in JavaScript on your machine and nowhere else.

If you don't have an Intune export to hand, you can also use BaselineForge to browse the recommended settings by category, read the rationale for each one, and build a baseline from scratch.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Microsoft baseline vs CIS: which should you use?

With the comparison data in hand, use this framework to decide your approach. The right answer depends on your compliance requirements, team maturity, and application estate.

Option 1: deploy Microsoft's baseline as-is

This option works when:

You have no specific compliance framework requirement (no CIS, NIST, or DISA STIG mandate)
Your application estate is predominantly Microsoft-native (M365 Apps, Edge, modern web apps)
You're starting from zero endpoint hardening and need to improve your posture quickly
You have limited security engineering capacity

It doesn't work when:

You need to demonstrate CIS or NIST compliance to auditors
You have legacy applications with known compatibility sensitivities
You're already managing endpoint security through other profiles and need to avoid conflicts

Deploy it safely with this sequence:

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Create the baseline profile from the latest template
Assign it to a pilot group (not "All Devices")
Monitor for 30 days: application crashes, driver issues, user complaints
Document any settings you customise and why
Expand to broader deployment rings

The biggest risk with this option is the version upgrade, not the initial deployment. Intune's built-in option to change a profile's version means you don't have to rebuild it from scratch, but you still need to work out what changed. Compare your customised settings against the new template, and decide whether the new recommendations still fit your environment before you switch. Once a newer version is available, a profile on the old version becomes read-only, so plan the upgrade rather than deferring it.

Option 2: use CIS as your primary framework

Choose this when:

You have a compliance requirement that maps to CIS Controls
Your security team has the capacity to implement and maintain 400+ individual settings
You're running a Configuration as Code pipeline that can manage profile-as-code
You want documented rationale for every security setting

Skip it when:

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

You don't have SecureSuite membership (the free PDF is workable but slow)
Your team lacks the Intune Settings Catalog expertise to translate CIS recommendations into profiles
You need a quick win and can't invest in the mapping exercise upfront

Roll it out with this sequence:

Start with CIS Level 1 only. Level 2 is for high-security environments and will cause compatibility issues
Group settings by category (account policies, audit policies, user rights, security options, Defender, ASR)
Create one Intune profile per category, not one profile for everything
Deploy to a pilot ring and test for 30 days per category
Track deviations from the benchmark with justification

Option 3: hybrid (my recommendation for most organisations)

The hybrid approach has three steps:

Start with Microsoft's baseline as the foundation. It covers the core endpoint hardening settings, deploys cleanly through Intune, and gives you immediate value.
Layer CIS-only settings on top as separate profiles. These are the settings CIS recommends but Microsoft's baseline doesn't include. Deploy them incrementally, category by category, with testing between each deployment.
Document every deviation from both baselines. The deviation tracker becomes your living compliance document.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

This approach gives you:

Fast initial value (Microsoft baseline in week 1)
Compliance mapping (CIS alignment over weeks 2-8)
Documented posture (deviation tracker from day 1)
Manageable maintenance (Microsoft baseline updates handled separately from CIS supplementary profiles)

Attack surface reduction: Intune's most underdeployed security feature

ASR rules deserve special attention because they're simultaneously the most impactful and least deployed security feature in Intune. They're included in Microsoft's Defender for Endpoint baseline, partially covered by CIS, and routinely left in audit mode or not deployed at all.

ASR rules are available with Defender Antivirus (included in Windows) but deliver their full value with Defender for Endpoint Plan 2, which provides the reporting, exclusion management, and advanced hunting capabilities you need to operate them at scale. If you're evaluating whether your organisation needs MDE P2, the E3 vs E5 decision framework covers the licensing analysis. If you're not sure how many MDE P2 or E5 licences you currently have deployed, the M365 licensing audit covers extracting that from Graph API.

Intune ASR rules: priority order for deployment

Not all ASR rules carry equal weight. Some are high-impact with low compatibility risk. Others will break legitimate workflows if deployed without testing. Here's the prioritisation I use:

Deploy these first: they carry low compatibility risk and high security value.

Rule	GUID	What it does
Block executable content from email client and webmail	`BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550`	Prevents execution of .exe, .dll, .scr from Outlook and webmail
Block all Office applications from creating child processes	`D4F940AB-401B-4EFC-AADC-AD5F3C50688A`	Stops Office apps from launching PowerShell, cmd, mshta
Block Office applications from creating executable content	`3B576869-A4EC-4529-8536-B80A7769E899`	Prevents Office from writing .exe or .dll files to disk
Block JavaScript or VBScript from launching downloaded executable content	`D3E037E1-3EB8-44C8-A917-57927947596D`	Stops script engines from launching downloaded executables
Block execution of potentially obfuscated scripts	`5BEB7EFE-FD9A-4556-801D-275E5FFC04CC`	Detects and blocks obfuscated scripts (PowerShell, VBScript, JavaScript)

These carry moderate compatibility risk and need thorough testing, so deploy them second.

Rule	GUID	What it does
Block credential stealing from the Windows local security authority subsystem (lsass.exe)	`9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2`	Prevents credential dumping from LSASS
Block process creations originating from PSExec and WMI commands	`D1E49AAC-8F56-4280-B9BA-993A6D77406C`	Blocks remote process creation via PSExec/WMI
Block persistence through WMI event subscription	`E6DB77E5-3DF2-4CF1-B95A-636979351E5B`	Prevents WMI-based persistence mechanisms
Use advanced protection against ransomware	`C1DB55AB-C21A-4637-BB3F-A12568109D35`	Cloud-based heuristic for ransomware detection

Save these for last: they carry the highest compatibility risk here and need the most testing.

Rule	GUID	What it does
Block Win32 API calls from Office macros	`92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B`	Blocks any VBA macro using Win32 API `Declare` statements. High compatibility risk: affects corporate Excel workbooks extensively. Test thoroughly before enabling.
Block untrusted and unsigned processes that run from USB	`B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4`	Blocks unsigned executables from removable media

The phased rollout

ASR rules support four modes: Disabled, Audit, Warn, and Block. Warn mode blocks like Block mode, but the user can select "Unblock" in the notification to bypass it for 24 hours. The correct deployment sequence is:

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Enable all rules in Audit mode across your pilot ring. This logs what would have been blocked without actually blocking it.
Run audit mode for 30 days minimum. Without MDE P2, collect events locally via Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" (event ID 1121 for block, 1122 for audit). With MDE P2, use advanced hunting for centralised visibility across your estate.
Review the audit data. Identify legitimate processes that trigger rules, and create per-rule exclusions for those processes.
Switch low-risk rules to Block mode in the pilot ring, and monitor for 14 days.
Expand to broader rings, following your standard deployment ring model.

If you have MDE P2 or M365 E5, advanced hunting gives you centralised ASR event data across all enrolled devices:

# Query ASR audit events via Defender for Endpoint advanced hunting
# Requires MDE P2 or M365 E5
$query = @"
DeviceEvents
| where ActionType startswith "Asr"
| where Timestamp > ago(30d)
| summarize
    AuditCount = countif(ActionType endswith "Audited"),
    BlockCount = countif(ActionType endswith "Blocked")
    by RuleId = tostring(AdditionalFields.RuleId),
       FileName,
       FolderPath,
       InitiatingProcessFileName
| sort by AuditCount desc
| take 50
"@
 
# Run via Microsoft Graph Security API
# Requires ThreatHunting.Read.All, available as a delegated or an application permission
$huntBody = @{ Query = $query } | ConvertTo-Json
$results = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/security/runHuntingQuery" `
    -Body $huntBody -ContentType "application/json"
 
$results.results | Format-Table -AutoSize

The audit data tells you exactly which applications trigger which rules on which devices. Without this data, you're guessing at exclusions. With it, you can make precise, documented decisions about what to exclude and what to block.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Handling baseline conflicts in Intune

Profile conflicts are easy to miss in endpoint security configuration. When two profiles configure the same setting with different values, Intune doesn't silently pick one: it marks the setting as "Conflict" in the device's configuration report, and neither value is applied. The device keeps its current or default state for that setting. At the profile level, both profiles can still show as "applied", which masks the fact that individual settings within them aren't being enforced.

Common conflict scenarios

Three scenarios come up most often:

Scenario	What happens
Microsoft baseline plus endpoint security profile	The security baseline configures Defender AV settings. A separate endpoint security antivirus profile configures some of the same settings, and both deploy to the same devices.
Microsoft baseline plus Settings Catalog profile	You deployed the baseline for quick wins, then started building CIS-aligned profiles through the Settings Catalog. The CIS profiles overlap with baseline settings.
Multiple Settings Catalog profiles	Two profiles created by different team members both configure BitLocker settings with different values.

Detection

Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
 
# Get all configuration policies
$policies = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies"
 
# Fetch settings for each policy (requires separate call per policy)
$settingMap = @{}
foreach ($policy in $policies.value) {
    $settings = Invoke-MgGraphRequest -Method GET `
        -Uri "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies/$($policy.id)/settings"
 
    foreach ($setting in $settings.value) {
        $defId = $setting.settingInstance.settingDefinitionId
        if (-not $defId) { continue }
 
        if ($settingMap.ContainsKey($defId)) {
            $settingMap[$defId] += @($policy.name)
        } else {
            $settingMap[$defId] = @($policy.name)
        }
    }
}
 
# Find conflicts (same setting in multiple profiles)
$conflicts = $settingMap.GetEnumerator() | Where-Object { $_.Value.Count -gt 1 }
 
Write-Host "Settings configured in multiple profiles: $($conflicts.Count)"
$conflicts | ForEach-Object {
    Write-Host "`n  Setting: $($_.Key)"
    $_.Value | ForEach-Object { Write-Host "    Profile: $_" }
}

Resolution

The resolution is architectural rather than technical. Choose one of two patterns:

Pattern	Approach
Pattern A: baseline plus supplements	Deploy the Microsoft baseline as your foundation. Any additional settings (from CIS or your own requirements) go into supplementary profiles that explicitly avoid overlapping with baseline settings. This means reviewing every CIS recommendation against the baseline export before creating supplementary profiles.
Pattern B: Settings Catalog only	Don't use the Microsoft baseline template at all. Implement everything through the Settings Catalog (or endpoint security profiles for Defender/Firewall/ASR). This gives you full control and eliminates the conflict risk, but requires more upfront work.

I recommend Pattern B for mature organisations already running a Configuration as Code pipeline. Pattern A is pragmatic for teams that need quick wins now and will mature their approach over time.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Implementing CIS benchmarks in Intune: building Settings Catalog profiles

Whether you choose Option 2 or 3, you'll need to create Intune profiles from the comparison output. Here's the pattern for translating settings into Settings Catalog profiles via Graph API.

Create a Settings Catalog profile

Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"
 
# Create a profile for account policies (CIS Section 1)
$profileBody = @{
    name = "SEC - Account Policies (CIS L1)"
    description = "CIS Windows 11 Level 1 - Account Policies. Deviations documented in deviation tracker."
    platforms = "windows10"
    technologies = "mdm"
    settings = @(
        @{
            settingInstance = @{
                "@odata.type" = "#microsoft.graph.deviceManagementConfigurationSimpleSettingInstance"
                settingDefinitionId = "device_vendor_msft_policy_config_devicelock_devicepasswordhistory"
                simpleSettingValue = @{
                    "@odata.type" = "#microsoft.graph.deviceManagementConfigurationIntegerSettingValue"
                    value = 24
                }
            }
        },
        @{
            settingInstance = @{
                "@odata.type" = "#microsoft.graph.deviceManagementConfigurationChoiceSettingInstance"
                settingDefinitionId = "device_vendor_msft_policy_config_localpoliciessecurityoptions_accounts_blockmicrosoftaccounts"
                choiceSettingValue = @{
                    "@odata.type" = "#microsoft.graph.deviceManagementConfigurationChoiceSettingValue"
                    value = "device_vendor_msft_policy_config_localpoliciessecurityoptions_accounts_blockmicrosoftaccounts_3"
                    children = @()
                }
            }
        }
        # Additional settings from CIS mapping...
    )
} | ConvertTo-Json -Depth 10
 
$profile = Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies" `
    -Body $profileBody -ContentType "application/json"
 
Write-Host "Created profile: $($profile.name) (ID: $($profile.id))"

Profile naming convention

Use a naming convention that tells you where a setting came from and why:

SEC - {Category} ({Source} {Level})

Examples:

SEC - Account Policies (CIS L1) - CIS Level 1 account policy settings
SEC - ASR Rules (MS Baseline + CIS L1) - merged settings from both sources
SEC - Credential Guard (CIS L2) - CIS Level 2, deployed only to high-security devices
SEC - Defender AV (MS Baseline) - Microsoft baseline Defender settings, no CIS additions

This convention makes the policy list self-documenting. Anyone looking at Intune can see the source and scope of each profile without opening it.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Maintaining your baseline over time

Deploying a baseline takes about 20% of the total effort involved in running one; maintaining it accounts for the other 80%.

Quarterly review cycle

Every quarter, review your security profiles against three inputs:

New Microsoft baseline versions. Did Microsoft release an updated baseline? What changed, and do the changes affect your environment?
CIS benchmark updates. CIS publishes updates less frequently, typically annually, but when it does, the changelog tells you exactly which recommendations changed and why.
Your deviation tracker. Are the deviations you documented still valid? Has the business context changed? Have the applications that caused compatibility issues been updated or retired?

# Check for new baseline template versions
$templates = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/templates?`$filter=templateType eq 'securityBaseline'"
 
$templates.value |
    Select-Object displayName, publishedDateTime, versionInfo |
    Sort-Object publishedDateTime -Descending |
    Format-Table -AutoSize

Drift detection

If you're running Configuration as Code, drift detection is built into your pipeline. If you're not, periodically export your deployed profiles and compare them against your intended state:

# Export current deployed profile settings
$policySettings = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies('$profileId')/settings"
 
$currentSettings = $policySettings.value | ForEach-Object {
    [PSCustomObject]@{
        SettingId = $_.settingInstance.settingDefinitionId
        Value     = ($_.settingInstance | ConvertTo-Json -Depth 5)
    }
}
 
# Compare against your source-of-truth (e.g. exported JSON from your repo)
$intendedSettings = Get-Content "profiles/sec-account-policies.json" -Raw |
    ConvertFrom-Json
 
# Diff logic here - full implementation in companion repo
Write-Host "Deployed settings: $($currentSettings.Count)"
Write-Host "Intended settings: $($intendedSettings.settings.Count)"

The Configuration as Code post covers the broader drift detection and remediation pattern, and if you're exploring AI-assisted tooling for this, the AI endpoint management post covers automated drift detection with Copilot. For security profiles, drift is more than a hygiene problem: a setting configured to "Block" that has drifted to "Not configured" is a gap in your defences that nobody notices.

sbd.org.uk · No. 05Intune Security Baselines vs CIS Benchmarks

Intune security baseline implementation timeline

Here's the recommended implementation sequence, assuming you're starting from scratch or replacing an ad-hoc set of profiles with a structured approach.

Start with the comparison and decision (weeks 1-2), then move into piloting and progressive rollout. The key is to resist the urge to deploy everything at once. Each phase validates the previous one.

Weeks	Activity
Week 1	Export the current Microsoft baseline template, map it against CIS Level 1, and produce the deviation report.
Week 2	Review the deviation report with your security team. Choose Option 1, 2 or 3 from the decision framework, and document your choice and the rationale.
Weeks 3 to 4	Create your profiles (baseline, supplementary, or custom). Deploy to a pilot ring of 20 to 50 devices, and enable ASR rules in audit mode.
Weeks 5 to 8	Review application compatibility issues from the pilot, and document deviations for settings that need adjusting. Expand deployment ring by ring, and promote ASR rules from audit to block, low-risk rules first.
Week 9 onwards	Full deployment across managed devices, with the deviation tracker complete. ASR rules run in block mode for low and medium risk rules, and the quarterly review cycle begins.

Next steps: Conditional Access, ASR and your security stack

Security baselines are one layer of your endpoint hardening posture. They harden the OS configuration, but they don't cover the full attack surface. The next layer is the endpoint security stack itself: Defender Antivirus configuration and Defender for Endpoint capabilities. The ASR rules covered in this post deserve their own look at operational practice, beyond deployment mechanics.

If you haven't already established your Conditional Access baseline, do that first. Identity security is the foundation. Endpoint hardening builds on top of it.

If you're still on E3 and wondering whether MDE P2 is worth the investment for ASR reporting and advanced hunting, the E3 vs E5 decision framework works through that calculation. And if your broader endpoint management practice needs structure, the standardisation post covers the principles that make all of this sustainable.

If you want to skip the spreadsheet work and do this interactively, BaselineForge automates the comparison, deviation tracking, and policy export workflow from this post. Load your config to see the gaps, then export what's missing.

Treat your security baseline as something that keeps changing, not a one-time deployment. It evolves with your application estate and the frameworks you're measured against, and it deserves the same review discipline as the rest of your configuration.

Intune Security Baselines vs CIS Benchmarks

What Microsoft's security baselines actually are

What they get right

Where they fall short

What CIS benchmarks offer instead

Structure

The trade-off

How to compare Intune baselines against CIS benchmarks

Step 1: export the Microsoft baseline

Step 2: map CIS recommendations

Step 3: diff the two

Step 4: document your deviations

Automate this with BaselineForge

Microsoft baseline vs CIS: which should you use?

Option 1: deploy Microsoft's baseline as-is

Option 2: use CIS as your primary framework

Option 3: hybrid (my recommendation for most organisations)

Attack surface reduction: Intune's most underdeployed security feature

Intune ASR rules: priority order for deployment

The phased rollout

Handling baseline conflicts in Intune

Common conflict scenarios

Detection

Resolution

Implementing CIS benchmarks in Intune: building Settings Catalog profiles

Create a Settings Catalog profile

Profile naming convention

Maintaining your baseline over time

Quarterly review cycle

Drift detection

Intune security baseline implementation timeline

Next steps: Conditional Access, ASR and your security stack

Get the next one by email