System and Communications Protection 3.13.15 (3.13.15)
Protect the authenticity of communications sessions.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to verify that communication sessions are genuine and haven't been tampered with or hijacked. It protects against attackers who might try to intercept, modify, or impersonate legitimate communications between systems or users. The focus is on ensuring both parties in a communication can trust they're talking to who they think they are, and that the information exchanged hasn't been altered in transit.
Control Intent
To ensure the integrity and authenticity of active communication sessions, preventing unauthorized interception, modification, or impersonation that could compromise CUI confidentiality or integrity.
Who This Control Applies To
- •All systems that process, store, or transmit CUI
- •Web applications and services that handle CUI
- •Remote access solutions (VPN, remote desktop, etc.)
- •Email systems transmitting CUI
- •File transfer systems handling CUI
- •API endpoints exchanging CUI
- •Database connections involving CUI
- •Inter-system communications within the CDE
- •Cloud service connections handling CUI
- •Mobile applications accessing CUI
Not Applicable When
- •Systems that only process public information with no CUI
- •Standalone systems with no network connectivity
- •Air-gapped systems with no communication sessions
- •Systems that have been formally decommissioned
- •Systems explicitly scoped out of the CUI environment
Key Objectives
- 1Verify the identity of parties engaged in communication sessions to prevent impersonation and man-in-the-middle attacks.
- 2Protect communication sessions from unauthorized modification or insertion of false information during transmission.
- 3Establish mutual trust between communicating parties regarding ongoing session validity and participant identities.
Sample Self-Assessment Questions (Partial)
Do your systems use encrypted protocols (HTTPS, TLS, SSH) for all communications involving CUI?
Are digital certificates used to verify the identity of systems and services?
Implementation Approaches (High-Level)
TLS/SSL with Certificate Validation
Enforce TLS 1.2 or higher for all communications involving CUI, with strict certificate validation and rejection of invalid certificates.
Mutual TLS (mTLS) Authentication
Implement mutual TLS authentication where both client and server present and validate certificates, ensuring bidirectional authenticity.
Session Management Controls
Implement robust session management including secure token generation, session timeouts, re-authentication, and protection against session hijacking.
VPN with Strong Authentication
Use VPN solutions with certificate-based or multi-factor authentication to establish authenticated and encrypted communication tunnels.
API Authentication and Authorization
Implement strong API authentication using OAuth 2.0, API keys with rotation, or certificate-based authentication with request signing.
Email Security with TLS and Authentication
Enforce TLS encryption for email transmission with DMARC, SPF, and DKIM to verify sender authenticity and prevent spoofing.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
Prioritize systems with the highest CUI exposure or external accessibility Phase implementation starting with internet-facing systems and remote access Allow time for certificate procurement, deployment, and testing Consider interim compensating controls such as network segmentation or additional monitoring Document legacy systems that cannot support modern protocols and plan for replacement or isolation Include certificate lifecycle management and rotation procedures in remediation plans Address both technical implementation and operational procedures for maintaining authenticity Plan for user training on recognizing certificate warnings and authentication prompts Include monitoring and detection capabilities in the remediation timeline Coordinate with vendors for SaaS or third-party systems that require configuration changes
Frequently Asked Questions
What is the difference between encryption and authenticity protection?
Encryption protects confidentiality by making data unreadable to unauthorized parties. Authenticity protection verifies that you're communicating with the intended party and that messages haven't been tampered with. This control requires both - TLS provides encryption and authenticity through certificate validation. You can have encryption without authenticity (vulnerable to man-in-the-middle attacks), which doesn't satisfy this control.
Do we need mutual TLS (mTLS) for all communications, or is server-side TLS sufficient?
Server-side TLS with certificate validation is sufficient for most user-to-system communications (web browsers, email clients). Mutual TLS is recommended for system-to-system communications, APIs, and service integrations where both parties need to verify each other's identity. The control requires authenticity verification appropriate to the communication type and risk.
Can we use self-signed certificates to meet this control?
Self-signed certificates can meet the control only if there's a documented process for validating and trusting them (such as manual verification and installation in trust stores). Simply accepting all self-signed certificates without validation does not meet the control. Using certificates from trusted certificate authorities is the preferred and more easily assessed approach.
What happens if a vendor system doesn't support TLS 1.2 or certificate validation?
Systems that cannot support modern authentication protocols represent a gap that must be addressed through a POA&M. Compensating controls such as network segmentation, additional monitoring, or VPN encapsulation may provide interim protection, but the long-term plan should include system upgrade, replacement, or removal from the CUI environment. Document the limitation and remediation timeline.
How do session timeouts relate to authenticity protection?
Session timeouts are part of authenticity protection because they limit the window for session hijacking attacks. If a session token is stolen, timeouts reduce how long an attacker can use it. This control requires both initial authentication verification and ongoing session validity checks, including timeouts and re-authentication for sensitive operations.
Do internal communications between systems in our data center need the same protections as internet-facing systems?
Yes, this control applies to all communications involving CUI regardless of network location. Internal networks can be compromised, and lateral movement is a common attack pattern. All systems processing CUI must verify communication authenticity whether they're internet-facing, internal, or isolated. The implementation may differ (mTLS for internal APIs vs. standard TLS for web applications), but authenticity verification is required.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.