Endpoint Hardening with CIS Benchmarks: Where to Start

Endpoint hardening means changing the settings of users' computers and servers so that less is open to attack: switching off what is not needed and tightening what stays on. CIS Benchmarks hardening uses the CIS Benchmarks, configuration guides published by the Center for Internet Security (CIS), as the list of settings to change. The guides cover many operating systems and products and are written by experts through a consensus process. This article shows how to start without breaking users' work: pick a baseline (the standard set of settings that every device of one type should have), choose a level of strictness, test, roll out in stages, and then check that the settings stay in place.

What a baseline is, and why not write your own

A baseline is the agreed set of settings that every device of one type should have. Microsoft's guide explains why starting from a published one makes sense: Windows 10 alone had more than 3,000 Group Policy settings (a Windows feature for configuring many computers at once), not counting more than 1,800 for Internet Explorer 11, and only some of them are security-related. Working out the meaning and the right value of each one yourself takes a long time. Microsoft therefore recommends using a broadly known, well-tested baseline rather than building your own, which also helps reduce cost.

CIS also publishes the CIS Controls, a list of security measures. According to CIS's website as read on 22 October 2026, version 8.1 has 18 controls, and Control 4 is Secure Configuration of Enterprise Assets and Software. A benchmark is one source of the detailed settings behind that control.

Where to get a baseline

• CIS Benchmarks: configuration recommendations for the products of many vendors, developed by expert consensus. CIS's FAQ says the benchmarks are free to download as PDF and that other formats are for CIS SecureSuite members, so read CIS's terms of use for your own case
• Microsoft security baselines: Microsoft's recommended settings for Windows, Windows Server, Microsoft 365 Apps, and Edge, distributed through a download set called the Security Compliance Toolkit, which includes tools such as Policy Analyzer (compares sets of settings) and LGPO (applies settings to local policy), and built into Microsoft Intune (a device management service) for managed Windows devices
• NIST National Checklist Program: a public repository of security configuration checklists for IT products. It hosts copies of some checklists, mainly from the US government, and links to others. NIST SP 800-70 Rev. 5 (May 2026) explains how to use it
• OpenSCAP: open-source tools for checking systems against a security policy (compliance scanning)

A Microsoft baseline is not the same thing as a CIS Benchmark. Microsoft says that, strictly speaking, its Intune baselines are not CIS or NIST compliant, because there is no one-to-one mapping. Choose one main baseline per type of device, and do not stack several without checking for settings that conflict.

Choose a profile before you start

CIS groups its recommendations into profiles, which are levels of strictness:

• Level 1: the base recommendations. They can be applied quickly and aim to reduce the attack surface while keeping systems usable, without a large performance impact
• Level 2: an extra layer called defense in depth, for environments where security matters most. CIS warns that its recommendations can cause problems if applied without care
• STIG: contains the recommendations specific to STIGs (security configuration guides published by DISA, a US defense agency), together with the overlapping Level 1 and Level 2 items. This profile replaced the earlier Level 3

Most organizations should start with Level 1 on one device group, because it is designed to stay usable. Then apply selected Level 2 settings to systems that justify the extra strictness, such as servers holding sensitive data, and only after testing.

Roll out in stages

A safe order of work for one device group, such as newly bought laptops:

• Group the devices: by operating system version and role, because each benchmark targets a specific version (CIS lists a version number for each benchmark, and Microsoft publishes baselines per Windows version)
• Review each setting: decide whether to keep, adjust, or skip each recommendation, and write down why. Treat a benchmark as input to a decision, not a to-do list to finish
• Test first: apply it to a lab or a small pilot group before production. CIS recommends trying guidance in a test environment first to see the impact, and Microsoft does not recommend preview baselines in production
• Roll out in waves: deploy with Group Policy, Microsoft Configuration Manager, or Intune, and widen the group as the problems found are fixed
• Record exceptions: each with a reason, an owner, and a review date
• Re-check and update: compare devices with the baseline regularly, and revisit when a new Windows or benchmark version appears, because new versions can add or remove settings

What tends to break, and what to check first

Hardening is meant to stop unsafe behavior, so some things will stop working. Know the usual causes before the pilot starts:

• Users with administrator rights: Microsoft says its baselines are designed for well-managed organizations in which standard users do not have administrative rights. Removing local admin rights first makes the rest easier, see PAM Explained: Controlling Privileged Access
• Virtual machines and virtual desktops: Intune documentation says the Microsoft Defender for Endpoint baseline is optimized for physical devices and is currently not recommended for virtual machines (VM) or virtual desktops (VDI), because some settings affect remote sessions
• Conflicting settings: Intune warns that different baselines, or a baseline and other policies, can set the same setting to different values, and that defaults are in almost all cases the most restrictive, so check for conflicts, for example firewall settings if you use delivery optimization (a Windows feature that lets devices share update downloads)
• Level 2 settings: CIS warns they can cause problems if applied without care

Check that it stays in place

Settings drift: people change them, software changes them, and new versions add new ones. A baseline is only useful if you can measure how many devices still match it. Tools that can help:

• CIS-CAT Pro Assessor: assesses how closely a system conforms to a CIS Benchmark (per CIS's website)
• Microsoft Policy Analyzer: compares sets of Group Policy Objects with each other and with local settings, and can capture a baseline to compare with a later snapshot
• Intune compliance reports: show the users, groups, and devices that follow or do not follow a baseline
• OpenSCAP: checks systems against a policy with open-source tools

Pick one measure to report, for example the share of devices in each group that match the baseline and the number of open exceptions.

Hardening reduces what an attacker can do on a device, but it does not replace detection. Pair it with EDR or an MDR service, see EDR vs XDR vs MDR: Differences and How to Choose. Patching is another job that must run regularly, see Patch Management Best Practice: Fast, Without Outages. Device health checks can also feed zero trust access decisions, see Zero Trust Architecture: Components and Roadmap.

Common mistakes

• Applying Level 2 to every device at once: CIS warns that Level 2 can cause problems
• Copying a benchmark without reviewing each setting: CIS itself recommends testing first
• Assuming a Microsoft baseline means CIS compliance: Microsoft says that, strictly speaking, it does not
• Using a preview baseline in production: Microsoft advises against it, because the settings may change
• Leaving users as administrators of their own devices: baselines are designed on the assumption that they are not
• Hardening once and never checking again: settings can change by themselves, and new versions add new ones
• Exceptions with no owner and no end date: a temporary exception becomes permanent

Start today

• Pick one device group and its OS version: for example newly bought laptops
• Download the matching benchmark and Microsoft baseline: and compare where they differ
• Audit first without changing anything: use a scanning tool to see how far today's devices are from the baseline
• Set Level 1 as the target: and list the settings you plan to skip, with reasons
• Find the users who are administrators of their own devices: list who has admin rights on their own machine
• Book a re-check date: set the day you will scan again and review exceptions

To see how configuration control fits your wider endpoint and access controls, try the self-assessment.

Scope and accuracy

The CIS information (the Benchmarks page, FAQ, and Controls list) was read on 22 October 2026. The Microsoft pages read were last updated between August 2025 and October 2026, and NIST SP 800-70 Rev. 5 was finalized in May 2026, replacing the now-withdrawn Rev. 4. Benchmark and baseline versions change often, so check the latest version that matches your systems before use.

The same CIS Benchmark idea applies to cloud settings. See What Is CSPM? Finding Cloud Misconfigurations.

CIS also publishes a Kubernetes benchmark; see how to apply it in the article on container and Kubernetes security.

References and further reading

• CIS Benchmarks: overview of the benchmarks, the products covered, and related tools
• CIS Benchmarks FAQ: definitions of Level 1, Level 2, and STIG, and the advice to test first
• CIS Controls v8.1: the list of 18 controls, including Control 4 on secure configuration
• Microsoft: Security baselines guide: what a baseline is, the principles, and where to download
• Microsoft: Security Compliance Toolkit guide: the available baselines and tools such as Policy Analyzer and LGPO
• Microsoft Intune: Security baselines for Windows devices: deploying baselines, setting conflicts, and the question of CIS compliance
• NIST SP 800-70 Rev. 5: National Checklist Program for IT Products: guidelines for checklist users and developers
• NIST National Checklist Program: the public repository of security configuration checklists
• OpenSCAP: open-source tools for checking systems against a security policy