Security Configuration Enforcement

Official Source Material

Establish and enforce security configuration settings for information technology products employed in organizational systems.

Determine if:

[a] security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and
[b] security configuration settings for information technology products employed in the system are enforced.

Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024

Practitioner Guidance

How to meet it

Start from a published benchmark and remove what you do not need. Do not write settings from scratch.

The CIS Benchmarks and the DoD STIGs are published lists of recommended security settings, so you do not have to invent a hardening standard. Define your settings as the benchmark minus approved exceptions, document each exception with its reason, and objective [a] becomes a short document instead of a long one.

The tool that enforces the settings is not the document that establishes them.

Intune compliance policies, the settings catalog, and Group Policy Objects are enforcement under [b]. Objective [a] still needs a written statement of what the settings are supposed to be. A setting that exists only inside the tool cannot be compared against anything. Keep the written baseline and audit the tenant against it.

Every open port and every deviation gets a recorded reason.

A config line does not say why it exists or whether it is security relevant. Keep a firewall rules list with the business justification for each rule and the ticket or approval that created it. Record the rationale for each benchmark deviation. When someone asks in two years why a port is open, that comment is the only answer that exists.

Prove enforcement on samples, not with promises.

Objective [b] is tested against running systems. The Windows Resultant Set of Policy report from sampled machines shows the settings actually applied. Intune compliance reports do the same, and so does a SCAP scan, an automated check of a machine against your chosen benchmark. Pick whichever your stack produces. The requirement does not name a tool, and compliance scanning is not itself required.

Do not write baselines for software that cannot be configured.

Applications bundled with the operating system inherit its settings, and a suite needs one baseline, not one per app. Spend the effort on products with security settings worth controlling: operating systems, browsers, firewalls, and anything that touches CUI, the controlled unclassified information your contract requires you to protect.

What falls short

A backup of the running configuration offered as the established settings. Backing up what exists does not establish what should exist, so [a] is unmet.
Firewall rules with no recorded justification. The settings exist, but nothing shows they were established deliberately, which leaves [a] without evidence, and deviations from the intended state are invisible.

Edge cases

A benchmark setting that breaks a business function is handled by documenting the deviation with its rationale and approval. A documented exception to your own baseline is a deviation record, not a failure of the requirement.
Switches, cameras, and badge systems that never touch CUI still get a slim baseline covering the settings that help meet requirements and keep CUI off them. Workstation-grade baselines there are wasted effort.
Servers sharing an operating system but holding different roles take one core OS baseline plus a short appendix per role.