Skip to content
ControlVerdict
Sign in
CM.L2-3.4.2CMMC Level 2Level 2

Security Configuration Enforcement

Submit your own example

Practice statement

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

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.4.2.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(2)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    security configuration settings for information technology products employed in the system are established and included in the baseline configuration; and

    1 example covers this

  2. [b]

    security configuration settings for information technology products employed in the system are enforced.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    CM.L2-3.4.2Security Configuration Enforcement
    Establish and enforce security configuration settings for information technology products employed in organizational systems.

    • [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.

    CIS-aligned Windows baseline assigned by compliance; drift becomes a ticket

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses both Security Configuration Enforcement objectives for the Windows CUI fleet. Lab Windows IoT and macOS engineer devices use a reduced checklist under documented exceptions but are still governed by the same establish-and-enforce baseline process.

    Baseline content. Hardened password/PIN policy (complementing IdP MFA), BitLocker required, Secure Boot, disabled SMBv1, restricted PowerShell language mode for standard users, Windows Defender real-time + cloud protection on, local admin rights removed for standard users, screen lock ≤ 15 minutes, USB write blocked on CUI devices.

    Assignment. Baseline is an Intune configuration profile + compliance policy. Noncompliant devices lose CUI Conditional Access until remediated (except a documented grace period for rebuilds).

    Drift. Compliance dashboard reviewed weekly; devices noncompliant >7 days auto-open a ticket to the endpoint team. Local changes that fight the baseline (e.g., re-enabling local admin) are overwritten on next Intune sync.

    Maintenance. Baseline versioned (vYYYY.MM). Changes go through CAB with security review. After each major OS upgrade, re-diff against CIS and update the profile within 30 days.

    Accepted gap. Lab instruments on Windows IoT cannot take the full baseline. They are VLAN-isolated, no CUI at rest, and use a reduced hardening checklist signed by the enclave owner.

    What the evidence looks like

    • Intune profile export (settings list)
    • Compliance policy and Conditional Access grant dependency
    • Baseline version history / CAB ticket for last change
    • Weekly compliance snapshot with open drift tickets
    • Lab exception checklist

    Environment

    Windows 11 fleet for CUI users; macOS engineers on a separate, smaller baseline.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.