The System and Communications Protection Domain: the technical boundary that carries CUI safely

What the System and Communications Protection Domain Is For

The System and Communications Protection domain establishes the technical boundary that protects CUI as it moves through systems and across networks. Its sixteen requirements cover network segmentation, boundary protection, cryptographic mechanisms for data in transit and at rest, session integrity, and specific technology categories such as collaborative computing devices, mobile code, and Voice over IP. The domain is one of the largest in the framework, and it is where most of the technical implementation work in a CMMC readiness program concentrates.

The practitioner reading of SC is that it is the technical substrate that every other domain depends on. Access control decisions only matter if the boundary SC defines is actually enforced. Authentication only matters if the channel SC protects is actually confidential. Audit records only matter if the systems SC segments are actually reachable for recording. When SC is strong, the rest of the framework has a defensible foundation. When SC is weak, the other domains implement policies against an environment where the technical controls they assume are not reliably in place.

For defense contractors preparing for CMMC Level 2 assessment, the SC domain is where FIPS validation questions become operationally consequential. Multiple controls require FIPS-validated cryptography, and the distinction between cryptographic correctness and FIPS validation is a frequent source of findings. A correctly implemented algorithm running in a non-validated module does not satisfy the control, and assessors specifically verify the validation status of the cryptographic mechanisms in use.

The Structure of the 16 Controls

The sixteen SC requirements organize into four clusters that reflect distinct technical concerns within the domain.

The first cluster covers boundary protection. These four controls (3.13.1, 3.13.5, 3.13.6, and 3.13.7) define how the network perimeter is established, how publicly accessible components are separated from internal networks, how default-deny policies govern traffic, and how split tunneling is prevented. The cluster is the network-level foundation that the rest of the domain depends on.

The second cluster covers architectural principles. These three controls (3.13.2, 3.13.3, and 3.13.4) address security engineering principles that shape how systems are designed, how user functionality is separated from system management, and how shared resources are prevented from causing unintended information transfer. The cluster is where security-by-design becomes assessable.

The third cluster covers cryptographic protection. These four controls (3.13.8, 3.13.10, 3.13.11, and 3.13.16) govern how cryptography protects CUI in transit and at rest, how cryptographic keys are managed, and how FIPS validation applies to the cryptographic mechanisms used. The cluster is where most of the FIPS-related implementation work concentrates.

The fourth cluster covers session integrity and specialized technology. These five controls (3.13.9, 3.13.12, 3.13.13, 3.13.14, and 3.13.15) address how sessions are terminated, how collaborative computing devices are controlled, how mobile code is managed, how VoIP is governed, and how communications session authenticity is protected. The cluster covers specific technology categories that each carry their own operational concerns.

The first cluster defines the network-level boundary that separates the CMMC environment from everything outside it. These four controls are the foundation of the domain.

SC.L2-3.13.1Boundary Protection

Communications must be monitored, controlled, and protected at external boundaries and key internal boundaries of the system. The control establishes that the environment has a defined boundary, that traffic crossing the boundary is monitored and controlled, and that internal boundaries segment the environment into zones with different trust levels. The implementation typically combines firewalls, intrusion detection systems, and network segmentation at both the perimeter and between internal zones. The assessable evidence includes network diagrams, firewall rule sets, and monitoring output that demonstrates the boundary is actively enforced rather than merely configured.

SC.L2-3.13.5Public-Access System Separation

Subnetworks for publicly accessible system components must be implemented and physically or logically separated from internal networks. The control addresses the specific scenario of systems that must be reachable from the internet, such as web servers, email gateways, and public-facing applications. These systems must sit in a segregated network zone (typically a DMZ) that isolates them from the internal network where CUI is handled. Findings in this area often involve network architectures where the separation exists in policy but not in enforcement, such as DMZ systems that can initiate connections into the internal network through poorly constrained firewall rules.

SC.L2-3.13.6Network Communication by Exception

Network communications traffic must be denied by default and allowed by exception. The control establishes the default-deny principle at the network level. Every traffic flow that is permitted must be explicitly authorized, and any flow that is not explicitly authorized is blocked. The implementation is typically satisfied through firewall configuration, but the assessable question is whether the deny-default actually operates in practice. A firewall with a final deny rule at the bottom of a long list of allow rules may satisfy the letter of the control while the accumulated allow rules make the practical effect permissive. Periodic firewall rule review is part of the operational discipline that makes 3.13.6 evidence-supportable.

SC.L2-3.13.7Split Tunneling

Remote devices must be prevented from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks. The control addresses the split tunneling scenario where a remote device connects to the organization through a VPN while simultaneously maintaining direct connectivity to the internet or other external networks. The combination creates a potential bridge between the two environments that bypasses the organizational boundary. The implementation typically requires VPN configuration that forces all traffic through the organization, with split tunneling explicitly disabled. Findings often involve VPN deployments where split tunneling was enabled for performance reasons without recognition of the compliance implication.

The second cluster addresses security engineering principles that shape how systems are designed rather than how they are operated. These three controls are the architectural foundations that make the rest of SC possible.

SC.L2-3.13.2Security Engineering

Architectural designs, software development techniques, and systems engineering principles that promote effective information security must be employed. The control is broad by design, addressing the general obligation to apply security engineering principles throughout the systems environment. The assessable evidence typically includes documented architectural standards, secure development practices where in-house development occurs, and engineering review processes that verify security considerations are addressed during design. For contractors that do not develop software internally, the control still applies to how commercial systems are selected, integrated, and configured in ways that support effective security.

SC.L2-3.13.3Role Separation

User functionality must be separated from system management functionality. The control requires that the interfaces, privileges, and mechanisms used for system administration are distinct from those used for routine user activity. A user performing ordinary work should not have access to administrative functions, and an administrator performing administrative work should do so through interfaces that are separate from the routine user interfaces. This control interacts directly with Access Control 3.1.6 on non-privileged account use, where the same separation principle applies at the account level.

SC.L2-3.13.4Shared Resource Control

Unauthorized and unintended information transfer via shared system resources must be prevented. The control addresses the class of vulnerabilities where shared resources such as memory, storage, or network buffers can leak information between users, processes, or sessions. Object reuse requirements, memory clearing before reallocation, and shared storage sanitization all fall within this control. The assessable evidence includes system configuration that enforces these protections and operational procedures that verify enforcement in practice. Modern operating systems provide many of these protections by default, but cloud environments and virtualized systems introduce new shared resource considerations that the control continues to address.

The third cluster addresses cryptographic protection of CUI in transit and at rest, the management of cryptographic keys, and the FIPS validation that multiple controls in the framework require. These four controls concentrate most of the cryptographic implementation work in SC.

SC.L2-3.13.8Data in Transit

Cryptographic mechanisms must be implemented to prevent unauthorized disclosure of CUI during transmission, unless otherwise protected by alternative physical safeguards. The control requires that CUI moving across networks is encrypted. The exception for physical safeguards is narrow and applies mainly to closed systems with physical security that prevents interception. For most environments, the control is satisfied by TLS, IPsec, or equivalent encryption protecting every network transmission of CUI. The cryptographic implementation must meet the FIPS validation requirement under 3.13.11.

SC.L2-3.13.10Key Management

Cryptographic keys for cryptography employed in organizational systems must be established and managed. The control requires a formal key management program that addresses key generation, distribution, storage, rotation, and destruction. Key management is frequently underbuilt because operating systems and applications handle many cryptographic operations transparently, leaving organizations without a documented understanding of how their keys are managed. The assessable evidence includes a key management policy, documentation of key lifecycle events, and protection of key material from unauthorized access. Hardware security modules (HSMs) or equivalent key protection mechanisms are common implementation patterns for environments handling sensitive keys.

SC.L2-3.13.11CUI Encryption

FIPS-validated cryptography must be employed when used to protect the confidentiality of CUI. The control establishes FIPS validation as the standard for cryptographic mechanisms that protect CUI. The distinction between FIPS compliance and FIPS validation matters. A cryptographic implementation may use correct algorithms and still not be FIPS-validated if the specific implementation has not passed the validation testing required under FIPS 140. Assessors verify the validation status of the cryptographic modules in use, typically by reference to the NIST Cryptographic Module Validation Program list. Findings in this area often involve older implementations that were validated at one point but have since expired, or commercial products that claim FIPS compliance without holding current FIPS validation certificates.

SC.L2-3.13.16Data at Rest

The confidentiality of CUI at rest must be protected. The control requires that CUI stored in systems is encrypted or otherwise protected against unauthorized disclosure. Implementation patterns include full-disk encryption on workstations and laptops, encrypted database storage, encrypted file system volumes, and encrypted backup storage. The cryptographic mechanisms protecting data at rest must meet the FIPS validation requirement under 3.13.11, and the key management must meet the requirements under 3.13.10. The control interacts with Media Protection because the distinction between CUI at rest on a system and CUI on media carrying that system's data is sometimes blurred during equipment lifecycle events.

The fourth cluster covers session termination, specific technology categories that carry their own operational concerns, and the authenticity of communications sessions. These five controls address the more specialized aspects of the domain.

SC.L2-3.13.9Connections Termination

Network connections associated with communications sessions must be terminated at the end of the sessions or after a defined period of inactivity. The control addresses the risk of stale sessions that remain open indefinitely, creating pathways that can be exploited by attackers who gain access to the endpoint. Implementation typically involves timeout configurations on network services, idle session detection, and explicit termination at logout. The defined inactivity period is an organizational decision that must be documented and applied consistently across the environment.

SC.L2-3.13.12Collaborative Device Control

Remote activation of collaborative computing devices must be prohibited, and indication of devices in use must be provided to users present at the device. Collaborative computing devices include cameras, microphones, and conferencing systems. The control addresses two concerns. The first is that such devices should not be remotely activated without the knowledge of the people near them, which addresses a specific surveillance risk. The second is that when the devices are in use, the local users must know they are active, which addresses accidental disclosure. Findings often involve conferencing systems configured for remote activation without indicators, or webcams on laptops that can be activated without the camera light signaling activity.

SC.L2-3.13.13Mobile Code

The use of mobile code must be controlled and monitored. Mobile code includes JavaScript, ActiveX, Flash (deprecated), macros, and any executable content that moves from one system to another and runs on the receiving system. The control requires that the organization has policy on which mobile code is permitted, technical enforcement of that policy, and monitoring of mobile code activity. Modern environments typically address this through browser configuration, endpoint security products, email gateway filtering, and macro security settings in productivity applications. The assessable evidence includes the policy itself and demonstration that the technical enforcement matches the policy.

SC.L2-3.13.14Voice over IP

The use of Voice over Internet Protocol technologies must be controlled and monitored. VoIP introduces a distinct class of network traffic with its own security considerations, including call signaling, media streams, and the administrative interfaces of the VoIP infrastructure. The control requires documented policy on VoIP use, technical controls that protect VoIP traffic and infrastructure, and monitoring of VoIP activity. Findings often involve VoIP deployments that were implemented years before CMMC requirements, where the security configuration has not been reviewed against current standards, or where VoIP traffic shares network paths with CUI without adequate segregation.

SC.L2-3.13.15Communications Authenticity

The authenticity of communications sessions must be protected. The control requires mechanisms that verify the identity of communicating parties and protect against session hijacking, man-in-the-middle attacks, and similar threats. Implementation typically involves TLS with proper certificate validation, IPsec with authentication headers, or equivalent protocols that provide session authenticity along with confidentiality. The control interacts with Identification and Authentication 3.5.4 on replay-resistant authentication, which addresses a related aspect of session integrity from the authentication perspective.

Where System and Communications Protection Intersects with Other Domains

SC is the technical foundation that multiple other domains depend on, and its cryptographic and boundary capabilities are inherited by controls across the framework.

Access Control depends on SC for the technical boundaries that AC decisions operate against. AC 3.1.13 on remote access confidentiality inherits SC cryptographic capabilities, and AC segmentation decisions are implemented through SC boundary controls.

Identification and Authentication relies on SC for the cryptographic mechanisms that protect credentials during transmission and at rest. IA 3.5.10 on cryptographically-protected passwords inherits SC cryptographic requirements, and IA 3.5.4 on replay-resistant authentication works together with SC 3.13.15 on communications authenticity.

Media Protection depends on SC cryptographic capabilities for MP 3.8.6 on portable storage encryption. The FIPS validation requirement in SC 3.13.11 applies to the cryptographic mechanisms MP inherits for transport protection.

Audit and Accountability depends on SC for the boundary that separates audit infrastructure from the systems it records. AU 3.3.8 on audit protection assumes that audit storage is protected by SC-level segmentation from the systems whose activity it captures.

Configuration Management defines the specific security configuration settings that SC enforces under 3.4.2. The configuration settings for firewalls, cryptographic parameters, and network boundary devices are CM artifacts that SC implements operationally.

System and Information Integrity relies on SC boundaries for the monitoring coverage that SI controls require. The segmentation SC defines determines where SI monitoring must be positioned to observe relevant activity.

Common Implementation Pitfalls

Several patterns come up repeatedly in System and Communications Protection readiness work.

FIPS compliance claimed without FIPS validation. Commercial products advertise FIPS compliance, and contractors assume the claim satisfies 3.13.11. The control requires FIPS validation, which is a specific certification that products either hold or do not hold. A product that uses correct algorithms without completing the FIPS 140 validation process does not satisfy the control, and assessors verify validation status through the NIST Cryptographic Module Validation Program list rather than through vendor marketing claims.

Firewall rule accumulation that makes deny-by-default nominal rather than effective. The firewall has a final deny rule, but the preceding allow rules have accumulated over time to the point where the practical behavior is permissive. The 3.13.6 control is satisfied only when the deny-by-default operates in practice, and periodic rule review is needed to prevent the accumulation from undermining the control.

Split tunneling enabled on VPN deployments. The VPN was configured with split tunneling for bandwidth or performance reasons, and the configuration bypasses the 3.13.7 requirement. The remediation usually requires VPN reconfiguration and may involve infrastructure changes to accommodate the full-tunnel traffic load.

Key management left to software defaults. The organization uses encryption extensively but has no documented key management program because the underlying software handles keys transparently. The 3.13.10 requirement calls for explicit key management, and the assessable evidence cannot be produced from a program that exists only as vendor defaults. Building an explicit key management policy and lifecycle documentation is typically required.

Data at rest encryption applied selectively. Workstations and laptops have full-disk encryption, but servers, removable drives, and backup storage do not. The 3.13.16 obligation covers all CUI at rest, and selective encryption produces gaps that assessors will identify. The remediation is systematic application of encryption to every location where CUI rests, with documentation of the coverage.

VoIP deployments not addressed at all. The organization uses VoIP throughout the environment, but the compliance program has not considered it as a distinct domain concern. The 3.13.14 requirement applies specifically to VoIP, and a program that treats VoIP as ordinary network traffic does not produce the evidence the control requires.

Collaborative devices without activity indicators. Conference room cameras, webcams, and microphones are deployed without attention to the 3.13.12 requirement for indication of use. Users cannot tell when the devices are active, and the remote-activation prevention has not been verified. The remediation is both technical (enabling indicators, disabling remote activation) and procedural (policy on how devices may be used).

Mobile code restrictions configured but not enforced consistently. Browser configuration blocks ActiveX and limits JavaScript, but email clients still permit macros, and the policy does not extend to all mobile code vectors. The 3.13.13 requirement applies to mobile code broadly, and partial enforcement produces the gaps that make the overall control inadequate.

Where to Start

For an organization new to the SC domain, the first work is the network architecture documentation.

The foundational deliverable is a network diagram that accurately represents the CMMC environment, its boundaries, its internal zones, and its external connections. The diagram is the reference point for every control in the domain. Without it, boundary controls cannot be evaluated because the boundary itself is not clearly defined, cryptographic controls cannot be verified because the traffic flows are not identified, and architectural controls cannot be assessed because the architecture is not documented.

The second deliverable is the cryptographic inventory. What cryptographic mechanisms protect CUI in transit and at rest, which modules are FIPS validated, when the validation certificates expire, and how keys are managed. The inventory supports the 3.13.8, 3.13.10, 3.13.11, and 3.13.16 controls together and establishes the baseline for ongoing cryptographic governance.

The third deliverable is the specialized technology inventory. Collaborative computing devices, VoIP infrastructure, and mobile code vectors all require documented attention that the general network documentation does not provide. The inventory ensures that 3.13.12, 3.13.13, and 3.13.14 are addressed systematically rather than implicitly.

With the network documentation, cryptographic inventory, and specialized technology inventory in place, the remaining SC controls become implementation work against a documented foundation. The assessment evidence follows from the operational reality that the three foundational deliverables establish.