Skip to content

3.4.2 — Harden Everything

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

Every system in your CUI environment must be hardened to a documented security baseline — not the vendor’s factory defaults. This applies to workstations, servers, network devices, cloud services, and applications.

Two things the assessor checks:

  1. Security settings are established and documented. You have a hardening baseline for each system type based on a recognized standard: CIS Benchmarks, DISA STIGs, or vendor security guides. The baseline specifies settings like: password policies, account lockout thresholds, audit policy, disabled services, firewall rules, encryption requirements. Any deviations from the baseline are documented with a justification — “We can’t disable SMBv1 because legacy application X requires it” with a compensating control and a remediation timeline.

  2. Security settings are enforced. Not just documented — technically applied and continuously verified. Group Policy, Intune compliance policies, AWS Config rules, or whatever mechanism ensures systems actually comply. Drift detection flags when a system falls out of compliance.

The assessor will pick a random CUI system, ask to see your hardening baseline for that system type, and then check whether the live system matches. If the baseline says “TLS 1.0 disabled” and the server has TLS 1.0 enabled, that’s a finding — even if the document is perfect.


Your assessor needs a “yes” to every row:

#QuestionWhat “yes” looks like
1Are security configuration settings established and in the baseline?Documented hardening baseline per system type — referencing CIS/STIG/vendor guide with specific settings
2Are security configuration settings enforced?Technical enforcement (GPO/Intune/Config rules) plus compliance scanning showing systems actually match the baseline

Documents they’ll review: Configuration management policy; baseline configuration with security settings; security configuration checklists (CIS/STIG); procedures addressing configuration settings; system security plan; system configuration settings showing enforcement; documented deviations with justification; change control records for baseline updates

People they’ll talk to: Personnel with security configuration management responsibilities; information security personnel; system or network administrators

Live demos they’ll ask for: “Show me your CIS Benchmark for Windows workstations.” “Pull up this server’s configuration — does it match the baseline?” “Show me a compliance scan result.” “Show me a documented deviation with justification.”


These are the actual questions. Have answers ready.

  • “What hardening standard do you follow? CIS? STIG? Show me the baseline.”
  • “Pick a system — does its live configuration match your baseline?”
  • “How do you enforce these settings? Is it GPO, Intune, or manual?”
  • “How do you detect configuration drift?”
  • “Are there any deviations from the baseline? Show me the documentation and justification.”
  • “Do your security settings reflect the most restrictive settings appropriate for each system?”
  • “When was your baseline last updated?”

Factory defaults. Systems deployed out of the box with no hardening applied. Default admin passwords, unnecessary services enabled, no encryption. Apply baselines before systems touch the CUI environment.

No documented baseline. Systems are hardened by knowledgeable admins, but nothing is written down. The assessor asks “show me your baseline” and it’s tribal knowledge. Document it — even if it’s a spreadsheet mapping CIS Benchmark items to your settings.

Baseline exists but isn’t enforced. The document says “screen lock at 15 minutes” but half the workstations are set to 30 minutes. Without technical enforcement (GPO/Intune), baselines drift. Apply settings centrally and scan for compliance.

No deviation documentation. Some settings can’t be applied because of application compatibility. That’s okay — but undocumented deviations are findings. Every exception needs: the setting, why it can’t be applied, the compensating control, and the target remediation date.

Incomplete coverage. Workstations and servers are hardened, but network devices and cloud services aren’t. The requirement applies to all IT products in the CUI environment — including firewalls, switches, and cloud tenants.



RequirementWhy it matters here
3.4.1 — Know Your InventoryThe inventory of systems that baselines are applied to
3.4.6 — Shrink the Attack SurfaceLeast functionality is part of your hardening baseline
3.4.3 — Control Every ChangeChanges to baselines go through change management
3.13.11 — Encrypt CUI at RestEncryption settings are a key part of the hardening baseline

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

CMMC Practice ID: CM.L2-3.4.2 | SPRS Weight: 5 points | POA&M Eligible: No