How to Enforce Security Baselines Across Your Managed Devices

What a security baseline is in practice

A security baseline is a set of configuration values you have decided every device in a given class must hold: password and lockout policy, audit policy, which services run, whether BitLocker or FileVault is on, which legacy protocols are disabled, how Defender or XProtect behaves. In practice it covers three separate jobs: defining the values, pushing them to devices, and proving they're still there next month.

Almost nobody writes a baseline from scratch. The common starting points are the CIS Benchmarks, DISA STIGs, the Microsoft security baselines shipped in the Security Compliance Toolkit, and, for Macs, the macOS Security Compliance Project (mSCP). NIST SP 800-219r1 describes mSCP as a joint effort of NIST, NASA, DISA, and Los Alamos National Laboratory, and the project generates configuration profiles, scripts, and audit checklists from a single rule set.

CIS splits each benchmark into Level 1 and Level 2 profiles. Level 1 is meant to be safe on most systems with limited operational impact. Level 2 is defense in depth and will break things. Start every device class at Level 1 and adopt Level 2 controls one at a time, after testing.

How baseline enforcement actually works (and where it splits)

How a baseline gets enforced depends on the platform and management channel, and most fleets run more than one channel at once.

The 16-hour security reprocessing cycle in Group Policy is useful. It means a local admin who flips an audit setting gets overwritten without anyone touching the GPO. MDM-delivered settings don't behave the same way across every CSP, and Linux has no native equivalent at all. If you enforce Linux hardening with a one-time script at build, you have a build standard, not an enforced baseline.

The GPO and MDM conflict

Hybrid-joined Windows fleets cause the most baseline confusion. When a GPO and an MDM policy set the same value, Group Policy wins by default. The ControlPolicyConflict/MDMWinsOverGP setting, available since Windows 10 1803, flips that, but only for settings delivered through the Policy CSP. It does not cover the Update Policy CSP, and some security settings (firewall rules and certain Defender settings come up often in practice) aren't governed by it the way admins expect. Local GPOs left over from imaging can also override settings quietly.

The practical rule is to pick one authoritative channel per setting. If you're moving to an MDM or UEM solution, remove the conflicting GPO settings rather than relying on precedence rules to sort it out. Then confirm the effective state on the device itself, with gpresult /h, Get-MpPreference, or the MDM diagnostic report, not just in the console's deployment status.

Four checks to ensure your baselines don't fail after rollout

• Verify actual device state

  A success status means the device received the policy, not that the setting still holds. Scan devices regularly, as recommended in NIST SP 800-128.

• Document every exception

  Some devices will always need a rule relaxed, such as a finance PC running an old macro-based add-in. Give each one an owner, a reason, and a review date. CIS Controls v8.1 Safeguard 4.1 expects approved deviations to be documented in your configuration standard.

• Track coverage

  Devices you can’t reach aren’t protected (offline laptops, Macs with management profile removed etc.) and fall outside enforcement. Report coverage (devices checking in ÷ devices you own) next to your compliance score.

• Pin benchmark versions

  Benchmarks change with every OS release. CIS and Microsoft update their baselines as new Windows and macOS versions ship, adding and retiring settings. Lock each device group to a specific version and review before upgrading.

Compliance: what a baseline does and doesn't prove

A clean baseline report is evidence and doesn't make you readily compliant. Regulatory and contractual frameworks ask for a process: a documented standard, a way to apply it, a way to detect deviation, and a record of approved exceptions. A high pass rate against a CIS Benchmark shows that one part of the process is working on the devices you scanned at the time you scanned them.

How specific frameworks treat baselines differs:

• PCI DSS v4.0.1 Requirement 2.2.1

  Requires configuration standards for all system components that address known vulnerabilities and are consistent with industry-accepted hardening standards or vendor recommendations. It doesn't require CIS specifically. Assessors also expect to see the standard applied, not just written down (check the wording in the PCI SSC document library).

• CIS Controls v8.1 Control 4

  Is a framework, not a regulation. Following it is a defensible practice, but it doesn't satisfy a regulator by itself.

• The HIPAA Security Rule

  Is risk-based and doesn't name any configuration benchmark. A hardening baseline can support your risk analysis and your safeguards, but “we pass CIS Level 1” doesn't answer a HIPAA risk assessment question. See the HIPAA Security Rule.

• NIST SP 800-53

  Via the CM family, including CM-2 Baseline Configuration and CM-6 Configuration Settings, expects documented baselines and monitoring. SP 800-128 is the companion guidance for doing that well.

When describing your posture to leadership or auditors, keep the claims precise. A statement in the form “X% of in-scope Windows endpoints pass our CIS Level 1-derived baseline, with N documented exceptions and Y% agent coverage” holds up in an audit. “We're CIS compliant” or “our endpoints are HIPAA compliant” doesn't. No tool or benchmark makes an organization compliant. Compliance is a judgment someone else makes about your whole program.

A practical sequence for enforcing your baseline

1. 1. Inventory first

   Build device classes (standard laptop, developer workstation, kiosk, server role) from your asset inventory. A baseline without a scope is unenforceable.

2. 2. Choose and pin a source benchmark per class

   Such as CIS Windows 11 Enterprise Level 1 or mSCP's CIS Level 1 baseline for macOS, and record the version.

3. 3. Tailor before you deploy

   Mark the settings you'll deviate from, with a reason and an owner. This becomes your configuration standard.

4. 4. Assess in audit-only mode first

   Run the assessment against a pilot group and fix what would break before you enforce anything.

5. 5. Enforce in rings

   IT devices, then a cross-department pilot, then broad deployment. Watch help desk ticket volume after each ring.

6. 6. Assign one channel per setting

   Remove GPO/MDM overlap and stop relying on precedence.

7. 7. Assess continuously and remediate automatically

   Where the setting allows it. Alert on drift for settings you can't safely auto-correct.

8. 8. Review exceptions quarterly

   Review the baseline when the benchmark version or OS version changes.

Steps 4 through 7 are where tooling matters most. A unified endpoint management platform like Endpoint Central can push the configuration and audit the result from the same console, so the deployment record and the compliance evidence come from one source instead of being stitched together from GPO reports, MDM exports, and Linux scripts. Its CIS compliance auditing scores endpoints per benchmark rule across Windows, macOS, and Linux and gives the remediation for each failed recommendation, which is the per-rule evidence auditors ask for under PCI DSS 2.2.

Wrapping up and where to start

Enforcing a baseline is less about the initial rollout and more about what happens afterward: drift, exceptions, unmanaged devices, and benchmark revisions. Treat the baseline as a living configuration standard with an owner, measure actual device state rather than deployment status, and report coverage alongside compliance.

If you haven't already, pick your largest device class, run the matching CIS Level 1 benchmark in audit-only mode this week, and compare the result with what your console currently reports. That difference tells you where to begin.