Skip to content
eastbaycyber

What is CIS Level 1 vs Level 2 hardening? A Practitioner's Definition

FAQs 6 min read
EC
East Bay Cyber Editorial Team Reviewed 2026-07-29
Short answer

TL;DR - CIS Level 1 is the safer, broadly compatible baseline for most systems. - CIS Level 2 adds stricter controls that can affect usability or application behavior. - Start with Level 1, test Level 2 carefully, and apply it only where the risk justifies the friction.

Definition

CIS Level 1 vs Level 2 hardening refers to two implementation profiles in CIS Benchmarks. Level 1 focuses on essential security settings with minimal operational impact, while Level 2 applies more restrictive controls for higher-security environments where reduced functionality or extra admin effort is acceptable.

How it works

CIS Benchmarks break hardening guidance into specific configuration recommendations for operating systems, cloud services, network devices, containers, and applications. Those recommendations are commonly grouped into Level 1 and Level 2 so teams can choose a baseline that matches business risk and operational tolerance.

In practice, the difference is not “good security” versus “real security.” It is a tradeoff decision:

  • Level 1 aims to reduce common attack paths without breaking normal operations.
  • Level 2 aims to further reduce exposure, even if that means more restrictive defaults, more exceptions, and more testing.

A practical way to think about it:

Baseline Main goal Operational impact Best fit
CIS Level 1 Strong default security Low to moderate Most servers, endpoints, cloud workloads
CIS Level 2 Higher assurance, tighter restrictions Moderate to high Regulated, sensitive, admin-only, or isolated systems

What Level 1 usually includes

Level 1 commonly focuses on foundational controls such as:

  • Disabling unnecessary services
  • Enforcing password and lockout policies
  • Enabling logging and auditing
  • Restricting insecure protocols
  • Applying secure file permissions
  • Turning on host firewall protections
  • Requiring supported cryptographic settings

These controls generally align well with mainstream enterprise operations.

What Level 2 usually adds

Level 2 often goes further by introducing controls that may disrupt legacy apps, automation, or administrator convenience, such as:

  • Tighter access restrictions
  • More aggressive audit settings
  • Additional protocol or cipher limitations
  • Stricter kernel, service, or account controls
  • Reduced interactive access
  • Stronger restrictions on removable media, scripting, or remote administration

The exact settings vary by benchmark, but the pattern is consistent: Level 2 is harder to bypass and harder to live with.

When you’ll encounter it

You will usually encounter the Level 1 vs Level 2 decision in a few common places.

1. Building a server or endpoint baseline

Security teams often ask whether standard images should be aligned to CIS Level 1 or Level 2. For most general-purpose systems, Level 1 is the default answer because it improves security without creating constant exceptions.

2. Compliance or audit preparation

Auditors, customers, or internal governance teams may ask whether your systems are “CIS hardened.” The important follow-up question is: to what level? Saying a system is CIS aligned without naming the profile can be misleading.

3. Protecting high-value systems

You are more likely to use Level 2 on:

  • Domain controllers
  • Jump hosts
  • Bastion servers
  • Sensitive database servers
  • OT or segmented admin systems
  • Regulated workloads with strict compensating controls

4. Cloud and container hardening

In cloud environments, Level 1 often becomes the standard baseline for broad deployment. Level 2 is then selectively applied to production workloads with sensitive data, limited user interaction, or strong automation support.

Choosing between Level 1 and Level 2

The safest operational model is usually:

  1. Deploy Level 1 broadly
  2. Validate stability
  3. Evaluate Level 2 by asset class
  4. Apply Level 2 only where risk and supportability justify it

That approach avoids the common mistake of treating all systems the same.

A simple decision rule

Use Level 1 when:

  • The system supports business applications with unknown compatibility needs
  • End-user productivity matters
  • You need a secure default baseline across many assets
  • The environment includes mixed ownership or legacy dependencies

Use Level 2 when:

  • The system is highly sensitive or tightly controlled
  • Interactive use is limited
  • Applications are well understood and tested
  • You can support exceptions through change control
  • The cost of compromise is much higher than the cost of operational friction

Practitioner guidance: what to do next

If your actual question is “How do I achieve CIS Level 1 vs Level 2 hardening?” the answer is less about a single tool and more about process discipline.

Step 1: Pick the benchmark and platform scope

Do not harden from a generic checklist. Use the benchmark specific to your platform, version, and role. A Windows Server baseline, a Linux distribution baseline, and a cloud service benchmark will all differ.

Step 2: Implement Level 1 first

This gives you a defensible baseline that usually delivers strong risk reduction quickly. Apply it through:

  • Group Policy
  • MDM profiles
  • Configuration management
  • Infrastructure as code
  • Golden images
  • Cloud guardrails

Technical Notes

Example Linux validation checks:

# Verify SSH root login is disabled
grep -Ei '^
\s*PermitRootLogin' /etc/ssh/sshd_config

# Check whether a firewall service is enabled
systemctl is-enabled firewalld 2>/dev/null || systemctl is-enabled ufw 2>/dev/null

# Confirm password aging settings
grep -E '^(PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE)' /etc/login.defs

Example Windows audit check with PowerShell:

# Review local security policy export
secedit /export /cfg C:\temp\secpol.cfg

# Check firewall profiles
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

# Review audit policy
auditpol /get /category:*

Step 3: Test Level 2 in a representative environment

This is where many teams fail. Level 2 can affect services, remote access behavior, authentication flows, older middleware, and admin routines. Test with:

  • Standard application workflows
  • Patch cycles
  • Backup and recovery operations
  • Monitoring and logging agents
  • Remote management tools
  • Authentication and service accounts

Technical Notes

Common signs that a stricter baseline caused issues include:

- Authentication failures after policy changes
- Application startup errors tied to permissions or disabled protocols
- Log forwarding or monitoring agent breakage
- Remote administration failures after service or firewall changes
- Legacy TLS or cipher negotiation errors

Step 4: Document exceptions instead of weakening the baseline everywhere

If one application cannot tolerate a stricter control, create a scoped exception for that system or workload. Do not downgrade the entire environment to accommodate an edge case.

A good exception record includes:

  • Benchmark recommendation ID
  • Reason for exception
  • Business owner
  • Compensating control
  • Review date
  • Expiration date if temporary

Step 5: Continuously assess drift

Hardening is not a one-time image build. Systems drift due to patches, admins, software installs, and emergency changes. Reassess baseline alignment regularly with your existing tooling.

Technical Notes

Useful evidence sources include:

  • Configuration management reports
  • Vulnerability scanner compliance results
  • OS policy exports
  • Cloud security posture findings
  • File integrity monitoring
  • Audit logs showing policy changes

CIS Benchmarks

Prescriptive security configuration guides for specific technologies. Level 1 and Level 2 come from these benchmarks.

Security baseline

A standard set of approved settings applied across systems to reduce risk and improve consistency.

Hardening

The process of reducing attack surface by disabling unnecessary functionality and enforcing secure settings.

Configuration compliance

The practice of checking whether systems still match an approved baseline over time.

Exception management

A formal process for handling systems that cannot fully meet the standard baseline.

Bottom line

CIS Level 1 and Level 2 are not competing standards. They are two hardening profiles for different risk and operational needs. For most organizations, Level 1 should be the default baseline. Level 2 should be a selective, tested, higher-assurance profile for systems where the extra security value outweighs compatibility and support costs.

For further reading on related topics, check out our articles on CIS Benchmarks and CVE-2026-53481.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-07-29

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.