Configuration Management 3.4.2 (3.4.2)
Establish and enforce security configuration settings for information technology products employed in organizational systems.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to define and enforce secure configuration settings for all IT products in their systems. This includes servers, workstations, network devices, operating systems, and applications. Organizations must establish baseline security configurations using recognized standards and ensure all systems are configured according to these baselines. The goal is to reduce security vulnerabilities by ensuring systems are not left in default or insecure configurations.
Control Intent
To reduce security vulnerabilities and attack surface by ensuring all information technology products are configured according to established security baselines rather than default or ad-hoc settings.
Who This Control Applies To
- •All information technology products employed in organizational systems
- •Servers, workstations, and mainframe computers
- •Network components including firewalls, routers, switches, wireless access points
- •Operating systems across all platforms
- •Middleware and applications
- •Input/output devices such as printers, scanners, and copiers
- •Mobile devices and endpoints accessing organizational systems
- •Cloud infrastructure and platform services
- •Virtualization platforms and containers
- •Database management systems
Not Applicable When
- •The organization has no information technology products or systems in scope
- •Systems are entirely managed by a third party with contractual security configuration requirements that meet or exceed organizational standards
- •Legacy systems scheduled for decommissioning within 90 days with documented compensating controls
- •Air-gapped systems with no CUI and documented risk acceptance
Key Objectives
- 1Establish organization-wide security configuration standards for all IT products in use.
- 2Enforce approved security configuration settings across all systems and components.
- 3Maintain configuration baselines that incorporate security parameters affecting system security posture.
- 4Utilize recognized secure configuration benchmarks and standards where available.
Sample Self-Assessment Questions (Partial)
What types of IT products and systems does your organization use (servers, workstations, network devices, applications)?
Do you use any recognized security configuration standards or benchmarks (CIS Benchmarks, DISA STIGs, vendor hardening guides)?
Implementation Approaches (High-Level)
CIS Benchmark-Based Configuration Management
Organization adopts CIS Benchmarks as the foundation for security configuration standards, customizes them for organizational needs, and enforces them using automated tools.
DISA STIG-Based Configuration Management
Organization implements DISA Security Technical Implementation Guides (STIGs) as security configuration baselines, particularly for systems processing DoD information.
Vendor Hardening Guide Implementation
Organization uses vendor-provided security hardening guides and best practices as the basis for security configuration standards.
Group Policy-Based Configuration Management (Windows)
Organization uses Active Directory Group Policy Objects (GPOs) to centrally define and enforce security configuration settings across Windows systems.
Configuration Management Tool Enforcement
Organization uses enterprise configuration management tools to define, deploy, and enforce security configurations across diverse system types.
Cloud Security Posture Management (CSPM)
Organization uses CSPM tools to define, monitor, and enforce security configurations for cloud infrastructure and services.
Hybrid Manual and Automated Configuration Management
Organization uses a combination of manual procedures and automated tools to establish and enforce security configurations, particularly for diverse or legacy environments.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If security configuration standards do not exist, prioritize developing baselines for systems processing CUI first, then expand to supporting infrastructure If standards exist but are not enforced, implement automated enforcement tools starting with highest-risk systems If using manual processes, create a phased plan to implement automated configuration management tools For configuration drift issues, implement continuous monitoring and automated remediation capabilities If baselines are not based on recognized standards, map existing configurations to CIS Benchmarks or STIGs and document gaps For legacy systems that cannot meet current standards, document compensating controls and plan for system replacement or upgrade If configuration management is decentralized, establish organization-wide standards first, then implement enforcement mechanisms Include specific milestones for tool selection, baseline development, implementation, and verification Ensure POA&M includes resources needed (tools, training, personnel time) and realistic timelines Consider phased implementation by system type or criticality rather than attempting organization-wide deployment simultaneously
Frequently Asked Questions
What is the difference between a security configuration setting and a configuration baseline?
A security configuration setting is an individual parameter that affects security posture (e.g., password length requirement, firewall rule, audit setting). A configuration baseline is the complete set of security configuration settings that define the approved secure state for a particular system type. The baseline serves as the reference point for deployment and ongoing compliance verification.
Do we need to use CIS Benchmarks or DISA STIGs, or can we create our own security configuration standards?
You can create your own security configuration standards, but they must be based on sound security principles and address all relevant security parameters. Using recognized standards like CIS Benchmarks or DISA STIGs is strongly recommended because they are widely accepted, regularly updated, and provide a defensible basis for your configurations. If you create custom standards, document the rationale and ensure they meet or exceed recognized benchmark recommendations.
How do we handle security configurations for SaaS applications we don't directly control?
For SaaS applications, you must still establish and enforce security configuration settings within your control, such as user access controls, authentication requirements, data sharing settings, and integration configurations. Document the security configurations you can control, obtain evidence of the provider's security configurations through attestations or third-party assessments, and include SaaS security configuration requirements in your vendor management process.
What should we do if a required security configuration breaks a critical business application?
Document the conflict, perform a risk assessment, and follow your exception process to request a deviation from the standard configuration. Implement compensating controls where possible to mitigate the risk. Document the business justification, risk acceptance, and any compensating controls. Include the exception in your POA&M if it represents a gap, with a plan to resolve the underlying issue through application updates, replacement, or alternative controls.
How often do we need to verify that security configurations remain in place?
Verification frequency should be risk-based and documented in your procedures. High-risk systems or those processing CUI should be verified more frequently (monthly or quarterly). Automated configuration monitoring tools can provide continuous verification. At minimum, annual verification is recommended for all in-scope systems. Configuration verification should also occur after any system changes, updates, or incidents.
Can we use different security configuration standards for different types of systems?
Yes, different system types typically require different configuration standards (e.g., Windows servers vs. Linux servers vs. network devices). However, you must establish organization-wide security configuration principles and ensure system-specific baselines align with these principles. Document why different standards are used and ensure all baselines address the same security objectives appropriate to each system type.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.