What's New - CIS Microsoft Intune for Windows 11 Benchmark v5.0.0
If v4.0.0 was about broadening coverage, v5.0.0 is about consolidation and raising the security floor. The Center for Internet Security released version 5.0.0 of the Microsoft Intune for Windows 11 Benchmark on 25th June 2026, introducing a new Device Compliance Policy section, modern SMB hardening controls, LSASS protection improvements, and the removal of a significant number of legacy or redundant recommendations.
For anyone managing Windows 11 endpoints through Intune, this release is worth setting time aside for — not least because several long-standing controls have been removed.
What is the CIS Microsoft Intune for Windows 11 Benchmark?
CIS (Center for Internet Security) benchmarks are consensus-driven security configuration guidelines built by industry practitioners. The CIS Microsoft Intune for Windows 11 Benchmark provides a prescriptive set of recommendations for hardening Windows 11 devices managed through Microsoft Intune, delivered via configuration profiles (Settings Catalog), Endpoint security policies, and Device Compliance policies.
The benchmark follows the CIS on-premises Windows OS benchmarks as closely as the MDM control surface allows. Each recommendation is mapped to a Level 1 (core baseline) or Level 2 (may affect functionality) profile, with a separate BitLocker (BL) profile for encryption-specific settings.
What's changed in v5.0.0?
Version 5.0.0 introduces roughly 22 new controls, 15 updated controls, and around 25 removed controls compared with v4.0.0. The total recommendation count drops from approximately 457 to 419 — a slightly smaller benchmark, but a more focused one.
Several sections have been renumbered because of the removals. If you maintain your own mapping spreadsheet against control numbers rather than titles or GRIDs, you will need to reconcile it. Global Recommendation IDs (GRIDs) are present throughout, as they were in v4.0.0, and remain the most reliable way to track a control across versions.
New controls
The 22 new recommendations align into three core themes.
Device Compliance policy
The headline addition is an entirely new section covering Intune Device Compliance policies — the first time the benchmark has prescribed compliance-policy settings rather than device configuration alone. Seven new controls, all Level 1, all assessed manually:
- Device Health: BitLocker — set to Require
- Device Health: Secure Boot — set to Require
- Device Health: Code integrity — set to Require
- Device Security: Firewall — set to Require
- Device Security: Trusted Platform Module (TPM) — set to Require
- Device Security: Antivirus — set to Require
- Device Security: Antispyware — set to Require
These aren't configuration settings pushed to the device. They're compliance signals that, when paired with Conditional Access, let you gate access to corporate resources on a device's actual health posture.
SMB hardening — Lanman server and workstation
All Level 1 controls that modernise SMB:
- Require Encryption (client) — set to Enabled
- Min Smb2 Dialect — set to SMB 3.1.1, on both client and server
- Enable Auth Rate Limiter and Auth Rate Limiter Delay In Ms ≥ 2000, throttling brute-force authentication against the SMB server
- Enable Mailslots — set to Disabled on both client and server
- Audit controls for insecure guest logon, and for clients/servers that don't support signing or encryption
Together these push SMB towards encrypted, signed, modern-dialect-only communication and give you visibility of any legacy traffic that would otherwise pass silently.
Additional hardening
- Allow Custom SSPs and APs to be loaded into LSASS — set to Disabled (L1). Prevents custom Security Support Providers and Authentication Packages loading into LSASS, closing a credential-interception vector.
- Require Ipps Policy — set to Enabled (L2). Forces IPP printer communication over TLS (IPPS). Assess printers first: anything using self-signed or locally issued certificates will be affected.
Notable updated controls
Tightening:
- Network security: LAN Manager authentication level — tightened from 'Send LM and NTLMv2 responses only. Refuse LM and NTLM' to 'Send NTLMv2 responses only. Refuse LM and NTLM'.
- Password Complexity (Windows LAPS) — updated to include passphrases alongside the existing complexity requirement.
- Firewall log file path controls (Domain / Private / Public) — moved from requiring a specific hard-coded path to simply requiring that a path is configured, which no longer fails environments using a non-default log location.
Profile changes (L1 → L2):
- Allow widgets — set to Not allowed
- Limit Dump Collection and Limit Diagnostic Log Collection
- Interactive logon: Do not require CTRL+ALT+DEL — set to Disabled
If your current baseline enforces these at L1, the benchmark no longer requires it — but there's nothing stopping you keeping the stricter setting where it makes sense.
Removed controls
Around 25 recommendations have been retired. They fall into a few clear groups:
- The Device Lock password cluster (9 controls). The entire set of device password recommendations — length, complexity, history, expiration, failed-attempt lockout, inactivity lock — has been removed, leaving Device Lock as an empty placeholder. Password and PIN posture on Intune-managed Windows is increasingly governed through Windows Hello for Business and account-protection policy instead.
- BitLocker startup authentication (5 controls). The 'Require additional authentication at startup' family (TPM startup, startup PIN, startup key, and BitLocker without a compatible TPM) has been removed. These GPO-era pre-boot settings are increasingly at odds with modern silicon and Autopilot deployment models.
- Redundant SMB signing controls. Microsoft network client / server: Digitally sign communications (if server/client agrees) have both gone. The stronger (always) signing controls remain, making the weaker variants redundant.
- Legacy hardening now handled elsewhere. Do not store LAN Manager hash value on next password change, MSI Always install with elevated privileges, background Group Policy refresh, and the Defer Feature Updates period control have all gone — along with the Microsoft Defender Antivirus configuration-template recommendations.
What happened to the Defender Antivirus controls?
The Defender Antivirus removal is worth calling out separately, because it does not mean the benchmark has stopped caring about antivirus.
The new Device Compliance Antivirus and Antispyware controls shift that assurance from "is this policy template configured?" to "is a WSC-registered AV solution actually running at check-in?" — a stronger and more outcome-focused position.
If you're wondering how to confirm Defender Antivirus is configured correctly, those controls have been separated out into their own benchmark: Microsoft Intune for Microsoft Defender Antivirus v1.0.0.
Top 3 new controls to implement first
1. Device Compliance policy for device health and system security (L1)
Treat the new Device Compliance section as a single item to implement, because that's how it delivers value — a compliance policy bundling all seven health signals together.
For the first time, the benchmark prescribes what a Windows 11 device must prove about itself, not just what you push to it. The seven controls require that BitLocker, Secure Boot, Code Integrity, a functioning TPM, the Windows Firewall, antivirus, and antispyware are all present and healthy — verified at each check-in, several via the Windows Health Attestation Service rather than a self-reported registry value.
On its own, a compliance policy just labels devices compliant or non-compliant. The power comes from pairing it with a Conditional Access policy that requires a compliant device to reach corporate resources. That turns device health from a dashboard metric into an enforced access gate.
Watch-outs: Devices not yet encrypted, or still encrypting, will be marked non-compliant — stage the policy and monitor the non-compliance report before tying it to Conditional Access. The Firewall check can transiently report an Error immediately after reboot or wake-from-sleep; a manual device sync re-evaluates it. Third-party AV must be registered with Windows Security Center to satisfy the Antivirus/Antispyware checks. Older hardware without TPM 2.0, or with the TPM disabled in firmware, will fail the TPM check.
2. Disable custom SSPs and APs in LSASS (L1)
LSASS is one of the most valuable targets on any Windows endpoint, holding the credential material attackers need to move laterally. This control blocks custom Security Support Providers and Authentication Packages from loading into the LSASS process, closing a well-understood technique for intercepting logon credentials.
The default state is Enabled, meaning LSASS will load custom SSPs/APs out of the box. Most tenants are therefore exposed unless they've explicitly hardened this — a high-value, low-effort win that pairs naturally with LSA protection (Run as PPL) and Credential Guard.
Watch-outs: Some legitimate third-party security or authentication products register their own SSP/AP. Test in a pilot ring before broad rollout.
3. SMB encryption and minimum SMB 3.1.1 dialect (L1)
SMB remains a heavily targeted protocol for interception and lateral movement, and much of the exposure comes from older, unencrypted, lower-dialect traffic that flows silently. These controls raise the floor: encryption required on the SMB client, a minimum dialect of SMB 3.1.1 on both client and server, and audit logging so legacy traffic becomes visible.
Watch-outs: Requiring encryption and a 3.1.1 dialect floor will break connectivity to legacy systems (Windows 7 / Server 2008 R2 and older) and to third-party NAS devices or appliances that don't support SMB v3. Enable the audit controls first, review the events, then remediate or exempt legacy endpoints before enforcing.
In summary
Version 5.0.0 is a maturity release. The arrival of Device Compliance policy recommendations moves the benchmark from "configure the device correctly" to "prove the device is healthy before it gets access" — a meaningful shift that lands best when paired with Conditional Access. Around that, the SMB and LSASS additions close well-known attack paths, while the removals strip out legacy device-password and pre-boot-authentication settings that no longer fit modern, cloud-managed Windows 11 estates.
If your devices are already aligned to v4.0.0, the practical work is threefold: stand up a Device Compliance policy and stage it carefully behind a grace period, adopt the SMB and LSASS hardening after an audit-first pilot, and reconcile your control mapping against the renumbered sections.