6.3 System & Communications Protection (SC) Domain: Boundary Defense & Cryptography

System & Communications Protection: Boundaries, Sessions & Cryptography

The SC family contains 16 Level 2 requirements. Requirements 3.13.1 and 3.13.5 also map to Level 1. The family protects boundaries, architecture, transmissions, stored CUI, communications sessions, cryptography, collaborative devices, mobile code, and VoIP.

Boundary and architecture requirements

Requirement 3.13.1 monitors, controls, and protects communications at external boundaries and key internal boundaries. The organization identifies those boundaries and shows the mechanisms and activities that enforce them. Continuous packet inspection, a particular firewall brand, or one diagram style is not stated universally.

Requirement 3.13.2 employs architectural designs, software-development techniques, and systems-engineering principles that promote effective information security. 3.13.3 separates user functionality from system-management functionality, and 3.13.4 prevents unauthorized and unintended information transfer through shared system resources. Separate management networks and bastions may help, but logical access controls or other designs can satisfy the objective when supported.

Requirement 3.13.5 implements physically or logically separated subnetworks for publicly accessible components. A DMZ is a common design. The team verifies actual separation and allowed paths, not the label on a network segment.

Traffic and split tunneling

Requirement 3.13.6 denies network communications traffic by default and allows it by exception. The team traces approved flows to firewall, router, host, cloud, or application rules and verifies that the effective configuration implements the default-deny result. A broad rule needs evidence of its authorized purpose; the requirement is not a command to search for one literal ACL string.

Requirement 3.13.7 prevents remote devices from simultaneously establishing non-remote connections with organizational systems and communicating through another connection to external networks. Full-tunnel VPN is a common implementation, but the objective is the prevented simultaneous path. The assessor evaluates the actual remote-device architecture rather than claiming that one VPN product is mandatory.

CUI confidentiality and cryptography

Requirement 3.13.8 implements cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless alternative physical safeguards protect it. Protected distribution systems or controlled physical paths may be relevant alternatives in limited circumstances. Ordinary internet transmission typically relies on cryptography.

Requirement 3.13.16 protects the confidentiality of CUI at rest. Encryption is a common mechanism, but the requirement is outcome-oriented and can interact with physical and access safeguards. If cryptography is used to protect CUI confidentiality for either requirement, 3.13.11 requires FIPS-validated cryptography.

FIPS validation attaches to the cryptographic module and its validated operational environment or configuration, not merely to AES, TLS, or another algorithm name. Evidence should identify the exact module, version, certificate, security policy, deployed configuration, and data path. The current CMVP record and transition rules matter. “FIPS capable” is not proof that the deployed function operates inside the validation boundary.

Requirement 3.13.10 establishes and manages cryptographic keys for cryptography used in organizational systems. Generation, distribution, storage, access, rotation or replacement, recovery, revocation, and destruction are evaluated as applicable. It is 3.13.10—not 3.13.9.

Connections and communications technologies

Requirement 3.13.9 terminates network connections associated with communications sessions at the end of sessions or after an organization-defined period of inactivity. This is distinct from key management and from the user-session termination requirement in Access Control.

Requirement 3.13.12 prohibits remote activation of collaborative computing devices and indicates their use to users present at the device. Authorized exceptions and technologies are evaluated against the assessment objectives.

Requirement 3.13.13 controls and monitors mobile code. The organization identifies covered technologies and allowed or prohibited use based on risk. Not every script is automatically mobile code, and CMMC does not publish one universal allowlist.

Requirement 3.13.14 controls and monitors VoIP use. Network segmentation, configuration, call controls, monitoring, or encryption may support the result depending on architecture; the requirement does not universally prescribe SRTP, a VLAN, or a vendor.

Requirement 3.13.15 protects communications-session authenticity. Relevant evidence can include protocol configuration, certificate validation, mutual authentication, or other mechanisms that prevent impersonation and session hijacking.

Evidence sequence

For an SC scenario:

1. Trace CUI, management, public, remote, and provider flows across the actual scope.
2. Map the fact to the exact numbered requirement and assessment objectives.
3. Examine architecture, rules, configuration, module validation, keys, and records.
4. Interview network, system, security, and service-provider personnel.
5. Test representative allowed, denied, remote, session, or cryptographic behavior where appropriate.
6. Confirm that inherited or shared-provider claims match the CRM and operational evidence.

A diagram showing a DMZ does not prove separation if routing bypasses it. A VPN screenshot does not prove split tunneling is prevented on the sampled endpoints. A CMVP certificate does not prove the product uses that validated module in the assessed configuration. The finding follows the complete evidence chain.