3.4 CM
1,064 paragraphs across seven sections. Here is the design rationale and the decisions that distinguish this page from generic hardening documentation.
Document structure
Section 3 carries the most operational weight — it is where the 103 individual configuration settings across six platform baselines live. Engineers implementing 3.4.1 and 3.4.2 spend most of their time in Section 3, not Section 2. The design decision to include specific required values (not just CIS Benchmark references) throughout the baseline tables is deliberate and matches what assessors test: the NIST SP 800-171A examine objective for 3.4.2 requires seeing specific documented settings, not "we follow CIS Benchmark."
The six platform baselines cover Windows 11 workstations, Windows Server 2022, macOS, Ubuntu 22.04 LTS, network devices, and cloud infrastructure. Cloud infrastructure (BL-CLOUD) is the most commonly missing baseline in first-time CMMC assessments — organisations document on-premises systems thoroughly and then leave cloud resources entirely unaddressed. The cloud baseline table explicitly names the AWS Config rules and Azure Policy controls that enforce each setting, because this is the technical enforcement mechanism that satisfies 3.4.2 for cloud resources.
Section 3A — the approved software list governance section — sits between the baseline specifications and the evidence register because the approved software list is the operational reference that links all four software control controls (3.4.6 through 3.4.9). The five categories (productivity, developer tools, security tools, privileged utilities, browser extensions) and the approval SLA give the IT manager a complete operating procedure without needing to reference any other document.
The three control groupings and why they matter
The nine CM controls are split into three groups matching how engineers actually implement them. Baseline configuration (3.4.1 and 3.4.2) is a documentation and tooling problem — you need specifications and you need automated enforcement. Change management (3.4.3, 3.4.4, 3.4.5) is a process and workflow problem — you need an RFC system, a CAB, and a documented security impact assessment template. Software control (3.4.6, 3.4.7, 3.4.8, 3.4.9) is a policy and technical restriction problem — you need an approved list, a denial mechanism, and monitoring.
The most commonly missed implementation detail is that 3.4.8 requires different technical approaches for different system types. General-purpose endpoints can rely on admin rights removal plus reputation-based blocking — application allow-listing is operationally difficult when users need to install approved software regularly. High-value CUI-processing servers should use deny-all application allow-listing (AppLocker / WDAC / SELinux) because the software set is stable and the security value of allow-listing is highest precisely when systems are difficult to change frequently. The document makes this distinction explicit in the 3.4.8 implementation description.
The six common findings — what matters most operationally
Finding one — the vague baseline — is the most structurally important. An organisation that writes "follow CIS Benchmark Level 1" without documenting which specific settings they implement and which they deviate from fails 3.4.1 in the most fundamental way. The assessor cannot test against "CIS Level 1" — they can only test against specific values. The baseline tables in Section 3 are the output format assessors expect to see.
Finding two — the manual audit — matters because objectivity is tested. A configuration audit conducted by the same engineer who configured the system, using a spreadsheet they built themselves, has no independence or completeness guarantee. An automated tool scan (CIS-CAT Pro, Microsoft Defender for Endpoint configuration assessment, Tenable) generates a timestamped, tool-signed report that an assessor can evaluate without questioning the methodology.
Finding six — the missing cloud baseline — is worth specific attention for any organisation with US defence contracts. AWS, Azure, and GCP resources that store or process CUI are absolutely within NIST 800-171 scope. The CMVP database, FIPS endpoint requirements, and CloudTrail requirements apply to cloud just as much as on-premises. The BL-CLOUD table with AWS Config rules and Azure Policy enforcement references gives the cloud engineering team the same level of specification that the Windows team has in BL-WIN11.
Cross-linking in Confluence
The AT-CM page connects to more other pages than any other family in the library. Link to AT-SI (the vulnerability scanning that feeds 3.4.2's configuration flaw identification uses the same scan tool and evidence items); AT-AC (the access restrictions for change in 3.4.5 depend on the PAM platform and privileged account model from the AC family); AT-SC-BDY (the firewall and DMZ baseline for network devices documented in BL-NET is the technical implementation of the SC boundary controls); FC-02 (the all-staff secure configuration page in the Fundamental tier is the behavioural counterpart to this technical page); and the SSP (every CUI-scope system in the asset register must have an SSP system description entry — the two documents are kept in sync through the change management process defined in 3.4.3).
The asset register (EV-D22) is the single piece of evidence that underpins both AT-CM and the SSP — it is the source of truth for which systems are in scope, what platform type each is, and therefore which baseline applies. Keeping the asset register current is the upstream dependency for almost every other CM evidence item, and it is worth emphasising this to the IT manager as the operational priority within the CM family.