AC.L2-3.1.12 requires organizations seeking CMMC 2.0 Level 2 (NIST SP 800-171 Rev.2 control 3.1.12) to monitor and control remote access sessions to protect Controlled Unclassified Information (CUI); this post gives small businesses concrete architecture, tooling, logging, and evidence steps to prepare for assessment and to operationalize session monitoring and control within the Compliance Framework.
Understanding AC.L2-3.1.12 and assessment expectations
At assessment time, auditors will expect you to show that remote sessions (VPN, RDP/SSH, cloud session managers, web-admin consoles, third-party support tools) are actively monitored and that controls exist to start, limit, and stop sessions when needed. In Compliance Framework terms, this practice sits in the Access Control family: your implementation must show technical enforcement (session termination, idle timeouts, disallowed features), monitoring (centralized logs and session metadata), and documented processes (who authorizes remote access, how elevated sessions are granted and revoked). Evidence must be repeatable, auditable, and tied to identities.
Practical implementation steps
Network and access architecture (what to build)
Start by funneling all remote administrative access through a hardened jump host, bastion, or PAM (Privileged Access Management) solution. For small businesses, cost-effective options include: an SSH bastion with multi-factor auth (MFA) + logging (OpenSSH + auditd + rsyslog), AWS Systems Manager Session Manager (no open inbound ports, session recordings to S3 and CloudTrail), or Azure Bastion + Azure AD Conditional Access. Design the network so only the bastion is reachable from the internet; internal systems accept connections only from that bastion. Implement network segmentation so users cannot use remote access to move freely into CUI environments.
Session control settings and tooling (how to enforce limits)
Apply strict session controls: enforce MFA and contextual controls (source IP, geofence), enable idle and absolute session timeouts (e.g., 15 minutes idle, 8 hours absolute), disable clipboard/file transfer for remote sessions unless explicitly authorized, and require Just-In-Time (JIT) or time-limited access for privileged accounts. Use tooling that supports session termination on-demand (PAM consoles, cloud session managers, RDP gateways), and implement recorded sessions for high-risk accounts — examples: BeyondTrust/Bomgar, CyberArk, or open-source ttyrec/Script-based session recording with integrity checks. Configure SSH with ForceCommand wrappers to drop logs to a central collector and set Audit logs (auditd, journald) to capture execs and tty activity.
Logging, monitoring, and alerting (how to observe sessions)
Centralize session metadata and full-session logs into a SIEM or log-management stack (Splunk, Elastic, Wazuh, or cloud-native logging). Key fields: session ID, user identity (SAML/AD username), start/stop timestamps, source/destination IPs, commands executed (for privileged sessions), file transfer attempts, and session termination reason. Correlate logs with identity events (Active Directory/Azure AD) and firewall logs. Implement detection rules for long/overnight sessions, sessions initiated from unusual geolocations, multiple failed elevation attempts, or unexpected interactive commands in automated service contexts. Ensure log integrity — ship over TLS, sign or hash session recordings, and retain logs according to policy (commonly 90 days online, 1 year archived for CUI environments, but follow your organization’s retention baseline).
Documentation and evidence to collect for your assessment
Create a concise evidence pack: architecture diagram showing bastion/PAM, configuration snapshots (SSH daemon config, RDP gateway settings, cloud session manager settings), screenshots of conditional access policies (MFA, IP restrictions), SIEM dashboards and example alerts, export of session logs with correlated AD user attributes, approved access request forms for a privileged session, and SOPs describing how and when sessions are terminated. Include a recent tabletop or live-play test showing session termination in response to an alert and an incident log demonstrating how a suspicious session was handled. Map each evidence item to the specific Requirement (AC.L2-3.1.12) in your compliance spreadsheet.
Real-world small business scenarios and examples
Example 1: A 30-person defense subcontractor uses AWS for development and enables AWS Systems Manager Session Manager for server access. They enforce MFA on console logins, require Just-In-Time IAM role elevation for admins, log sessions to S3 with server-side encryption and S3 Object Lock for immutability, and forward CloudTrail events to a lightweight SIEM (Wazuh). For assessment, they provide session recordings, S3 access logs showing integrity, an incident ticket where a session was terminated, and the IAM policy granting JIT access. Example 2: A small manufacturing firm uses an on-prem SSH bastion with OpenSSH forced commands and auditd; they centralize logs via rsyslog over TLS to a VM running Elastic Stack, with Kibana dashboards showing session starts and terminations and alerts for sessions longer than business hours.
Risks of non-implementation and compliance tips
Failing to monitor and control remote sessions increases risk of undetected lateral movement, credential theft, and exfiltration of CUI — and in CMMC contexts can lead to failing an assessment, losing DoD contracts, or being required to implement costly compensating controls. Practical compliance tips: (1) Start with a minimum viable monitoring solution and iterate — centralize logs first. (2) Use cloud-native session managers where possible to lower attack surface. (3) Document exceptions and compensating controls in a POA&M. (4) Build reproducible evidence by scripting configuration exports and automated daily backups of logs. (5) Train staff and run quarterly live drills to prove the process works.
In summary, to prepare for a CMMC 2.0 Level 2 assessment for AC.L2-3.1.12, funnel remote access through hardened gateways or PAM, enforce strict session controls (MFA, time limits, disabled transfer features), centralize and retain session logs with clear correlation to identity, and assemble a compact evidence package showing architecture, configurations, logs, alerts, and incident handling — doing so both reduces real security risk and gives assessors the repeatable proof they need to award compliance.
