CMMC 2.0 Architecture Diagrams: System Security Plan & Network Boundary (2026)

CMMC 2.0 architecture diagrams are now legally required artifacts for most US defense contractors. CMMC Phase 1 enforcement began November 10, 2025, with Phase 2 (mandatory third-party C3PAO assessments for Level 2) commencing November 2026. The cornerstone document is the System Security Plan (SSP), which explicitly requires network and system boundary diagrams that map your environment to NIST SP 800-171 controls. If your organization handles Controlled Unclassified Information (CUI) and bids on DoD contracts, these diagrams are not optional — they are assessed during your C3PAO audit. This guide covers what CMMC assessors look for in architecture documentation and how to use AI to generate compliant, assessment-ready diagrams efficiently.

CMMC 2.0 levels and what documentation each requires

• Level 1 — Foundational (17 practices): Self-assessment, annual affirmation. Architecture documentation is recommended but not assessed. Applies to organizations handling only Federal Contract Information (FCI), not CUI.
• Level 2 — Advanced (110 practices, NIST 800-171): Third-party C3PAO assessment required for prioritized acquisitions (most CUI contracts). Full System Security Plan (SSP) with boundary diagrams, network topology, data flow diagrams, and control mapping is mandatory. This is where 80%+ of defense contractors fall.
• Level 3 — Expert (110+ practices, NIST 800-172): Government-led DIBCAC assessment. Enhanced documentation including detailed threat modeling and advanced persistent threat (APT) mitigations. Applies to programs with highest CUI sensitivity.

Required diagrams in a CMMC Level 2 SSP

• System boundary diagram: The most critical CMMC artifact. Defines the exact boundary of your CUI environment — every asset inside the boundary must be accounted for in your SSP and assessed. Assets outside the boundary are out of scope. Show all hardware (endpoints, servers, network devices), cloud services, external connections, and the logical and physical boundary lines. Assessors use this diagram to determine assessment scope.
• Network topology diagram: Shows the network architecture within the boundary — VLANs, subnets, firewalls, switches, routers, wireless access points, and remote access infrastructure (VPN). Annotate every network segment and the controls between segments. Assessors check this against AC-17 (remote access), SC-7 (boundary protection), and SC-8 (transmission confidentiality) controls.
• CUI data flow diagram: Traces CUI from receipt (email, file transfer, portal download) through processing and storage to transmission and disposal. Every point where CUI exists must be shown. Assessors map this against MP-6 (media sanitization), SC-28 (protection at rest), and SC-8 (protection in transit).
• User access and authentication flow: Shows how users authenticate to CUI systems — MFA enforcement (IA-3, IA-5), privileged access management (AC-6), and how access requests and terminations are processed (AC-2).
• External connection diagram: Documents every connection crossing the boundary: government network connections (GovCloud, DISA STIG-compliant connections), vendor remote access, cloud service provider links, and contractor laptop VPN. Each connection must be associated with an interconnection security agreement (ISA) or memorandum of understanding (MOU). Maps to CA-3.
• Incident response architecture: Shows your SIEM/logging stack, alerting pipeline, and the incident response workflow. Assessors check IR-6 (incident reporting to DIBNet within 72 hours of discovery) and IR-4 (incident handling).

CUI scoping: the most common assessment failure point

The most common reason CMMC assessments fail is over-scoping or under-scoping the CUI environment. Your boundary diagram drives the scope — include too little and you have unprotected CUI; include too much and your assessment burden (and cost) balloons unnecessarily.

Best practices for scoping your boundary diagram:

• Segment CUI systems from corporate IT networks using VLANs, separate subnets, or physical separation. CUI systems in a dedicated VLAN can scope out your entire corporate network from the assessment.
• Use a CUI enclave for cloud workloads — a dedicated AWS GovCloud account, Azure Government subscription, or Google Public Sector project that handles only CUI. Non-CUI workloads stay in commercial cloud accounts outside the boundary.
• Document every external service that touches CUI (Microsoft 365 GCC High, cloud storage). If it's inside the boundary, the vendor must have their own FedRAMP High or equivalent authorization, or you must assess them as part of your SSP.
• Remote work endpoints that access CUI are inside the boundary. Show them in the diagram with their endpoint protection controls (EDR, full disk encryption, compliant OS).

Prompt examples for CMMC architecture diagrams

CMMC Level 2 system boundary diagram

CUI data flow diagram

Network topology with NIST 800-171 control annotations

CMMC vs other compliance frameworks: key differences

Annotation checklist for CMMC architecture diagrams

• Boundary lines: Use a clearly visible dashed or colored border to delineate the CUI boundary. Every element inside must be accounted for in the SSP. Assessors cite unclear boundaries as a finding.
• NIST 800-171 control references: Annotate components with the relevant 800-171 control families they support (AC, AT, AU, CA, CM, IA, IR, MA, MP, PE, PS, RA, SA, SC, SI). This aligns your diagram directly with the assessment framework.
• Asset inventory alignment: Every asset shown in the boundary diagram must have a corresponding entry in your SSP asset inventory table. Assessors cross-reference them.
• Encryption annotations: FIPS 140-2 or 140-3 validation is required for cryptographic modules protecting CUI (IA-7, SC-13). Annotate encryption algorithms and whether the implementation is FIPS-validated.
• Diagram version and approval: CMMC SSPs require configuration management of documentation (CM-9). Include version number, approval date, and the name of the approving official on every diagram.

Related guides: zero-trust architecture, SOC 2 architecture diagrams, DevSecOps architecture, and security architecture patterns.