CIS is one of the most cited security frameworks in the industry and also one of the most misunderstood. Half the articles online conflate two different CIS products into one. Most of the rest treat Level 1 and Level 2 as marketing tiers – basic versus advanced – rather than what they actually are. The framework deserves better, and so does anyone trying to apply it to a real Intune tenant.
Before the L1 and L2 conversation makes any sense, it’s worth separating what CIS publishes. The Center for Internet Security produces two distinct things that routinely get blended together in commentary.
The first is the CIS Critical Security Controls – eighteen high-level safeguards organized by function, with Implementation Groups IG1, IG2, and IG3 that describe organizational maturity. Controls describe what a security program should be doing. They don’t tell you how to configure anything.
The second is CIS Benchmarks – over a hundred platform-specific hardening guides covering operating systems, cloud services, containers, databases, browsers, and MDM products. Each benchmark is a prescriptive list of configuration recommendations for a single technology. The CIS Microsoft Intune for Windows 11 Benchmark is one of these. It tells you exactly which settings to configure and what to set them to.
Level 1 and Level 2 belong to Benchmarks, not Controls. This is the distinction that gets lost most often, and it matters because it anchors everything that follows.
Every CIS Benchmark is internally organized into at least two profiles, Level 1 and Level 2. These are not difficulty tiers or maturity levels. They are scopes.
Level 1 is the profile CIS considers applicable to a general-purpose environment. The settings within it are ones the community expects an organization can apply broadly without significant operational pain. Password length, account lockout, BitLocker enablement, screen lock timeout, disabling guest accounts, baseline firewall defaults – these sit in Level 1. The emphasis is on hardening that doesn’t fight the business.
Level 2 is the profile CIS considers appropriate when security takes priority over functionality. It’s intended for environments where operational friction is acceptable in exchange for reduced attack surface. Stricter audit subcategories, PowerShell transcription enabled at the system level, tighter SMB and NTLM constraints, more aggressive account restrictions – these are typical Level 2 territory. Level 2 includes Level 1. It doesn’t replace it.
The common framing of “Level 2 is better security” misses the point. Level 2 is more security, at a cost. The baseline a typical enterprise Windows fleet should actually target is Level 1. Level 2 exists for device classes where the additional friction is acceptable – privileged access workstations, specific regulated workloads, isolated device groups – not as a default everyone should aim for.
Level 2 isn’t better security. It’s more security, with the understanding that you will pay for it operationally.
Choosing a level is the easy part. The harder part is turning the benchmark into enforced configuration across a fleet of managed Windows devices.
A CIS Benchmark is a reference document. The Windows 11 Intune benchmark at v4.0.0 runs to several hundred recommendations in the Level 1 profile alone. Every recommendation has a CSP or Group Policy analog, a defined setting value, and a rationale. What it does not have is a finished Intune deployment.
To actually operationalize any CIS level in Intune, you need four things. An enforceable mapping from each recommendation to a specific Intune policy setting. A modular policy structure so settings can be scoped, excluded, and targeted independently as the environment demands. A documented record of every recommendation you’re not enforcing, with a defensible reason for each. And a versioning discipline that tracks benchmark revisions – CIS updates its benchmarks, and what was canonical in v3.0.1 is partly obsolete in v4.0.0.
None of that is included in the PDF. The benchmark is an input. You still need something to deliver it.
There are three realistic ways to turn a CIS alignment goal into actual Intune policy. Each comes with tradeoffs worth naming directly.
The first is Microsoft’s own Intune Security Baseline for Windows. It’s shipped by Microsoft, enabled inside the Intune admin center, and represents Microsoft’s opinion on a secure Windows configuration. It does not claim CIS alignment and it doesn’t try to match the benchmark structure. It’s monolithic – a single policy containing a large set of settings – which makes granular scoping and targeted exclusion difficult. For organizations that want Microsoft’s opinion and don’t need CIS mapping, it’s a valid starting point. For anything else, it’s a poor fit.
The second is building your own. Start from the CIS Benchmark PDF, translate every recommendation into Intune settings, deploy, document, and maintain it yourself. This is the most accurate path to actual CIS alignment, and for organizations with the engineering capacity to sustain it, it works. The cost is real. Every benchmark revision triggers a review of every setting. Every deviation needs its own rationale. Every new customer tenant starts the work from zero. The majority of teams that start this path don’t finish it, or finish once and never update it.
The third is using a community-maintained baseline that has already done the translation. The most prominent in the Intune space is OpenIntuneBaseline, currently at Windows v3.8. OIB is a set of Settings Catalog and Endpoint Security Intune policies, structured modularly by control surface – Defender Antivirus, BitLocker, LAPS, ASR, Edge, OneDrive, Office, Windows Update, device security, and so on. Each policy has a version number and a change log. Settings are grouped by category and by whether they target devices or users. Policies can be imported, excluded, or re-scoped independently.
OIB does not claim to be CIS. Its documentation is explicit on this point – the project draws from CIS, the NCSC Device Security Guidance, the ACSC Essential Eight, and Microsoft’s Security Baselines, but it is not a pure implementation of any of them. The author’s stated position is that security frameworks are sets of recommendations, not unmovable requirements, and that managability and user experience are legitimate inputs into baseline design.
Where OIB differs from CIS Intune Level 1, it publishes the reason. The project maintains a rationale document listing every L1 setting it deliberately does not enforce, with a line of explanation for each. The reasons cluster into recognizable patterns.
Some settings target domain-joined behavior that doesn’t apply to Entra-joined devices. Hardened UNC paths for NETLOGON and SYSVOL shares, registry policy processing during background cycles, and enumeration of domain users on local machines are all meaningful in an on-premises world and silent no-ops in a cloud-native tenant. Enforcing them changes nothing. Documenting why they’re skipped prevents someone from re-introducing them later.
Some settings conflict directly with modern Windows identity. Several L1 password complexity, length, and history settings were written for local account policy. Applying them breaks Windows Hello for Business PIN creation. When identity is Entra-managed and the sign-in experience is WHfB, device-local password policy is the wrong control surface, and CIS itself is in the process of removing several of these in the next benchmark revision.
Some settings are handled more effectively by a different product. Process creation command-line auditing captures sensitive data into a log that standard users can read. A properly configured EDR captures the same telemetry in a place where standard users cannot. Update deferral and quality update scheduling settings are managed by Autopatch or Windows Update for Business rings, not by static policy values. Password complexity belongs in Entra, not in device-local security options.
Some settings cannot be enforced by Intune at all. Disabling specific Windows services – ICS, SSDP Discovery, UPnP Device Host, Windows Mobile Hotspot – is achievable via Group Policy on a domain-joined device, but the corresponding CSP simply doesn’t exist in Intune. Listing the recommendation as “not implemented” with “no policy path available” is more honest than pretending the setting is applied.
And some settings enforce behavior Windows 11 already does by default. Safe DLL search mode, disabled picture-password sign-in, shell protocol protected mode – the OS ships configured this way. Deploying a policy to enforce a default adds audit noise without improving posture.
What you end up choosing depends on what you’re optimizing for. If Microsoft’s opinion is sufficient and granularity isn’t a requirement, the built-in Intune baseline covers the ground. If pure CIS alignment is the deliverable – because a contract, an auditor, or a framework mandate demands it – then the work is to build and maintain that mapping yourself, in full, with the maintenance cost that implies. If the goal is a defensible, modular, version-tracked baseline that’s informed by CIS but shaped for cloud-native Intune reality, something like OIB is what that looks like when someone has already built it.
The rationale document is the part worth reading carefully. Every deviation from CIS L1 is listed, with its reason. Agreement with each decision is a judgment call. Disagreement is permitted. What matters is that the reasoning exists in writing, grounded in the specifics of Entra-joined, Intune-managed, cloud-native Windows – the environment CIS doesn’t optimize for, but the one most modern tenants actually live in.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.1.1] The Modular Baseline Playbook: Deploying OIB in Practice
Next: [5.1.3] The OIB Deployer: Shipping the Baseline Without the Ceremony ›
