The System and Communications Protection family is where your CMMC implementation starts to look like a real security architecture rather than a collection of point controls. This family governs how Controlled Unclassified Information is protected in transit and at rest, how communication paths are constrained, how sessions are authenticated and terminated, and how network and collaboration technologies are controlled.

It is also one of the more nuanced families to implement in Microsoft GCC High. On paper, GCC High gives you meaningful platform support here. Microsoft enforces TLS 1.2 or later for Microsoft 365 connectivity, operates GCC High through distinct government endpoints, and provides underlying cryptographic and service protections that support several SC requirements. But that platform support only gets you part of the way. The remaining controls depend on how you configure Conditional Access, Intune, Teams, Exchange Online, Defender for Cloud Apps, and Azure Government services around your tenant boundary.

That is why this family tends to separate mature implementations from superficial ones. A team can buy GCC High and still have weak session controls, overly permissive collaboration settings, split tunneling, unrestricted macros, or no documented cryptographic key management process. None of those problems are solved automatically.

This is Part 13 of the NIST 800-171 GCC High Configuration Guide. It assumes you already have a functioning GCC High tenant, multifactor authentication is configured, Intune enrollment is complete, and your baseline Conditional Access policies are in place. If you have not yet worked through Access Control and Identification and Authentication, start there first. Several SC controls depend directly on decisions made in those families.

SC family overview

The System and Communications Protection family contains sixteen controls. In practice, they fall into three buckets. Some are primarily platform-provided because Microsoft handles the underlying service architecture, cryptographic modules, and protected transport behavior. Most require direct tenant configuration. One, cryptographic key management, is best understood as a shared responsibility control because Microsoft manages service-side encryption keys while your organization still owns key management for things like BitLocker recovery, certificates, and any customer-controlled encryption workflows.

This family has more platform support than many others, but that can be misleading if read too casually. Platform support does not remove the need to document how the control is satisfied, identify where Microsoft’s responsibility ends, and show how your own environment extends those protections to endpoints, collaboration tools, VPN traffic, and admin workflows.

SC controls and CMMC scope

The SC family applies to the full communication path for systems and identities inside your assessment boundary. That includes user endpoints, remote access paths, Exchange mail flow, SharePoint and OneDrive data handling, Teams collaboration, and any network or identity boundary that governs how CUI moves through the environment.

This is especially important in enclave-based architectures. An enclave can narrow the number of people and systems handling CUI, but the controls inside that enclave still have to be complete. Encryption in transit, session authenticity, session timeout, collaboration restrictions, VPN behavior, and mobile code restrictions all still matter inside the enclave boundary. In some ways, they matter more, because the enclave is supposed to be the place where CUI protections are strongest and easiest to defend.

This is also a family where hybrid reality often matters. Even if your CUI lives primarily in GCC High, remote access clients, endpoint devices, local printers, VPN concentrators, external mail connectors, or Azure-hosted enclave components can all become part of the communications protection story. If they participate in how CUI is transmitted, accessed, or segmented, they are relevant to the assessment.

What GCC High provides by default

Several SC controls are largely supported by the Microsoft platform. These are not controls you ignore. They are controls you document carefully so your C3PAO understands what the platform provides and what your organization still owns around it.

3.13.2 Employ architectural designs, development techniques, and systems engineering principles that promote effective information security

This control is about security-minded system architecture. In GCC High, Microsoft provides the cloud service architecture itself, including the government cloud environment, layered service protections, and the engineering principles that underpin the platform. GCC High’s distinct government endpoints and service architecture support the idea that the tenant is operating in a separate government environment rather than the commercial Microsoft 365 cloud.

For your assessment, though, that is only half the answer. Your SSP still needs to explain how your own environment uses sound architecture. That includes how you segment admin accounts, how you constrain endpoints, how you isolate public-facing components, and how your enclave or tenant boundary is designed to reduce exposure of CUI.

3.13.4 Prevent unauthorized and unintended information transfer via shared system resources

This control is largely supported by Microsoft’s service architecture. Tenant isolation, service isolation, and protected storage boundaries reduce the risk of unauthorized transfer through shared cloud resources. But if your implementation includes on-premises shared systems, unmanaged shared devices, or loosely controlled file transfer workflows, your own environment can still weaken the practical control.

This is one of those cases where the platform can satisfy the cloud portion of the requirement while your organization still needs to address the rest of the boundary clearly in the SSP.

3.13.8 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission

Microsoft documents that Microsoft 365 requires TLS 1.2 or later for connectivity, and GCC High uses distinct government endpoints for Microsoft 365 services. That means the baseline platform already provides a strong protected transport path for browser, client, and service communications into the tenant.

The practical challenge here is not usually Microsoft 365 itself. It is all of the adjacent paths where CUI might move outside that built-in protection model. External SMTP connectors, third-party integrations, hybrid systems, local file shares, VPN tunnels, and partner communications often determine whether the real-world implementation actually satisfies the control.

3.13.11 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI

GCC High relies on Microsoft cryptographic infrastructure, and Microsoft publishes technical references on encryption and transport protections across Microsoft 365. For the purposes of this control, the platform gives you a defensible starting point at the service level.

The piece organizations most often miss is the endpoint story. If Windows devices, VPN clients, local storage, or third-party applications use cryptography outside the Microsoft 365 service layer, those components still need to align with your FIPS position and be documented accordingly.

3.13.15 Protect the authenticity of communications sessions

At the service level, GCC High supports session authenticity through certificate-based trust, modern authentication, and token-based session handling. Microsoft 365’s use of TLS and Entra-backed identity flows gives you the platform mechanisms needed to defend session authenticity.

The common weakness here is not the Microsoft session. It is the surrounding environment. If DKIM is not enabled, if legacy authentication remains open, or if external connectors and partner routes are loosely controlled, your organization can undermine the authenticity guarantees that the platform is otherwise capable of supporting.

3.13.16 Protect the confidentiality of CUI at rest

Microsoft 365 provides service-side encryption at rest, and the platform supports encryption protections across core data services. Microsoft’s technical encryption documentation confirms at-rest protection as part of the Microsoft 365 service model.

Again, though, the control does not end at the service. Endpoints matter. If CUI is cached locally, downloaded to managed devices, or accessed through virtual desktops or local sync clients, your organization still needs a clear story around BitLocker, FileVault, sensitivity labels, and device compliance.

The SC controls you must configure yourself

This is where most of the real SC implementation work happens. The Microsoft platform gives you the secure building materials, but your team still has to build the actual boundary.

3.13.1 Monitor, control, and protect communications at external boundaries and key internal boundaries

For most GCC High environments, boundaries do not look like a traditional on-premises firewall diagram alone. They are defined through the tenant boundary, Conditional Access perimeter, managed device requirement, Exchange mail flow rules, and any enclave or hybrid segmentation architecture around the environment.

A strong implementation starts by documenting the boundary clearly in the SSP. From there, organizations usually layer in Defender for Cloud Apps, named locations in Entra Conditional Access, Exchange Online transport controls, and wherever applicable, firewall or proxy-level monitoring feeding into cloud security tooling. Microsoft documents Defender for Cloud Apps availability for GCC High in US Government environments, which makes it a practical monitoring and control layer for cloud boundary enforcement.

The common failure here is not lack of tooling. It is lack of a coherent boundary model. Teams deploy Conditional Access, Exchange rules, and Defender policies independently, but never pull them together into a defensible statement of what the external boundary is and how traffic across it is monitored and restricted.

3.13.3 Separate user functionality from information system management functionality

This control is one of the most operationally visible in the family. It requires that administrative activity be separated from day-to-day user activity.

In practice, that means dedicated admin accounts, Conditional Access restrictions that apply specifically to those accounts, ideally privileged workstations or at least hardened compliant devices for admin use, and a clear prohibition on using standard licensed user accounts for administration. This is also one of the controls assessors can validate quickly. They will look at role assignments, account design, and whether those accounts are clearly distinct in both documentation and actual use.

3.13.5 Implement subnetworks for publicly accessible components that are physically or logically separated from internal networks

This control looks different in a cloud-first GCC High environment than it does in a traditional datacenter. If your organization relies entirely on Microsoft-managed public-facing services and does not host internet-accessible applications of its own, the implementation is mainly about documenting that reality and making sure you are not accidentally exposing content through SharePoint sharing or other public collaboration paths.

If you do host public-facing applications, APIs, portals, or enclave components, then the control becomes much more traditional. You need logical or physical separation, documented segmentation, and a boundary story that distinguishes public access from internal or CUI-related networks.

3.13.6 Deny network communications traffic by default and allow by exception

This is where your tenant should stop feeling permissive.

In a Microsoft 365 context, deny-by-default is usually expressed through a combination of Conditional Access and endpoint firewall policy. A strong model blocks or constrains access unless the request comes from a compliant device, trusted context, or explicitly permitted path. At the endpoint layer, Windows and macOS firewalls should reinforce the same principle by blocking unsolicited inbound traffic and controlling unnecessary exposure on unmanaged networks.

The most common mistake here is believing that “require MFA” equals deny-by-default. It does not. MFA can still exist inside a broadly permissive access model. To satisfy this control well, your policies need to show that unmanaged or unauthorized traffic is denied unless it meets clearly defined exceptions.

3.13.7 Prevent split tunneling

This is one of the SC controls that regularly trips teams up because many VPN and remote access products prioritize performance over strict tunnel enforcement by default.

If your users can access Microsoft 365 or enclave resources while simultaneously routing other traffic directly to the internet outside your protective path, you have a real split tunneling problem. In practice, organizations usually solve this through Always On VPN, full-tunnel profiles delivered via Intune, or a SASE solution configured in a way that forces protected routing. Where Microsoft 365 traffic is intentionally bypassed for “optimization,” teams need to be very careful about whether that routing model is compatible with how CUI is actually being accessed.

Microsoft’s connectivity guidance sometimes recommends allowing certain Microsoft 365 traffic to bypass VPN tunnels to improve performance. While that guidance can be appropriate for commercial tenants, organizations handling CUI should evaluate it carefully. If Microsoft 365 services are within the CUI processing boundary, bypassing the protected tunnel may conflict with the intent of SC.L2-3.13.7, and organizations should ensure their design still routes CUI traffic through a controlled and monitored security boundary.

3.13.9 Terminate network connections associated with communications sessions at the end of sessions or after a defined period of inactivity

In GCC High, this usually comes down to Conditional Access sign-in frequency, browser persistence controls, and SharePoint or OneDrive idle timeout settings.

The reason this control is often missed is that Microsoft’s default token behavior can feel secure enough until you look at it through a CMMC lens. A session that persists far longer than your documented inactivity threshold can become a real assessment issue, especially if the SSP claims something tighter than the tenant actually enforces.

The strongest implementations align the SSP, Conditional Access sign-in frequency, idle sign-out behavior, and privileged-user session settings so they tell one consistent story.

3.13.12 Prohibit remote activation of collaborative computing devices and provide indication of devices in use

In a Microsoft 365 environment, this control maps primarily to Teams, Teams Rooms devices, conferencing hardware, and endpoint camera and microphone behavior.

At a platform level, Teams does not simply let someone else turn on another user’s camera or microphone remotely without that user’s participation. But the control still needs to be addressed because collaborative computing devices include more than just the Teams software experience. Meeting policies, Teams Rooms settings, physical device indicators, endpoint privacy settings, and external meeting configuration all matter here.

This is also one of those controls that can feel low risk until assessors ask whether it is documented anywhere. Many teams have acceptable default behavior in place but have never described it in the SSP or linked it to a formal device management process.

3.13.13 Control and monitor the use of mobile code

For most GCC High tenants, this control becomes a discussion about Office macros, PowerShell, browser-based script execution, and endpoint attack surface reduction.

A mature implementation usually includes Intune-delivered Attack Surface Reduction rules, Office macro restrictions, browser controls, and a defined exception process for legitimate script or macro use. The key point is that mobile code should not be allowed to execute simply because it can. It should be constrained, monitored, and only permitted where there is a documented business need.

This is one of the clearest areas where endpoint management and Microsoft 365 configuration come together. If Intune and Defender policies are weak, the tenant can still look fine on paper while mobile code risk remains largely uncontrolled on the device.

3.13.14 Control and monitor the use of VoIP technologies

In GCC High, this usually centers on Microsoft Teams as the approved VoIP platform, along with restrictions on external access, call forwarding, calling policy design, and monitoring of communication activity.

The risk here is not just whether Teams is secure. It is whether your organization has clearly defined what VoIP tools are approved, whether external federation is too open, whether unmanaged calling behaviors are allowed, and whether unapproved VoIP apps are still present on managed endpoints. Teams admin guidance and external meeting or chat controls continue to evolve, so it is worth validating the exact government feature behavior in the live tenant before publishing screenshots or navigation paths.

The shared responsibility control: cryptographic key management

3.13.10 Establish and manage cryptographic keys

This is the one SC control in the family that is best treated as shared responsibility.

Microsoft manages the service-side encryption keys that protect the Microsoft 365 platform. Your organization, however, still owns a meaningful set of keys and key processes. That includes BitLocker recovery keys, certificate lifecycles, any customer-controlled encryption features you implement, and your general key management policy.

This is why organizations can get tripped up here. They know Microsoft manages platform encryption, so they assume key management is “covered.” Then an assessor asks for the key management policy, BitLocker recovery key escrow evidence, or certificate renewal procedures, and the control suddenly looks much less mature.

A defensible implementation does not require every advanced optional Microsoft encryption feature. It does require a documented key inventory, clear ownership, rotation and recovery processes, and restricted access to key management systems.

Recommended implementation order

This family is easiest to implement in a sequence that respects dependencies.

Start with 3.13.3 admin account separation, because several later controls depend on having clearly distinguished privileged accounts. Move next into 3.13.6 deny-by-default and 3.13.1 boundary monitoring and protection, because those set the access and communications baseline for the environment. After that, tackle 3.13.5 segmentation, 3.13.7 split tunneling prevention, and 3.13.9 session termination, since those controls shape how users and devices interact with the tenant over time.

Once those structural controls are stable, move into 3.13.13 mobile code, 3.13.12 collaborative device controls, and 3.13.14 VoIP governance. Finish with 3.13.10 key management, which benefits from having the rest of your encryption, endpoint, and identity decisions already clarified.

The platform-provided controls should be documented in parallel as you build the SSP, even if they do not require direct tenant configuration.

Common assessment findings across the SC family

C3PAOs tend to see the same patterns repeatedly during CMMC Level 2 assessments for the SC family. The issue is rarely that organizations lack the necessary tools. In most cases, the controls exist somewhere in the environment, but they have not been implemented consistently or documented clearly enough to demonstrate how communications are actually protected.

One of the most frequent problems is the absence of a clear authorization boundary diagram in the SSP. Without a diagram that shows what systems, identities, and communications paths fall inside the CUI boundary, assessors cannot easily determine where protections apply. This gap directly affects controls like 3.13.1 (boundary monitoring) and 3.13.5 (subnetwork separation), but it often creates confusion across the entire SC family.

Split tunneling is another common finding. Many VPN solutions enable split tunneling by default to improve performance, allowing some traffic to bypass the protected tunnel and route directly to the internet. Unless the organization can demonstrate that remote devices route all relevant traffic through the protected boundary or an equivalent SASE control, assessors frequently flag this under 3.13.7.

Conditional Access design also causes issues. Organizations often deploy policies that require MFA but never implement a true deny-by-default posture. Without a catch-all block or clearly defined allow conditions, unmanaged or non-compliant devices may still be able to reach cloud resources. This leaves the environment operating in a permit-by-default model, which conflicts with 3.13.6.

Account separation problems appear across many assessments as well. Administrative roles are sometimes assigned to the same accounts people use for daily work, or admin accounts still carry standard user licenses and mailbox access. That pattern violates 3.13.3, which requires clear separation between user functionality and system management functionality.

Session management is another area where implementations frequently fall short. Default Microsoft 365 token lifetimes can persist longer than the organization’s documented inactivity thresholds. When Conditional Access sign-in frequency or idle session controls are not configured to match the SSP, the environment fails to demonstrate compliance with 3.13.9.

Mobile code restrictions are also commonly incomplete. Many organizations leave Office macros enabled with only warning prompts or deploy Attack Surface Reduction rules in audit mode indefinitely. Without enforceable restrictions and monitoring, assessors may identify gaps in 3.13.13.

Key management documentation is another recurring weakness. Even though Microsoft manages many platform encryption keys, organizations are still responsible for key management procedures related to BitLocker recovery keys, certificate lifecycles, and any customer-controlled encryption capabilities. When that documentation is missing or incomplete, the environment cannot fully satisfy 3.13.10.

Finally, collaboration and communications technologies often remain more permissive than intended. Teams external access may allow federation with all external domains, unapproved VoIP applications may still exist on managed endpoints, and collaborative device behavior may not be documented. These issues can affect 3.13.12 and 3.13.14, depending on how communication tools are actually used in the environment.

In practice, most SC findings trace back to the same root cause: the organization implemented the technical controls but never unified them into a clearly documented communications protection model.

Evidence a C3PAO will usually want to see

For the SC family, evidence should connect architecture, policy, and technical configuration.

That usually includes an authorization boundary diagram, Conditional Access exports, Intune device and firewall policies, Defender for Cloud Apps policy screenshots, Exchange transport rules, Teams external access and meeting policy settings, VPN profile configuration, session timeout settings, macro and Attack Surface Reduction rules, BitLocker or FileVault enforcement evidence, and key management documentation. For the platform-provided controls, the SSP should explain what Microsoft provides and how that maps to the shared responsibility model for your environment.

Get started

The System and Communications Protection family contains sixteen controls, nine of which require hands-on configuration across Conditional Access, Intune, Teams, Exchange Online, and your remote access architecture. During an assessment, your C3PAO will expect to see clear evidence that these controls are not only configured but operating consistently across the environment.

That means demonstrating how your organization enforces deny-by-default network access (3.13.6), monitors traffic at the tenant boundary (3.13.1), terminates inactive sessions (3.13.9), and maintains documented cryptographic key management procedures (3.13.10). It also means showing that those controls remain in place over time rather than drifting after the initial configuration.

Secureframe Defense continuously monitors your GCC High tenant for SC control compliance, automatically collects the evidence artifacts assessors expect, and alerts your team when configurations change or drift from your documented baseline. Instead of manually assembling screenshots and configuration exports for each assessment cycle, you can maintain continuous visibility into how these controls operate across your environment.

See how Secureframe Defense automates CMMC evidence collection for NIST 800-171 controls by scheduling a demo with a product expert.