CIS Benchmark Level 1 vs Level 2: When to Use Which

What the Two Profiles Are For

Every CIS benchmark — Windows Server, Linux, Azure, Kubernetes, browsers — publishes two profile levels: Level 1 and Level 2. The CIS Center for Internet Security designed the split deliberately to acknowledge that one configuration baseline cannot serve every organization or every asset class within the same organization.

Level 1 (L1) is the practical baseline. It contains settings that meaningfully reduce attack surface without significantly disrupting business functionality, enterprise applications, or user productivity. L1 is designed to be deployable across general-purpose endpoints in most enterprises with minimal compatibility or workflow trade-offs.

Level 2 (L2) layers additional, stricter settings on top of L1. These settings are appropriate for high-security environments where the protection benefit outweighs reduced compatibility — classified networks, financial services backbones, healthcare data systems, government workloads, and similar contexts.

The relationship is additive, not exclusive. An L2 deployment includes everything in L1 plus the L2-specific controls. There is no "L2 only" profile.

Concrete Difference in Control Density

The L1 vs L2 split varies by benchmark, but a representative example illustrates the magnitude:

Benchmark L1 controls L2 controls (additional)

CIS Windows 11 Enterprise v5.0.0 ~390 ~165

CIS Windows Server 2022 v2.0.0 ~370 ~165

CIS Ubuntu 24.04 LTS v1.0.0 ~225 ~85

CIS RHEL 9 v2.0.0 ~210 ~85

CIS Microsoft Azure Foundations v2.1.0 ~135 ~65

CIS Kubernetes v1.10.0 ~85 ~30

Across the major OS benchmarks, L2 typically adds 40-50% more controls on top of L1.

What Kinds of Settings L2 Adds

L2 controls fall into a few recognizable patterns:

Stricter authentication — longer minimum password lengths, more aggressive lockout thresholds, mandatory smartcard authentication for privileged accounts

Aggressive logging — higher-volume audit categories enabled, longer retention windows, additional security event subcategories

Restricted services — additional Windows services disabled, additional Linux daemons removed

Hardened cryptographic settings — narrower TLS cipher suites, deprecated algorithms explicitly disabled, FIPS-validated modules required

Reduced functionality — features disabled that L1 leaves enabled (PowerShell v2, SMB v1, legacy authentication protocols)

Tighter file permissions — stricter ACLs on sensitive directories, restricted access to system configuration files

More aggressive patching — shorter patch deployment SLAs, automatic update enforcement

The trade-off is real. Some L2 settings break legacy applications, interfere with vendor support, or impose user friction. The CIS guidance makes this trade-off explicit: L2 is for environments where the security benefit is worth the friction.

Operational Impact of L2

When you move an asset class from L1 to L2, you typically encounter:

Application compatibility issues. Legacy line-of-business applications may rely on disabled services, deprecated protocols, or relaxed permissions. Each issue is fixable, but each requires investigation, vendor coordination, or compensating controls.

Help desk volume. Stricter authentication policies generate password reset and account lockout tickets. Stricter session timeouts disrupt workflows. Help desk staffing assumptions need adjustment.

Patch management discipline. L2 patch SLAs are shorter. Organizations that comfortably meet L1 patch windows may need additional patch automation to meet L2.

Audit and logging volume. L2 audit categories generate substantially more events. SIEM ingestion costs, log retention costs, and analyst capacity all need to scale.

Update on third-party agents. Some endpoint security tools, monitoring agents, or remote management software interact poorly with L2 settings. Vendor compatibility verification is part of L2 deployment.

None of these are blockers. They are budgeted realities. L2 deployment that ignores them produces operational regressions that get reverted, leaving the environment in an undefined state.

Choosing the Right Profile per Asset Class

The right profile is asset-class-specific, not organization-wide. A typical mature deployment uses both profiles strategically:

L1 is appropriate for:

General-purpose user workstations

Standard production servers handling non-sensitive workloads

Development and test environments

Cloud infrastructure foundations (Azure, AWS, M365 baseline configurations)

Container hosts running general-purpose workloads

Browser configurations across the enterprise fleet

L2 is appropriate for:

Domain controllers and identity infrastructure

Database servers handling regulated data (PCI, PHI, classified)

Administrative jump hosts and privileged access workstations

Servers in DMZ or internet-facing positions

Backup infrastructure and key management systems

Workloads under FedRAMP High, IL4/IL5, or equivalent classified baselines

Compliance-critical systems where audit findings carry regulatory penalty

Most organizations operate L1 across the broad fleet and apply L2 selectively to critical systems. The asset class boundary is enforced through Group Policy scopes, Ansible inventories, Kubernetes labels, or whatever segmentation tooling the organization uses.

When Auditors Care About Profile Selection

Auditors generally do not mandate a specific profile level — they ask about the organization's risk-based selection of profile per asset class. The defensible position is:

1. A documented policy that defines which asset classes require L1 and which require L2

2. Risk justification for the boundary (data sensitivity, exposure, regulatory obligation)

3. Configuration enforcement that aligns with the policy

4. Continuous monitoring that detects drift away from the assigned profile

What auditors flag is inconsistency: assets nominally classified for L2 that are actually configured to L1, or asset classes assigned to L1 that should be at L2 based on the organization's own risk criteria.

How to Operationalize Mixed-Profile Deployments

Running L1 and L2 simultaneously across an enterprise fleet is a configuration management problem. The patterns that work:

Tag-based scoping. Tag every asset with its required profile (L1 or L2) at provisioning time. Use the tag as the scope for configuration enforcement and for compliance scanning.

Per-profile baselines. Maintain two configuration baselines (L1 and L2) per platform. Apply the corresponding baseline at provisioning based on tag.

Per-profile compliance scanning. Compliance tooling must scan each asset against its assigned profile, not against a global default. Reporting should clearly distinguish L1 vs L2 compliance percentages.

Drift detection per profile. When an asset changes assigned profile (e.g., a workload moves from non-regulated to regulated), the configuration baseline reapplies automatically. Drift detection compares against the currently assigned profile, not a historical one.

Exception management per profile. Some L2 controls cannot be implemented in some environments due to vendor or application constraints. Formal exceptions document the specific L2 controls that cannot apply, with compensating controls and time-bounded approvals.

How CISGuard Handles L1 / L2 Profiles

CISGuard supports both profiles for every benchmark and lets you assign profile per asset group. The same underlying CIS content scanner runs against the appropriate profile per asset, and per-profile compliance scoring rolls up to a unified dashboard.

A CISGuard deployment typically operates with several profile assignments:

Workstation fleet — L1 across endpoints, drift-monitored continuously

General-purpose servers — L1, with L2-specific exceptions documented per host

Domain controllers — L2, scanned hourly

Privileged access workstations — L2, scanned hourly

Cloud foundations — L1 baseline plus selected L2 controls per regulatory requirement

Container infrastructure — L1 across general-purpose, L2 on isolated control-plane nodes

Because every scan is timestamped and immutable, audit evidence shows the assigned profile and the compliance state per asset over time. When you reassign an asset to a different profile, CISGuard rescans against the new baseline and the historical record reflects the change.

See how CISGuard handles per-profile scanning or request a profile-strategy review.