CMMC Level 2 Practice 3.1.12: Monitor and control remote access sessions

Remote access is where most CUI environments drift from “documented security” into “whatever works today.” CMMC Level 2 Practice 3.1.12: monitor and control remote access sessions requirement forces discipline: you must know which remote paths exist, limit them to approved mechanisms, and produce evidence that remote sessions are being monitored and controlled in day-to-day operations. ¹

For a CCO or GRC lead, the fastest path is to treat this as an access pathway control, not a generic logging project. Define what “remote access” means for your environment (employee remote work, admin access, third-party support, cloud consoles), then standardize on a small number of approved methods that can enforce MFA, session timeouts, and centralized logging. From there, you build a repeatable review cadence and an evidence bundle that an assessor can follow without interpretation. ²

This page gives requirement-level implementation guidance you can hand to IT and security teams: scope decisions, step-by-step tasks, evidence to retain, common audit friction points, and a practical execution plan. It’s written to help you pass a CMMC Level 2 assessment and to reduce operational risk from remote compromise paths. ³

Regulatory text

Requirement excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.12 (Monitor and control remote access sessions).” ¹

What the operator must do:
You must (1) know where remote access is possible, (2) restrict remote access to authorized users and approved mechanisms, (3) monitor remote sessions with logs you actually review, and (4) control sessions through technical settings (timeouts, termination, and privileged session governance) so remote access cannot quietly become an unmonitored backdoor into CUI systems. ¹

Scope note: This practice is assessed as part of CMMC Level 2, which is aligned to NIST SP 800-171 Rev. 2 requirements for protecting CUI in nonfederal systems. ³

Plain-English interpretation

“Monitor and control remote access sessions” means you can answer, with evidence:

• Which approved remote access methods exist (and which are blocked).
• Who used remote access, when, from where, and to what system.
• What security controls governed the session (MFA, device posture checks, timeouts).
• How you detect and respond to suspicious remote activity (alerts, review, termination). ¹

If you cannot reliably enumerate remote access paths, you cannot credibly claim you control them.

Who it applies to

Entities: Defense contractors and other federal contractors that handle CUI and need CMMC Level 2. ³

Operational contexts commonly in scope:

• Employee remote work into the CUI enclave (VPN/ZTNA, VDI).
• Remote administration (RDP/SSH, hypervisor consoles, network device management).
• Cloud administrative consoles and API access for in-scope tenant resources.
• Third-party support access (MSP, incident response, specialized equipment support).
• Remote access from mobile devices to in-scope email, file shares, or apps if those systems store/process CUI. ¹

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

1) Define “remote access” and the in-scope boundary

1. Document your CUI environment boundary and list systems inside it.
2. Define remote access for your environment in one paragraph: “Any access to in-scope systems from outside the boundary or from non-corporate networks, including administrative access.”
3. Identify all remote entry points: VPN, ZTNA, VDI, bastions/jump hosts, cloud console access, remote management tools, and any vendor backdoor services. ¹

Deliverable: Remote Access Path Inventory (systems, method, owner, auth method, logging destination).

2) Standardize on approved remote access methods and block the rest

1. Pick approved methods for each use case (user access vs admin access vs third-party access).
2. Enforce network controls so direct inbound RDP/SSH from the internet is blocked.
3. Require remote admin access to go through a controlled path (bastion host, PAM proxy, or management plane with strong controls).
4. For third parties, use separate accounts, least privilege, and time-bounded access. ¹

Operator tip: If you allow “temporary exceptions,” they become permanent. Put exceptions behind an expiry date and an owner.

3) Enforce session controls (control)

Minimum control set most assessors expect to see:

• MFA for remote access.
• Idle timeout and session lifetime controls.
• Reauthentication for sensitive actions (especially admin functions) where supported.
• Ability to terminate sessions quickly (SOC runbook plus tooling).
• Restrictions on privileged remote actions (PAM, just-in-time access, approval workflow) where feasible. ¹

Deliverable: Remote Access Standard (configuration baseline) mapped to each remote access technology you permit.

4) Centralize monitoring for remote sessions (monitor)

1. Send remote access logs to a centralized logging platform (SIEM or managed logging).
2. Ensure logs capture: user identity, source IP/device, target system/app, auth events, session start/stop, privilege elevation, and admin commands where supported.
3. Enable alerting for high-risk patterns: impossible travel, repeated MFA failures, new geo, access outside expected windows, first-time admin access, and access to sensitive CUI repositories. ¹

Deliverable: Logging & Alert Coverage Matrix (remote access source → log types → destination → alert rules).

5) Establish an operating cadence (so you can prove it runs)

You need sustained operation, not a one-time setup. A practical cadence:

• Event-driven: investigate alerts tied to remote access.
• Routine: periodic review of remote access sessions, privileged remote sessions, and third-party access sessions; document findings and closures.
• Change-driven: re-validate controls when you add a remote tool, onboard a third party, or change identity providers. ²

Deliverable: Control card/runbook that names the owner, triggers, steps, exceptions, and evidence bundle. This is where Daydream fits naturally: teams use Daydream to maintain control cards, schedule recurring checks, and attach evidence so the control stays audit-ready between assessments. ³

Required evidence and artifacts to retain

Keep evidence that proves both design (controls exist) and operation (controls run).

Minimum evidence bundle (practical)

• Remote Access Policy/Standard: approved methods, prohibited methods, MFA requirement, session timeout requirements, third-party rules. ¹
• Remote Access Path Inventory: list of entry points with owners and status (approved/blocked).
• Configuration evidence: screenshots/exports showing MFA, timeouts, conditional access, and firewall rules blocking direct access.
• Logging proof: sample logs for VPN/ZTNA, VDI, bastion, and cloud console access showing session start/stop and user identity.
• Monitoring proof: alert rules, alert tickets, and investigation notes for remote-access-related events.
• Access reviews: periodic review records for remote access users/groups and third-party accounts, including removals.
• Exception register: documented exceptions with compensating controls and expiry. ¹

Common exam/audit questions and hangups

Assessors tend to probe for “unknown remote paths” and “logging without review.”

What an assessor asks	What they are really testing	What to show
“How do you know all remote access paths?”	Asset/path completeness	Inventory, firewall baselines, remote tool allowlist, scan results, architectural diagram
“Can you terminate a suspicious remote session?”	Active control, not passive logs	Runbook, demo termination in VPN/ZTNA/PAM, incident tickets
“How do you monitor remote admin activity?”	Higher bar for privilege	Bastion/PAM logs, privileged session recordings if available, admin access approval trail
“How do third parties access systems?”	Account separation and oversight	Third-party access procedure, time-bounded access, logs tied to named accounts

Frequent implementation mistakes and how to avoid them

1. Relying on policy language without technical enforcement. Fix: block disallowed protocols at the network edge and require controlled gateways. ¹
2. Logging exists, but nobody reviews it. Fix: assign an owner, define review outputs (findings, closures), and store review records.
3. Remote admin access is treated the same as user remote access. Fix: require bastion/PAM, stronger monitoring, and tighter time limits for privileged sessions.
4. Third-party accounts are shared or permanent. Fix: named accounts, least privilege, approvals, and disablement when work ends.
5. Cloud console access is ignored. Fix: treat cloud admin consoles as remote access; log and control them through identity provider conditional access and audit logs. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. ²

Operationally, weak remote session control increases the likelihood that credential theft becomes full CUI exposure. From a program perspective, CMMC Level 2 is tied to DoD contracting eligibility; gaps here can become a finding that blocks certification until corrected. ³

Practical execution plan (30/60/90-day)

Use phased execution rather than dates you cannot hit. Keep the plan tied to deliverables and evidence.

First 30 days (stabilize and scope)

• Appoint a control owner and publish a one-page control card (objective, scope, cadence, evidence).
• Build the remote access path inventory and mark each path as approved, needs remediation, or prohibited.
• Turn on centralized logging for your primary remote access mechanism and validate log fields meet investigation needs. ¹

Days 31–60 (standardize and enforce)

• Reduce remote access methods to a small approved set; block direct inbound admin protocols from untrusted networks.
• Implement session controls (MFA, timeouts) consistently across approved tools.
• Write third-party remote access procedures: account provisioning, approvals, monitoring, and disablement. ¹

Days 61–90 (prove operations)

• Implement routine reviews (remote access users, privileged sessions, third-party sessions) and store outputs as evidence.
• Add remote-access-focused detections and document incident handling steps for remote session anomalies.
• Run a control health check: sample sessions, confirm alerts fire, confirm termination works, confirm evidence is complete. Track remediation to closure in a system your assessor can follow; Daydream can hold the control card, evidence bundle, and remediation tracking in one place. ²

Frequently Asked Questions

Does “remote access” include employees on laptops connecting from home to cloud apps?

If the cloud app or tenant is in your CUI scope, treat that access as remote access and apply monitoring and session controls through your identity provider and audit logs. Scope decisions must match your CUI boundary documentation. ¹

Are VPN logs alone enough to satisfy monitoring?

VPN logs are a start, but assessors often expect correlation to user identity, target systems, and privileged actions when applicable. Add bastion/PAM and cloud audit logs where remote access includes admin activity. ¹

How do we handle third-party support that insists on their own remote tool?

Treat it as a prohibited path unless you can bring it under your monitoring and control requirements (named accounts, MFA, logs to your system, time bounds, and termination capability). Document exceptions with compensating controls and expiry. ¹

What’s the cleanest way to prove we can terminate remote sessions?

Keep a short runbook and a demonstration record: who can terminate, from which console, and what an analyst does during an incident. Retain an example ticket where termination was executed or tested under change control. ¹

Do we need session recording for privileged remote access?

The requirement is to monitor and control sessions; session recording is one way to strengthen monitoring for privileged access but is not the only approach. If you do not record, compensate with tighter access, stronger logging, and more frequent review of privileged sessions. ¹

How should we document this control for CMMC evidence packages?

Maintain a control card that states scope, approved methods, control settings, review cadence, and the exact evidence bundle location. Daydream is commonly used to keep that package current and to show sustained operation through recurring check records. ³

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170