How to Actually Implement CMMC Level 2 System & Communications Protection: A Practitioner's Guide

Control what enters and leaves your network. Publicly accessible systems must be separated from internal networks.

Practice 3.13.1 requires monitoring, controlling, and protecting communications at external boundaries and key internal boundaries of organizational systems. Practice 3.13.5 requires implementing subnetworks for publicly accessible system components that are physically or logically separated from internal networks (DMZ architecture).

Implementation for 3.13.1:

• Deploy a firewall or next-generation firewall (NGFW) at all external network boundaries. The firewall must actively filter traffic, not merely log it
• Implement network segmentation between systems that handle CUI and systems that do not. If a guest wireless network, manufacturing floor network, or general corporate network exists on the same flat network as CUI systems, that is a finding
• Use network access control or VLAN segmentation to enforce boundary controls at key internal boundaries. Switches configured with VLANs and inter-VLAN routing controlled by firewall rules satisfy internal boundary monitoring requirements
• Document your network architecture with a diagram showing all external boundaries, internal boundaries, and the controls at each. The network diagram is a standard assessment artifact

Implementation for 3.13.5 (DMZ):

• If you operate any publicly accessible systems (web servers, email gateways, VPN concentrators), those systems must be in a DMZ that is logically or physically separated from the internal network where CUI systems reside
• In Azure, use separate virtual networks or subnets with Network Security Groups (NSGs) to implement DMZ architecture. Azure Application Gateway or Azure Firewall can serve as the DMZ boundary control
• If no publicly accessible systems exist, document that fact. The practice applies specifically to publicly accessible components; if there are none, the requirement does not impose additional architecture changes

Common mistake: A VPN server or remote access gateway sitting directly on the internal network with no DMZ separation. If that gateway is compromised, the attacker has direct internal network access. Place remote access infrastructure in a DMZ with firewall rules that permit only the required protocols from the DMZ to the internal network.

Build security into system design rather than bolting it on afterward.

This practice requires employing architectural designs, software development techniques, and systems engineering principles that promote effective information security. It is a design-intent practice: security should be a consideration from the start of any system build, not an afterthought.

Implementation:

• Apply least privilege to system design: components should have only the access they need to function. A web application should not connect to a database with a DBA account; a service account should not be a domain admin
• Implement defense in depth: layer controls so that compromise of a single layer does not result in full compromise. Firewall plus endpoint protection plus access controls plus logging is defense in depth. Firewall alone is not
• For new systems, conduct a brief security review as part of the design process. Document that security requirements were considered before deployment. This does not require a formal threat model for every system, but a documented checklist review is reasonable evidence
• Reference NIST SP 800-160 (Systems Security Engineering) as a framework for your engineering approach if you want a more formal reference to cite

Common mistake: Treating 3.13.2 as aspirational rather than evidenced. Assessors will ask how security is incorporated into system design. Having a documented process, even a brief one, is the differentiator between a passing and failing finding here.

Admin interfaces and user interfaces should be separate. Don't browse the internet from a domain controller.

This practice requires separating user functionality (email, web browsing, business applications) from system management functionality (administrative consoles, management interfaces, privileged access). Mixing these functions on the same system or account exposes management functions to the same threat surface as general user activity.

Implementation:

• Administrators should use dedicated privileged accounts for administrative tasks, separate from their standard user accounts. The standard account is used for email and general productivity; the admin account is used only for administrative tasks
• Management interfaces (server consoles, network device management portals, hypervisor management) should only be accessible from a dedicated management network or jump server, not from general workstations
• Restrict internet browsing on systems used for administrative functions. A domain controller or server with management access should not have a general-purpose browser and should have outbound internet access restricted
• Use Privileged Access Workstations (PAWs) or a jump server for administrative access to sensitive systems. Even a single dedicated administrative workstation that is separately managed and has restricted software is better than admins managing systems from their general-use laptops

Common mistake: IT administrators using their single account for both email and domain administration. If that account is compromised via a phishing email, the attacker has immediate administrative access. Separate accounts break the attack chain at the lateral movement step.

Shared system resources must not enable information leakage between users or processes.

This practice requires preventing unauthorized and unintended information transfer via shared system resources, such as memory, disk, or network interfaces. It addresses the risk that residual data in shared resources could be accessed by unauthorized users or processes.

Implementation:

• Configure operating systems to clear temporary storage and memory allocation before reassigning resources between users or processes. Windows handles this via memory sanitization at the OS level when properly configured
• On shared systems (terminal servers, virtual desktop infrastructure), ensure user profile isolation prevents one user from accessing another user's session data or temporary files
• For shared storage (NAS, file servers), verify that permissions prevent cross-user access to CUI. Users should not be able to browse to another user's CUI files through misconfigured share permissions
• In virtualized environments, verify that hypervisor memory isolation is functioning and that VMs cannot read memory allocated to other VMs (this is generally handled by the hypervisor vendor's security controls)

Common mistake: Shared network drives where CUI and general documents intermingle with broad read/write access. This fails both 3.13.4 and AC practices. CUI repositories should have access restricted to personnel with a need to access that specific CUI.

Default deny on the firewall. Every allow rule needs a reason.

This practice requires denying network communications traffic by default and allowing traffic only by explicit exception. It is the fundamental firewall philosophy that separates a security-conscious network from an open one.

Implementation:

• Verify that the default rule at the bottom of your firewall policy is an explicit deny-all. Some firewalls have an implicit deny; others require an explicit rule. Either is acceptable, but document which applies to your firewall
• Review every allow rule in the firewall policy. Each rule should have a documented business justification, the date it was created, and the name of the person who approved it. Rules with no business owner are candidates for removal
• Specifically look for any-to-any rules, any-to-internal rules, or broad destination subnets. These represent accumulated permissiveness that accumulates over time as IT staff add exceptions for convenience. Each should be reviewed and tightened or justified
• Implement an annual firewall rule review process. Rules that cannot be justified during the review should be removed. Document the review and its findings
• For Azure environments, NSG rules default to deny all inbound traffic from the internet and allow all outbound traffic within the virtual network. Review NSG rules to verify that outbound traffic is also appropriately controlled for CUI systems

Common mistake: Years of accumulated firewall rules with no documentation and no review. In a CMMC assessment, the firewall administrator will be asked to explain every inbound allow rule. "We've always had that rule" is not a passing answer.

Remote users must route all traffic through the organizational network, not just internal traffic.

Split tunneling allows a remote device to send corporate traffic through the VPN while routing internet traffic directly to the internet, bypassing organizational security controls. This creates a risk that a device simultaneously connected to the internet and to the internal network becomes a pivot point for attackers.

Implementation:

• Configure VPN profiles to use full tunnel mode, routing all client traffic through the VPN and subject to organizational security controls. Verify this in the VPN client configuration and test by checking the IP address of internet traffic while connected to the VPN
• For Always On VPN (Windows) or Microsoft Entra Application Proxy, verify that the traffic routing configuration does not permit split tunneling
• Document the VPN configuration and include a statement that split tunneling is disabled. This is frequently reviewed in assessments
• For cloud-only environments using Entra ID Conditional Access without traditional VPN, document how you ensure that remote access to CUI goes through security controls (e.g., Conditional Access policies that enforce compliant device requirements and session controls)

Common mistake: Enabling split tunneling for performance reasons (to avoid routing Teams or video call traffic through the corporate network) without understanding the security implications. If split tunneling is operationally required, document the compensating controls and understand that it may be a Plan of Action & Milestones item.

CUI traveling over any network must be encrypted. No plaintext transmission of CUI.

This practice requires implementing cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. In practical terms: any path by which CUI traverses a network must be encrypted.

Implementation:

• Enforce TLS 1.2 at minimum on all web applications and services that handle CUI. TLS 1.3 is preferred. Disable TLS 1.0, TLS 1.1, SSL 2.0, and SSL 3.0 on all servers and clients in scope. Use tools like SSL Labs (ssllabs.com/ssltest) to verify external-facing services
• Configure email encryption for CUI transmitted via email. Microsoft 365 Message Encryption (OME) can enforce encryption for messages containing CUI based on sensitivity labels or manual application
• Remote access to internal systems must use encrypted protocols. RDP traffic must go through a VPN or Remote Desktop Gateway with TLS; direct RDP exposure to the internet fails both this practice and CM practices
• File transfers containing CUI must use encrypted protocols: SFTP, FTPS, or HTTPS, not FTP or unencrypted SMB across untrusted networks
• Wireless networks that carry CUI must use WPA2 Enterprise or WPA3 with EAP-TLS or equivalent; WPA2-Personal (PSK) is a weaker control that may be acceptable for small environments with compensating controls but is not preferred

Common mistake: Allowing legacy TLS 1.0 or 1.1 to remain enabled for backward compatibility. PCI DSS and NIST both require disabling these versions. A scan during assessment will identify them as a finding. Run a cipher scan against all in-scope services and remediate before assessment.

Idle connections to CUI systems should time out and be terminated.

This practice requires terminating network connections after a defined period of inactivity. Persistent inactive sessions represent an attack surface: an unattended workstation with an open session to a CUI system could be exploited by anyone with physical access or by malware running on the device.

Implementation:

• Configure VPN session timeouts. VPN connections that have been idle for a defined period (commonly 15 to 30 minutes) should be terminated, requiring re-authentication
• Configure Remote Desktop session timeouts via Group Policy (Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Session Time Limits). Set limits for both idle sessions and disconnected sessions
• Configure application session timeouts for web applications handling CUI. A session that has been idle for more than a defined period should require re-authentication
• Screen lock and workstation session lock (via Group Policy) enforce a form of session protection for interactive sessions but are technically addressed under other practices. The SC 3.13.9 requirement is specifically about network-level session termination
• Document the timeout values in your SC policy. Assessors will ask what the timeout is and where it is configured

Common mistake: Configuring screen lock (which addresses physical access) but not configuring VPN or application session timeouts (which address network session persistence). These are different controls with different scopes.

Manage your cryptographic keys. Use FIPS-validated cryptography for CUI protection.

Practice 3.13.10 requires establishing and managing cryptographic keys for required cryptography. Practice 3.13.11 requires using FIPS-validated cryptography when protecting CUI confidentiality. These two practices work together: you need the right cryptographic algorithms (FIPS), and you need to manage the keys used by those algorithms properly.

FIPS implementation (3.13.11):

• Enable FIPS mode on Windows systems via Group Policy (Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"). This forces Windows to use only FIPS-validated modules for cryptographic operations
• Verify that BitLocker uses AES-256 in FIPS mode for CUI at rest (practice 3.13.16)
• For Azure services, enable FIPS 140-2 compliance mode where applicable. Azure Key Vault HSM operations use FIPS 140-2 Level 2 or Level 3 validated hardware
• Avoid MD5, SHA-1, DES, 3DES, and RC4. These are not FIPS-approved for new cryptographic protections. TLS 1.2 and 1.3 with AES-GCM cipher suites are FIPS-compliant

Key management (3.13.10):

• Document all cryptographic keys in use: what they protect, where they are stored, who has access, how they are generated, and how they are rotated or revoked
• Use a key management system for encryption keys protecting CUI. Azure Key Vault is a FIPS-validated key management service. BitLocker keys stored in Active Directory or Azure AD/Entra ID satisfy the managed storage requirement for endpoint encryption keys
• Define a key rotation schedule. TLS certificates should be renewed before expiration (certificate expiry causing service outages is common). Data encryption keys should have a defined lifetime
• Define procedures for key compromise response: what happens if a private key is exposed or an encryption certificate is compromised

Common mistake: Using self-signed certificates with SHA-1 or 1024-bit RSA keys on internal systems. While external-facing services often get proper certificates, internal services are neglected. Internal services that handle CUI also require properly managed, FIPS-compliant cryptography.

Cameras and microphones on CUI systems should not be remotely activatable without user knowledge.

This practice requires prohibiting the remote activation of collaborative computing devices (cameras, microphones, conference room A/V systems) and providing indication to users when these devices are in use. The concern is covert surveillance via compromised or maliciously configured collaboration tools.

Implementation:

• Configure endpoint management policies (Intune or Group Policy) to restrict which applications can access camera and microphone resources. Users should be able to see which applications have these permissions and revoke them
• Windows 10/11 privacy settings can restrict app access to camera and microphone; enforce these settings via Intune device configuration profiles
• Ensure that collaboration software (Teams, Zoom, Webex) does not permit remote activation without user acceptance. Standard enterprise configurations of these platforms require explicit user action to join a call
• For conference room systems with persistent A/V hardware in spaces where CUI discussions occur, verify that the system cannot be activated remotely without physical indication (e.g., a visible LED or status light)
• Document your approach in the SC policy. Assessors primarily want to see that the organization has considered this control and has a defined implementation approach

Common mistake: Overlooking conference room collaboration systems. Personal laptop cameras are usually addressed by endpoint management, but fixed conference room A/V systems with always-on microphones in rooms where CUI is discussed are often overlooked in scope.

Define what mobile code is allowed. Control VoIP systems that handle CUI discussions.

Practice 3.13.13 requires controlling and monitoring the use of mobile code (JavaScript, Java applets, ActiveX, Flash). Practice 3.13.14 requires controlling and monitoring VoIP technologies.

Mobile code (3.13.13):

• Establish a policy defining which mobile code technologies are authorized (e.g., JavaScript from approved sites is permitted; ActiveX and Java applets are prohibited)
• Use web filtering or browser management policies to enforce mobile code restrictions. Enterprise browsers managed via Intune or Group Policy can control script execution and extension installation
• The primary modern implementation is browser hardening: restrict unsigned scripts, control browser extensions, and use web proxies or DNS filtering to block malicious code delivery

VoIP (3.13.14):

• If VoIP is used for discussions involving CUI, the VoIP infrastructure must be controlled and monitored. This includes ensuring VoIP traffic is on a managed VLAN, not the general network
• If Teams or another UCaaS platform is used, verify that the platform is configured to your organizational standards (e.g., external users cannot join meetings without explicit admission)
• Document which VoIP systems are in use and how they are controlled. For most contractors using Microsoft Teams, the Intune/Entra ID management of the client combined with tenant-level meeting policies satisfies this practice

Common mistake: Having no documented policy for mobile code or VoIP. The practices don't require exotic technical controls; they require that you have defined what is authorized and are monitoring for deviations.

Protect against session hijacking and man-in-the-middle attacks.

This practice requires protecting the authenticity of communications sessions. Session hijacking and man-in-the-middle attacks can allow an attacker to take over an authenticated session without needing credentials. The primary technical controls are TLS with proper certificate validation and session token protections.

Implementation:

• Enforce HTTPS with valid certificates on all web applications handling CUI. Certificate pinning or HSTS (HTTP Strict Transport Security) headers prevent certificate substitution attacks
• Configure applications to use secure, HTTPOnly session cookies that cannot be accessed by JavaScript or transmitted over unencrypted connections
• Implement session timeouts (see 3.13.9) and session invalidation on logout. A session token that persists indefinitely after logout is a hijacking risk
• For API communications, use short-lived tokens (OAuth 2.0 access tokens with appropriate expiration) rather than long-lived API keys
• Verify that your VPN and remote access infrastructure uses mutual TLS or certificate-based authentication in addition to user credentials, preventing man-in-the-middle at the network layer

Common mistake: Conflating 3.13.15 with 3.13.8 (encryption in transit). Encryption protects confidentiality of data in transit; session authenticity protects against session takeover. Both are required and both are distinct controls.

CUI sitting on a disk, in a database, or in cloud storage must be encrypted.

This practice requires protecting the confidentiality of CUI at rest. Combined with 3.13.8 (CUI in transit) and 3.13.11 (FIPS cryptography), this completes the encryption picture: CUI must be protected both when moving and when sitting still.

Implementation:

• Endpoints: Enable BitLocker with AES-256 on all laptops and workstations that store CUI locally. Require PIN or startup key in addition to TPM for higher-assurance scenarios. Store recovery keys in Entra ID or Active Directory
• Servers: Enable BitLocker or full-disk encryption on physical servers storing CUI. For VMs, enable Azure Disk Encryption (for Azure-hosted VMs) using AES-256
• Cloud storage: Azure Blob Storage and Azure Files use AES-256 encryption by default with Microsoft-managed keys. For CUI, consider customer-managed keys (CMK) stored in Azure Key Vault for additional control
• Databases: Enable Transparent Data Encryption (TDE) on all SQL Server databases containing CUI. Azure SQL enables TDE by default. Verify it is not disabled
• SharePoint/OneDrive: Microsoft 365 encrypts data at rest by default. Verify that the Microsoft 365 tenant is configured to use customer-managed keys if your organization requires it, and that sensitivity labels are applied to CUI documents
• Removable media policy: USB drives that may contain CUI must also be encrypted, using BitLocker To Go or equivalent

Common mistake: Enabling BitLocker on laptops but not servers or removable media. Encryption at rest must cover all locations where CUI is stored, not just the most obvious ones.