CMMC NUGGET #8

Common Pitfalls of Securing the Architecture

Primary controls: SI.L2-3.14.1, SI.L2-3.14.4

Unpatched vulnerabilities are the most frequently exploited entry point for adversaries targeting the DIB. A robust patch management process must address:

• A defined patching policy with documented remediation timelines tied to severity. For example, critical vulnerabilities remediated within 15–30 days, high vulnerabilities within 30–60 days, etc.
• Automated patch deployment where possible, with manual verification for systems that cannot be patched automatically
• A documented exception process for systems that cannot be patched on the standard timeline, with compensating controls and POA&M entries
• Coverage of all asset types (endpoints, servers, network devices, firmware, and third-party applications)

Assessor Reality Check: Assessors will review recent vulnerability scan results. Unpatched critical vulnerabilities with no POA&M entries and no documented remediation timeline are among the most common findings in this domain.

Primary controls: AC.L2-3.1.1, AC.L2-3.1.2, AC.L2-3.1.5, IA.L2-3.5.3

Inadequate access controls remain one of the highest-frequency findings across all CMMC assessments. The most commonly failed elements:

• Least privilege not enforced: users have broader access than their job requires, often accumulated over time through role changes without corresponding access cleanup
• MFA not fully implemented: IA.L2-3.5.3 requires MFA for local and network access to privileged accounts and for network access to non-privileged accounts. Partial MFA implementation that covers some systems but not others is a finding
• Privileged accounts used for day-to-day work: administrators using their admin accounts for email and general browsing is one of the most common access control failures assessors encounter
• Access reviews not conducted or not documented: periodic reviews must be performed and the results retained as evidence

Assessor Reality Check: Assessors will request your privileged account list, your MFA configuration evidence, and records of your most recent access review. All three must be current and documented.

Primary controls: CM.L2-3.4.1, CM.L2-3.4.2, CM.L2-3.4.6, CM.L2-3.4.7

Default configurations are designed for ease of deployment not for ease of security. Common failures:

• Systems deployed with vendor default settings (default credentials, unnecessary services enabled, default ports open)
• No documented security configuration baseline against which systems are measured
• Unnecessary programs, services, ports, and protocols not disabled. CM.L2-3.4.6 and 3.4.7 require least functionality: if a service is not needed, it must be disabled
• Configuration drift resulting in systems that were properly configured at deployment but have drifted from the baseline over time with no detection mechanism or remediation

Assessor Reality Check: Assessors evaluate configuration management against your documented baseline. If no baseline exists, CM.L2-3.4.1 is an immediate finding regardless of how well your systems are actually configured.

Primary controls: SC.L2-3.13.1, SC.L2-3.13.2, SC.L2-3.13.5

A flat network where all systems can communicate with all other systems dramatically expands your assessment scope and your attack surface simultaneously. In a CMMC context, network segmentation serves two purposes: limiting the spread of a security incident and defining a defensible CUI boundary.

• CUI systems must be isolated in a defined enclave so that traffic between the CUI enclave and other network segments can be controlled and monitored
• Guest networks must be completely isolated from the CUI environment with no shared infrastructure
• Publicly accessible systems (web servers, portals) must be separated from internal CUI systems. This can typically be accomplished via a DMZ architecture
• Network segmentation must be documented in network diagrams and verifiable through firewall rules and access control configurations

Assessor Reality Check: Assessors will review your network diagrams and then verify them against actual firewall rules and network configurations. A diagram that does not match the actual network is a finding against your SSP accuracy, not just your segmentation.

Primary controls: AU.L2-3.3.1, AU.L2-3.3.2, AU.L2-3.3.5, AU.L2-3.3.9, SI.L2-3.14.6, SI.L2-3.14.7

Logging and monitoring failures are pervasive and consequential. The most common gaps:

• Log coverage gaps: not all CUI systems generate audit logs, or logs do not capture the required event types
• No defined log retention period: AU.L2-3.3.1 requires retaining logs sufficient for after-the-fact investigation. All organizations should define and document their own retention time. For example, a minimum of 90 days online with one year archived is a commonly accepted baseline.
• Logs collected but not reviewed: tool collection without human review does not satisfy the monitoring requirement. Evidence of regular review is required
• No correlation capability: AU.L2-3.3.5 requires correlating audit records to support investigation. A SIEM or equivalent capability is the standard implementation
• Audit log management access not restricted: AU.L2-3.3.9 requires limiting who can manage audit logging functions. Unrestricted access to log management is a finding

Assessor Reality Check: Assessors will ask to see your log coverage, your retention configuration, and evidence of regular review. A SIEM with six months of unchecked alerts is not evidence of monitoring, it is only evidence of log collection.

Primary controls: SI.L2-3.14.2, SI.L2-3.14.4, SI.L2-3.14.5, IA.L2-3.5.3

Every endpoint within your CUI environment is a potential entry point. Endpoint protection failures include:

• Antivirus or endpoint detection and response (EDR) not deployed on all in-scope endpoints resulting in coverage gaps which are findings
• Malicious code protection signatures not kept current. SI.L2-3.14.4 requires updating protection mechanisms when new releases are available
• Real-time scanning not enabled for files from external sources (SI.L2-3.14.5)
• MFA not enforced at the endpoint level for privileged access (IA.L2-3.5.3)

Practical Tip: Endpoint protection and MFA are assessed together in practice. An endpoint with current EDR but no MFA enforcement for privileged accounts has a gap that assessors will specifically probe.

Primary controls: SC.L2-3.13.1, SC.L2-3.13.7, AC.L2-3.1.12, AC.L2-3.1.14

Firewall misconfigurations are among the most technically consequential findings in CMMC assessments:

• Overly permissive outbound rules that allow unrestricted outbound traffic. This configuration creates data exfiltration risk and is difficult to defend during assessment
• Split tunneling enabled on VPN connections. SC.L2-3.13.7 specifically requires preventing split tunneling on remote access connections
• Remote access not routed through managed access control points. AC.L2-3.1.14 requires all remote access to traverse controlled entry points, not direct connections
• Firewall rule sets that have accumulated over years with no review or cleanup resulting in undocumented rules that don’t align with current policy are findings

Primary controls: IR.L2-3.6.1, IR.L2-3.6.2, IR.L2-3.6.3

Covered in depth in Nugget #5’s documentation section, but worth reiterating architecturally: incident response is not just a documentation control. It requires operational capability and assessors look for:

• A documented and current incident response plan (IRP), not a template pulled from the internet and never customized
• Evidence of tabletop exercises with participant lists and after-action reports
• Explicit DC3/DIBNet reporting procedures with the 72-hour timeline stated previously
• Technical capability to execute the IRP. This includes log preservation, system isolation procedures, and forensic image retention for 90 days

Primary controls: PE.L1-3.10.1, PE.L1-3.10.3, PE.L1-3.10.4, PE.L1-3.10.5, PE.L2-3.10.2

Physical security is consistently underestimated as a CMMC requirement. Key architectural elements:

• Physical access to CUI systems must be controlled and logged. This includes keycard systems, access logs, and visitor escort logs and procedures
• Server rooms, network closets, and areas housing CUI systems require documented access controls and audit logs
• Environmental controls (fire suppression, backup power, temperature management) are required under PE.L2-3.10.2 for the facility housing CUI systems
• Organizations in shared commercial facilities should document existing building controls in their SSP rather than assuming they are out of scope

Note: PE.L1-3.10.1, 3.10.3, 3.10.4, and 3.10.5 are Level 1 controls meaning they apply to all organizations handling FCI, not just CUI. PE.L2-3.10.2 is the additional Level 2 requirement. Both levels must be addressed.

Primary controls: SC.L2-3.13.8, SC.L2-3.13.10, SC.L2-3.13.11, SC.L2-3.13.16, MP.L2-3.8.6

Encryption failures in CMMC assessments almost always trace back to one of two root causes:

Root cause 1: Not encrypting at all

• CUI stored on endpoints, servers, or removable media without encryption
• CUI transmitted over networks without TLS 1.2 or higher
• Backup CUI not encrypted at rest

Root cause 2: Encrypting but not with FIPS-validated modules. SC.L2-3.13.11 requires “FIPS-validated cryptography” not just strong encryption algorithms. An organization can run AES-256 and still fail this control if the cryptographic module implementing AES is not validated under FIPS 140-2 or 140-3. Verify your encryption implementations against the NIST Cryptographic Module Validation Program (CMVP) list at csrc.nist.gov/projects/cryptographic-module-validation-program before your assessment.

Additional note: TLS 1.2 minimum is required — SSL and TLS 1.0/1.1 have been deprecated and continued use is an assessment finding.

Primary controls: CA.L2-3.12.1, CA.L2-3.12.3, RA.L2-3.11.1, RA.L2-3.11.2

Regular assessment and vulnerability scanning are not optional activities, they have specific required controls:

• RA.L2-3.11.1 requires periodic organizational risk assessments in a documented, formal manner and retained as evidence
• RA.L2-3.11.2 requires periodic vulnerability scanning with authenticated scans producing documented results
• CA.L2-3.12.1 requires periodic assessment of security control effectiveness
• Findings from all three must feed into your POA&M.

Note that an internal or external assessment that produces findings with no subsequent POA&M entries is itself an assessment finding.

Authenticated vs. unauthenticated scanning: Authenticated vulnerability scans where the scanner logs into systems with credentials provide for deeper inspection. Unauthenticated scans may miss significant vulnerabilities in the security posture. Best practice is to use both to identify and remediate vulnerabilities.

Primary controls: SR.L2-3.17.1, SR.L2-3.17.2 from NIST 800-171 Rev 3 / Not currently assessed under CMMC 2.0

As noted in Nugget #1, supply chain risk management controls are part of NIST SP 800-171 Rev 3 and are not currently assessed under CMMC 2.0, which is based on Rev 2. However, given the DoD’s stated direction and the real-world threat environment, organizations should begin building supply chain risk assessment practices now. Watch for DoD guidance on Rev 3 transition timelines.

For current CMMC 2.0 purposes, vendor security is addressed through the scoping and ESP/MSP controls covered in Nuggets #1 and #13.

These eleven pitfalls are not independent failures, they interact. An unpatched system with weak access controls, no network segmentation, and insufficient logging creates compounding risk where a single-entry point can lead to unrestricted lateral movement across your entire CUI environment with no detection capability.

Prioritize remediation of architecture shortcomings in this order:

1. Patch management and vulnerability remediation
2. MFA and access controls
3. Network segmentation and boundary protection
4. Logging and monitoring
5. Encryption validation against FIPS requirements
6. Configuration baseline documentation and enforcement

The controls referenced in this nugget span nine families: SI, AC, IA, CM, SC, AU, PE, CA, and RA. Each must be documented under its respective family section in your SSP. Network diagrams, system configurations, and vulnerability scan results are the primary evidence artifacts assessors request in this domain.

For assistance evaluating your architectural security posture, conducting a gap analysis, or preparing technical evidence packages for assessment, contact DTC’s C3PAO team.