Windows 11 Security Baseline 2026: CIS Benchmark vs DISA STIG vs Microsoft SCT

Most enterprise security teams know they need a Windows 11 hardening baseline. Far fewer know which baseline to apply, why the three dominant frameworks diverge on hundreds of settings, and which one will trigger a failed compliance scan six months after deployment. The Microsoft Security Compliance Toolkit, the CIS Benchmark for Windows 11, and the DISA STIG each represent a different philosophy about who the adversary is, what compliance framework governs your organization, and how much operational disruption is acceptable. Picking the wrong one does not just mean extra paperwork. It means either a broken endpoint fleet that IT has to roll back under pressure, or a passed pen test followed by a failed CMMC Level 2 assessment. This post breaks down all three frameworks in depth, maps out the settings that matter most, and gives you a deployment path via Intune and Group Policy that works at scale.

Understanding what you are deploying starts with knowing who wrote the baseline and for whom. The three frameworks share significant overlap but were designed for distinct audiences and regulatory contexts.

Microsoft Security Baseline (MSB): Published by the Microsoft Security Compliance Toolkit team, this baseline ships as a GPO backup package and an Intune-importable JSON set. It is updated with each major Windows release and represents Microsoft's own recommendation for securing Windows in a generic enterprise environment. It does not target any specific compliance framework. It is the easiest to deploy and the least opinionated of the three. Think of it as the sensible default before you layer compliance requirements on top.

CIS Benchmark for Windows 11: Published by the Center for Internet Security, the CIS Benchmark defines two profiles. Level 1 covers broadly applicable settings that any enterprise can implement without breaking standard workflows. Level 2 adds defense-in-depth controls intended for high-security environments where additional friction is acceptable. CIS Benchmarks are widely accepted as evidence of due care in SOC 2, ISO 27001, and HIPAA audits. CIS-CAT Pro is the primary automated assessment tool.

DISA STIG for Windows 11: Published by the Defense Information Systems Agency, the STIG is the mandatory baseline for all U.S. Department of Defense endpoints. It is also required for CMMC Level 2 and Level 3 certifications when organizations handle Controlled Unclassified Information. STIGs use a CAT I, CAT II, CAT III severity scale where CAT I findings are the most critical. StigViewer and SCAP-compliant tools like Nessus are the primary assessment tools. STIGs are more prescriptive than CIS and updated on a faster cadence tied to DoD security requirements.

The table below maps the four dimensions that matter most when selecting a baseline for enterprise deployment.

The Microsoft Security Compliance Toolkit (SCT) is a free download from the Microsoft Download Center and contains three key components that security teams need to understand before touching Group Policy or Intune.

LGPO.exe: A command-line utility that applies Local Group Policy settings from a text file without requiring Active Directory or a domain-joined machine. This is the fastest way to apply the Microsoft baseline to a standalone machine or a golden image. The syntax is straightforward: LGPO.exe /g <GPO-backup-folder> applies an exported GPO backup directly to local policy.

PolicyAnalyzer: A GUI tool that compares policy settings across multiple GPO backups, registry exports, or local policy states. Security engineers use it to diff the Microsoft baseline against their current GPO to identify gaps before deployment. It can also compare your current Intune configuration against the baseline to surface missing settings. This is the most useful pre-deployment tool in the toolkit.

GPO Backup Packages: The toolkit ships with a complete set of GPO backups that you import directly into Group Policy Management Console. Each backup is categorized by product area: Windows Security, Defender, BitLocker, and so on. You import the relevant backups, link them to the target OU, and run a gpresult to verify application.

For Intune deployments, Microsoft publishes a companion JSON file that you import via the Endpoint Security blade under Security Baselines. This provides a no-code path to applying baseline settings across your managed device fleet without ADMX templates or OMA-URI strings. The Intune baseline version tracks the Windows release version, so you will see separate baselines for Windows 11 23H2 and 24H2.

The CIS Benchmark's two-level structure is intentional. Level 1 is designed to be safe for any enterprise to apply wholesale. Level 2 assumes a high-security environment where the security team has accepted the operational trade-offs. Understanding which Level 2 settings cause the most friction is essential before you commit to L2 across your fleet.

Level 1 highlights: L1 enforces password complexity, account lockout thresholds, audit policy configuration, Windows Firewall profiles, and Defender AV settings. These settings align closely with the Microsoft baseline and introduce minimal workflow disruption. L1 also covers Remote Desktop hardening: requiring NLA, restricting RDP to specific security layers, and disabling clipboard redirection.

Level 2 additions that create friction: Several L2 settings are technically correct from a security standpoint but regularly break enterprise workflows. BitLocker enforcement with TPM+PIN pre-boot authentication conflicts with environments where unattended reboots are required (servers, VDI pools, patch cycles). LAPS (Local Administrator Password Solution) enforcement via L2 is correct, but it requires LAPS to already be deployed in your environment or you will lock out local admin access. Credential Guard enforcement via L2 breaks legacy NTLM-dependent applications and remote desktop connections using CredSSP in some configurations. PowerShell Constrained Language Mode, enforced in L2, breaks many legitimate admin scripts and monitoring agents that rely on .NET reflection or Add-Type.

The recommended approach: deploy L1 universally, then scope L2 to high-value asset groups such as privileged access workstations, finance endpoints, or systems with direct access to sensitive data stores. Use Intune's dynamic device groups or GPO security filtering to target L2 precisely.

The DISA STIG for Windows 11 operates on a three-category severity model that determines remediation urgency. Understanding the CAT structure is essential if you are preparing for a DoD assessment or a CMMC Level 2 audit.

CAT I findings represent the highest severity: vulnerabilities that provide direct, immediate pathways for an adversary to gain privileged access. Examples include disabling the built-in administrator account, preventing anonymous SID enumeration, and enforcing screen lock. CAT I findings must be remediated before a system is authorized to operate in a DoD environment. There is no waiver process for CAT I in most DoD contexts.

CAT II findings cover settings that significantly reduce the attack surface but do not represent an immediate takeover vector. The majority of STIG checks fall in this category: audit policy settings, Defender configuration, PowerShell script block logging, event log size requirements, and RDP security settings. CAT II findings must be remediated within a defined timeline or documented with an accepted risk.

CAT III findings are informational or best-practice settings where the risk of non-compliance is low. They still need to be documented but rarely block an Authorization to Operate (ATO).

When is the STIG required: Any organization in the Defense Industrial Base (DIB) handling CUI under DFARS clause 252.204-7012 must implement CMMC Level 2, which maps directly to NIST SP 800-171. DISA STIGs are the accepted implementation standard for the NIST 800-171 controls in DoD contexts. If your organization is pursuing a CMMC Level 2 certification and your assessor is from a C3PAO, expect STIG compliance checks on all Windows endpoints.

StigViewer: The primary tool for consuming STIG content is StigViewer, a free Java-based application available from the DoD Cyber Exchange (public.cyber.mil). You import the XCCDF STIG file, create a checklist, and mark each check as Open, Not a Finding, Not Applicable, or Not Reviewed. StigViewer exports a checklist (.ckl) file that you provide to your assessor. For automated scanning, SCAP-compliant tools such as SCC (SCAP Compliance Checker, also free from DoD Cyber Exchange) or Nessus with the Compliance plugin can auto-populate your checklist based on live scan results.

Across all three frameworks, a core set of security controls appears consistently. The divergence is in enforcement level, configuration specifics, and how aggressively the setting is applied.

Credential Guard: All three frameworks recommend enabling Credential Guard. The difference is in how they handle legacy compatibility. Microsoft SCT enables it as a recommended setting with a UI toggle. CIS L2 enforces it via policy with no bypass. DISA STIG makes it a CAT II finding if not enabled on supported hardware. Credential Guard requires UEFI Secure Boot, TPM 2.0, and 64-bit Windows, which eliminates some legacy hardware from compliance.

LAPS (Local Administrator Password Solution): Microsoft SCT and CIS both enforce LAPS enrollment. The DISA STIG enforces unique local admin passwords, which LAPS satisfies. The critical operational dependency: LAPS requires either Azure AD LAPS (Entra ID) or on-premises LAPS with the AD schema extension. If your AD schema is not extended before you enforce LAPS via policy, you will disable local admin access without a recovery mechanism.

BitLocker: All frameworks enforce BitLocker encryption at rest. The configuration diverges on pre-boot authentication. CIS L2 requires TPM+PIN. Microsoft SCT requires TPM but does not mandate PIN. DISA STIG requires BitLocker with a startup PIN or startup key for removable drives used in high-classification environments.

ASR Rules (Attack Surface Reduction): CIS and DISA both reference Attack Surface Reduction rules. Microsoft SCT configures them in Audit mode by default for several rules and Block mode for the most critical. CIS L2 enforces Block mode for all ASR rules that do not conflict with standard enterprise software. ASR rules that cause the most false positives: Block Office applications from creating child processes (breaks some macro-driven workflows), Block credential stealing from LSASS (can conflict with some DLP agents), and Block untrusted and unsigned processes from USB.

PowerShell Constrained Language Mode: CIS L2 enforces CLM via AppLocker or WDAC policy. DISA STIG enforces PowerShell script block logging and module logging as CAT II findings but does not mandate CLM. Microsoft SCT does not enforce CLM. This is the widest divergence between frameworks and the one most likely to break monitoring and automation tooling.

SmartScreen and Exploit Protection: All three frameworks enforce SmartScreen for both the browser and the shell. Exploit Protection settings (DEP, ASLR, CFG) are uniformly enforced across frameworks with minimal divergence in specific values.

Remote Desktop Hardening: All three require NLA, restrict encryption to highest levels, set a session timeout, and disable clipboard and drive redirection. DISA STIG additionally mandates a system use notification banner before login, which is a common CAT II finding that organizations miss because it requires a registry key for the legal notice text, not just enabling a policy.

Intune provides three deployment mechanisms for security baseline settings, and the right choice depends on the setting type and your target framework.

Security Baselines (native import): For the Microsoft Security Baseline, Intune's Security Baselines feature under Endpoint Security provides a pre-built profile you can create and assign in minutes. This is a curated subset of MDM CSP settings that maps to the Microsoft SCT GPO package. It does not cover every SCT setting but covers the most impactful ones. It supports version tracking so you can see which devices are on which baseline version and identify drift.

Settings Catalog: The Settings Catalog in Intune exposes thousands of individual MDM CSP settings through a searchable UI. For CIS and DISA STIG settings that do not have a native Security Baseline equivalent, Settings Catalog is the primary path. CIS publishes a settings catalog mapping for SecureSuite members that identifies which catalog entry maps to each benchmark recommendation. Search by the Windows policy path or the setting name. Settings Catalog configurations support conflict detection across policies, which helps identify overlapping settings between your CIS profile and your existing Defender or BitLocker profiles.

Custom OMA-URI: Some security settings have no Settings Catalog entry and require a custom OMA-URI policy. This is most common for settings that are only exposed via the Policy CSP but not yet surfaced in the catalog UI, and for settings that require specific data types (binary, base64). DISA STIG settings that require OMA-URI include some of the more granular audit policy subcategory settings and specific registry-based controls not yet in the catalog.

Compliance Policies: Separate from configuration profiles, Intune Compliance Policies define the health state requirements a device must meet to be considered compliant. These integrate with Conditional Access to block non-compliant devices from accessing corporate resources. For a CIS or STIG baseline, create a Compliance Policy that checks for: BitLocker enabled, Secure Boot enabled, code integrity enabled, and minimum OS version. The Compliance Policy does not configure these settings but verifies they are in place, giving you a real-time compliance dashboard across your device fleet.

For organizations that are not fully Intune-managed or that maintain hybrid AD environments, Group Policy remains the primary delivery mechanism. The Microsoft SCT GPO deployment workflow is the most straightforward, and it applies equally to on-premises and hybrid environments.

Step 1: Download the SCT package and extract it. The package contains GPO backup folders named by product area. Import relevant backups into Group Policy Management Console using the Import Settings wizard on a new or existing GPO.

Step 2: Before linking the GPO to any OU, run PolicyAnalyzer to compare the baseline GPO against your existing organizational GPOs. This surfaces conflicts where your current policy overrides a baseline setting or where the baseline introduces a new setting that may conflict with application requirements. PolicyAnalyzer generates a color-coded diff that makes this review fast.

Step 3: Use security filtering on the GPO to target a pilot group of machines. Start with IT workstations or a dedicated test OU. Apply the policy and run gpresult /h gpresult.html on a target machine to verify the settings applied and identify any blocked or superseded settings.

Step 4: For CIS ADMX deployment, obtain the ADMX templates from CIS SecureSuite. Copy the ADMX files to your PolicyDefinitions folder (either on the DC's SYSVOL or the local machine for local policy testing). The ADMX files expose CIS-specific settings in the Group Policy Editor under a CIS node.

Step 5: LGPO.exe is the fastest path for golden image hardening. During your image build process, call LGPO.exe /g <path-to-SCT-backup> to apply local policy to the image before sysprepping. This ensures every device built from that image ships pre-hardened without requiring domain connectivity at build time.

Deploying a baseline without validating it is the same as not deploying it. Each framework has a corresponding validation toolchain, and enterprise security teams should run validation before signing off on deployment and on a scheduled cadence afterward.

CIS-CAT Pro: The primary automated assessment tool for CIS Benchmarks. CIS-CAT Pro is available to CIS SecureSuite subscribers and runs as a command-line or GUI tool against Windows endpoints. It scans the local machine or remote machines via WinRM, scores each benchmark section, and produces an HTML and XML report showing pass, fail, and not-applicable findings. It maps each finding to the benchmark section ID so you can trace it back to the specific GPO setting. CIS-CAT Lite is available for free but covers only a subset of checks.

StigViewer and SCC: For DISA STIG validation, the SCAP Compliance Checker (SCC) from DoD Cyber Exchange is the standard. It ingests the XCCDF/OVAL content from the STIG package, scans the target machine, and produces a results file you import into StigViewer. StigViewer populates the checklist automatically with pass/fail status for each check. This is the workflow your C3PAO assessor will recognize.

Nessus Compliance Scans: Tenable Nessus with a Compliance plugin license can run CIS, DISA STIG, and custom compliance audits against Windows endpoints. Nessus compliance audit files (.audit) are available from Tenable's repository or the CIS SecureSuite portal. Nessus is particularly useful in environments where you are already running vulnerability scans, as you can unify both vulnerability and compliance findings in a single Tenable.io dashboard.

Microsoft Intune Compliance Reports: For Intune-managed fleets, navigate to Reports > Endpoint Security and review the Security Baselines report. This shows baseline assignment coverage, device compliance percentage, and setting-level drift reports. You can filter by baseline version to identify devices that have not yet received the latest baseline update. The Device Compliance report shows which devices are failing your Compliance Policy checks, giving you a real-time view of fleet health.

After covering the technical details of each framework, the practical question is which one to deploy in your environment. The answer depends on your regulatory posture, risk tolerance, and operational constraints.

Deploying a baseline is not a one-time event. Windows 11 feature updates introduce new settings, deprecate old ones, and shift the threat landscape in ways that require baseline updates. Each of the three frameworks handles this differently, and your maintenance process needs to account for the update cadence.

Microsoft SCT updates with each Windows feature release, typically once per year. When a new SCT version drops, run PolicyAnalyzer to diff it against your current deployed baseline and identify new settings, changed values, and removed settings. Stage the update in a pilot OU before broad deployment.

CIS Benchmark updates on a quarterly cadence and uses a community consensus process. Subscribe to CIS alerts for the Windows 11 Benchmark to receive notification when a new version publishes. CIS-CAT Pro automatically picks up new benchmark content when you update the tool. Major version changes (for example, v2.0 to v3.0) often introduce breaking changes in how certain settings are assessed.

DISA STIG updates every 90 days on average, which is the most aggressive cadence of the three. New CAT I findings introduced in a STIG update are considered open immediately on all enrolled systems. Subscribe to the DoD Cyber Exchange mailing list or monitor the STIG feed via RSS. SCC picks up new XCCDF content when you download and install updated STIG packages.

For Intune-managed environments, Microsoft's built-in Security Baseline versioning makes this easier: when a new baseline version publishes, Intune prompts you to update and shows a side-by-side comparison of changed settings. You can choose to update immediately or maintain the current version while testing the new one in a pilot group.

The most important operational discipline is drift detection. Baseline settings can be overridden by application installations, end-user changes (where local admin rights are present), or conflicting Intune profiles. Schedule CIS-CAT Pro or Nessus compliance scans monthly and integrate the results into your SIEM so drift triggers an alert rather than sitting in a report no one reads.