CMMC Level 2 Practice 3.13.15: Protect the authenticity of communications sessions

CMMC Level 2 Practice 3.13.15 requires you to prevent session hijacking and spoofing by ensuring communications sessions are authentic end-to-end, especially for remote access, administrative sessions, and access to CUI systems. Operationally, you implement strong mutual authentication where appropriate, cryptographic protections (for example, TLS/SSH), secure session management, and monitoring evidence that these protections run in production. (NIST SP 800-171 Rev. 2)

Key takeaways:

• Treat “session authenticity” as a control set: authenticated endpoints, protected session establishment, and protected session continuation.
• Prioritize remote access, admin access, and any access path into CUI environments; scope and document those paths first.
• Evidence matters as much as config: keep screenshots/config exports, diagrams, and logs that show secure protocols and session controls operating. (DoD CMMC Program Guidance)

The target keyword, cmmc level 2 practice 3.13.15: protect the authenticity of communications sessions requirement, maps directly to NIST SP 800-171 Rev. 2 control 3.13.15 and sits in the System and Communications Protection family. (NIST SP 800-171 Rev. 2) The practical intent is straightforward: if an attacker can impersonate an endpoint, hijack an authenticated session, or downgrade the protocol used to create a session, they can access CUI without “breaking” your access controls.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalization is to (1) identify where “sessions” exist in your environment (VPN, RDP, SSH, web apps, APIs, SaaS admin consoles, jump boxes), (2) mandate secure session establishment (strong authentication + cryptographic protection), (3) enforce secure session continuation (timeouts, re-auth, token protections), and (4) retain assessment-ready evidence tied to the scoped CUI boundary and the actual control operation. CMMC assessments reward teams that can show secure protocol choices, configurations, and repeatable evidence capture aligned to CMMC’s assessment expectations. (32 CFR Part 170; DoD CMMC Program Guidance)

Regulatory text

Excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.15 (Protect the authenticity of communications sessions).” (NIST SP 800-171 Rev. 2)

Operator interpretation of the text: You must ensure that communications sessions cannot be silently impersonated or taken over. In practice, that means you:

• authenticate the parties establishing the session (user-to-system and, where needed, system-to-system),
• use secure protocols that protect session negotiation and traffic from tampering,
• harden session management so authenticated sessions cannot be replayed, stolen, or extended indefinitely,
• can prove the above with evidence tied to your CUI scope. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Plain-English interpretation (what “session authenticity” means)

A “communications session” is the logical conversation between two endpoints, such as:

• a user’s browser session to an internal web app,
• an SSH session to a Linux host,
• an RDP session to a Windows server,
• an API client session to a service endpoint,
• a VPN tunnel from a remote device to your network.

“Protect authenticity” means the session is established and maintained with controls that prevent:

• impersonation (fake server, fake VPN gateway, fake admin portal),
• session hijacking (stealing cookies/tokens/keys and taking over),
• man-in-the-middle (MITM) tampering (altering traffic or negotiating weaker crypto),
• replay of previously valid session material.

Who it applies to (entity + operational context)

Entities: Defense contractors and other federal contractors handling CUI that are pursuing or maintaining CMMC Level 2 alignment. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational context (where assessors look first):

• Remote access into the environment that stores/processes/transmits CUI (VPN, ZTNA, VDI). (NIST SP 800-171 Rev. 2)
• Administrative sessions (domain admin, cloud tenant admin, hypervisors, network devices).
• Internal application sessions that grant access to CUI (web apps, file portals, collaboration tools in scope).
• System-to-system sessions that move CUI (ETL jobs, managed file transfer, APIs).

Scoping reminder: You do not need to retrofit every corporate system if it is truly out of CUI scope, but you must prove the scope boundary and ensure all session paths into the CUI boundary meet the practice. (DoD CMMC Program Guidance)

What you actually need to do (step-by-step)

Use the steps below as your requirement-to-operations checklist.

1) Inventory and classify session types in scope

Create a list of “session entry points” to the CUI boundary:

• interactive user sessions (web, VDI, RDP, SSH),
• remote access sessions (VPN/ZTNA),
• admin console sessions (on-prem and cloud),
• API/service sessions (service accounts, mutual TLS, signed tokens).

Deliverable: a one-page session inventory with owners and system names that match your SSP terminology. (DoD CMMC Program Guidance)

2) Standardize approved secure protocols and disallow weak ones

Define an “Approved Session Protocol Standard” for in-scope systems:

• HTTPS with TLS for web sessions
• SSH for admin on Linux/network devices (no Telnet)
• Secure RDP configurations (do not expose directly to the internet; require authenticated access path)
• VPN/ZTNA with strong authentication

What to configure:

• enforce encrypted transport for session establishment and data-in-transit,
• disable plaintext or legacy protocols that allow session spoofing,
• prevent protocol downgrade where your technology supports it.

Evidence tip: assessors usually accept “secure-by-policy” only if it is backed by device or service configuration exports showing enforcement. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

3) Require strong authentication for session establishment

Map each session type to its authentication method:

• workforce user sessions: SSO + MFA for remote/admin and for any high-risk access path into CUI systems
• privileged sessions: MFA plus privileged access workflows where feasible (for example, jump host access gates)
• service-to-service: rotate credentials and prefer cryptographic identity (cert-based auth / mutual TLS) where supported

Your goal is to reduce the chance that stolen credentials can be used to create a “valid” session.

Control alignment note: This practice intersects with access control and identification/authentication controls; keep the narrative clean in your SSP by clarifying that 3.13.15 is about session authenticity, not just “having MFA.” (NIST SP 800-171 Rev. 2)

4) Harden session management (protect the session after login)

Session authenticity fails most often after authentication. Implement session protections such as:

• short-lived tokens for web apps where supported,
• secure cookie settings (Secure/HttpOnly/SameSite) where applicable,
• session timeout and idle timeout for administrative consoles and remote access,
• re-authentication for high-risk actions (privileged changes, exports of CUI).

Operational approach: set a baseline by platform (IdP, VPN, Windows admin, Linux admin, SaaS admin), then document exceptions with compensating controls.

5) Protect session integrity across network boundaries

Focus on “trust breaks”:

• remote user device to access gateway,
• gateway to internal apps,
• third party connections (MSPs, integrators) into your environment.

For any third party access into in-scope environments, require the same session authenticity controls (strong authentication, secure protocols, controlled session paths) and document them in third party access standards and contracts where you can. (DoD CMMC Program Guidance)

6) Monitor and alert on session abuse signals

Implement detection that supports your claim that session authenticity is protected in operation:

• log remote access authentications and session starts/stops,
• log privileged session activity where available,
• alert on impossible travel, excessive failed logins, new device/location for admin sessions, and abnormal session duration.

Your assessor does not need a full SOC, but they will expect you to show logs exist, are retained, and are reviewed as part of normal operations. (DoD CMMC Program Guidance)

7) Map to your SSP and build a recurring evidence capture routine

Document:

• control statement for 3.13.15,
• in-scope session types and systems,
• responsible teams,
• how you enforce secure sessions,
• how often you review configs/logs (set an internal cadence and follow it).

Daydream (as a GRC workflow) fits well here when you need repeatable evidence capture: ticketed config pulls, screenshots, exports, and review sign-offs tied back to 3.13.15.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Design / configuration evidence

• Network and access path diagram showing session entry points to the CUI boundary
• VPN/ZTNA configuration exports showing authentication requirements and crypto settings
• IdP/SSO configuration screenshots (MFA requirements for in-scope apps/admin)
• SSH/RDP hardening standards and device-level configuration evidence
• Web app / reverse proxy / WAF config showing TLS enforcement

Operational evidence

• Sample logs: VPN session start/stop; successful/failed logins; admin console logins
• Change tickets showing protocol hardening actions (disabling legacy protocols, enabling TLS)
• Periodic access review outputs for privileged access paths tied to CUI systems
• Exception register for systems that cannot meet the standard with compensating controls and dates for remediation plans

Assessment packaging tip: store evidence by “session type” so an assessor can trace: requirement → system → config → log proof.

Common exam/audit questions and hangups

Expect assessors to press on these points (and prepare crisp answers):

• “Show me every way a user can remotely access the CUI enclave. Which are allowed?” (DoD CMMC Program Guidance)
• “Do you have any plaintext management protocols enabled on in-scope networks?”
• “How do you prevent session hijacking for web applications that handle CUI?”
• “What prevents a third party from connecting with weak authentication?”
• “Where is the evidence that these settings are enforced in production, not just written in policy?”

Hangup pattern: teams describe MFA and encryption but cannot show session inventory, access paths, or production config evidence.

Frequent implementation mistakes (and how to avoid them)

1. Treating 3.13.15 as ‘we use HTTPS’
   Fix: document session inventory and show enforcement at the gateway/app/device level plus logs. (NIST SP 800-171 Rev. 2)

2. Ignoring admin and machine-to-machine sessions
   Fix: explicitly include SSH, RDP, hypervisor consoles, network device management, and APIs in scope mapping.

3. Allowing “temporary” exceptions that become permanent
   Fix: run an exception register with an owner, compensating controls, and a tracked remediation path.

4. No evidence of ongoing operation
   Fix: schedule periodic evidence capture (config exports and log samples) and store it in your GRC system with reviewer sign-off. Daydream can automate reminders and evidence requests so reviews happen consistently.

Risk implications (why operators care)

Session authenticity gaps commonly lead to:

• unauthorized access to CUI through hijacked sessions,
• privileged takeover through compromised admin sessions,
• undetected MITM risks on remote access paths,
• assessment findings where controls are “partially met” due to missing evidence or incomplete scoping.

From a program perspective, CMMC requires you to demonstrate implementation, not intent. Your biggest controllable risk is “we did it but didn’t keep proof.” (32 CFR Part 170; DoD CMMC Program Guidance)

Practical 30/60/90-day execution plan

First 30 days: scope + quick wins

• Build the in-scope session inventory and CUI access path diagram. (DoD CMMC Program Guidance)
• Identify and shut down plaintext protocols in the CUI boundary where feasible (Telnet, HTTP admin, unmanaged remote access).
• Confirm MFA requirements for remote and privileged access paths into CUI systems; document enforcement points.
• Stand up an evidence folder structure (by session type) and start capturing “current state” configs.

Days 31–60: standardize + harden

• Publish an approved secure session standard (protocols, authentication, session timeout expectations).
• Implement consistent admin access patterns (jump host/PAW where feasible; at minimum, controlled entry points).
• Harden web app sessions (token/cookie/session timeout settings) for in-scope apps.
• Configure centralized logging coverage for remote access and privileged sessions; validate log completeness.

Days 61–90: prove operation + close gaps

• Run an internal “mock trace”: pick two in-scope systems and walk requirement → config → logs → review record.
• Formalize exception management and compensating controls for legacy systems.
• Add recurring control operation: periodic config snapshots and log review tickets tracked in your GRC workflow (Daydream fits here).
• Update SSP narrative for 3.13.15 with exact system names, technologies, and evidence locations. (DoD CMMC Program Guidance)

Frequently Asked Questions

Does 3.13.15 require mutual TLS everywhere?

No. The requirement is to protect session authenticity, which you can meet through appropriate authentication and secure protocols for the session type. Use mutual TLS where it is the right fit (common for service-to-service), and document why it is or is not used per pathway. (NIST SP 800-171 Rev. 2)

If we have MFA on VPN, is that enough?

MFA on VPN is a strong start, but assessors will also look for secure session protocols, hardened session management, and evidence that the VPN is the controlled entry point into the CUI boundary. You still need to address admin sessions and application sessions inside the boundary. (DoD CMMC Program Guidance)

How do we handle third party remote support into CUI systems?

Treat third party access as an in-scope session path: require secure remote access, strong authentication, and controlled entry points, and keep logs of their sessions. Document the method in your access standards and, where possible, contract terms. (DoD CMMC Program Guidance)

What evidence is most persuasive in a CMMC assessment for this practice?

Production configuration exports (VPN/IdP/app gateways) plus log samples showing real session events are typically persuasive because they show both enforcement and operation. Tie each artifact to an in-scope system list and your SSP control narrative. (DoD CMMC Program Guidance)

Our application is hosted in a SaaS platform. How do we prove session authenticity?

Capture SaaS admin security settings (SSO/MFA enforcement, session timeout controls), confirm TLS access, and retain audit logs for admin and user sign-ins. If the SaaS is a third party, document shared responsibility and the controls you can configure versus what the provider operates. (DoD CMMC Program Guidance)

What’s the most common reason teams fail 3.13.15?

Incomplete scoping and missing evidence. Teams often have secure sessions in practice but cannot show all access paths into CUI systems or cannot produce configuration proof and operational logs during assessment. (DoD CMMC Program Guidance)