What is CIS Level 1 vs Level 2 hardening? A Practitioner's Definition
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:
- Deploy Level 1 broadly
- Validate stability
- Evaluate Level 2 by asset class
- 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
Related terms
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.