How to Actually Implement CMMC Level 2 Access Controls: A Practitioner's Guide

Only authorized users and devices get access, and only to what they need

These two practices are the foundation of the entire AC domain. 3.1.1 says only authorized users (and devices acting on their behalf) can access your systems. 3.1.2 says those users can only perform the transactions their job requires.

How to implement:

• Use Active Directory or Microsoft Entra ID as your central identity provider, no local accounts on individual machines for users who access CUI
• No shared accounts. Every person gets their own named account with their own credentials
• Build a role-based access model: define what each job function needs access to, then assign permissions to roles, not individuals
• Document your provisioning process: how are accounts created, how are they modified, how are they deprovisioned when someone leaves
• Run quarterly access reviews, pull a list of who has access to what and verify it's still appropriate

Common mistake: No formal provisioning process. IT handles requests informally, access accumulates over time, and former employees sometimes retain access for weeks. Assessors will ask for evidence of access reviews.

CUI only flows to places it's authorized to go

This practice requires controlling the movement of CUI between systems and people. It's not just about who can access CUI, it's about where CUI can travel.

How to implement:

• Define approved storage locations for CUI: a specific SharePoint site, a mapped network drive, a designated folder structure with restricted permissions
• Restrict CUI from flowing to personal email accounts or unapproved cloud services, use Microsoft Purview DLP policies or equivalent
• Consider network segmentation: if practical, put CUI systems on a dedicated VLAN isolated from general-purpose networks
• Configure SharePoint and OneDrive so CUI containers aren't publicly accessible or broadly shared
• Classify your CUI data using sensitivity labels so DLP policies can act on it

Common mistake: CUI stored in a shared team folder that every employee can access because "the whole team works on these contracts." Access should be scoped to people who actually handle CUI on those specific contracts.

Admins have two accounts. Nobody has more access than their job requires.

This group of practices is where many small organizations fall short, not because the technology is hard, but because implementing it properly requires restructuring how IT staff work day-to-day.

3.1.4 requires separating duties so no single person can both commit and conceal a malicious action. 3.1.5 requires least privilege, especially for privileged accounts. 3.1.6 says use non-privileged accounts for non-security functions. 3.1.7 prevents non-privileged users from executing privileged functions.

How to implement:

• Create separate admin accounts for IT staff, convention like a-jsmith for the admin account, jsmith for daily work
• The admin account is used only for administrative tasks, not for email, browsing, or daily work
• Use Microsoft Entra Privileged Identity Management (PIM) for just-in-time admin access rather than persistent admin rights, admins request elevation for a specific task and duration
• Remove local administrator rights from standard user workstations
• For financial or approval functions, verify that no single person can both initiate and approve a transaction
• Document your privilege model, who has what admin access, why, and when it was last reviewed

Common mistake: The IT administrator uses their domain admin account for everything, reading email, browsing the web, running reports. If that account is compromised via phishing, the attacker immediately has domain admin. Separate accounts are non-negotiable for CMMC and for basic security hygiene.

Lockout policies, login banners, screen locks, and session timeouts

These four practices are among the easiest to implement and the most commonly missed in documentation. All four can be configured via Group Policy or Intune.

How to implement:

• 3.1.8 (failed logon): Configure Account Lockout Policy in GPO, threshold of 5 invalid attempts, lockout duration of 30 minutes, reset counter after 30 minutes
• 3.1.9 (privacy and security notices): Configure the Interactive Logon legal notice message in GPO, this is the banner users see before logging in. It must include a notice that the system is monitored and unauthorized use is prohibited
• 3.1.10 (session lock): Set screen saver timeout to 15 minutes in GPO with password required on resume. Apply to all machines handling CUI
• 3.1.11 (session termination): Configure session timeout at the application and VPN level. For remote desktop sessions, configure disconnect and idle timeout in GPO under Computer Configuration

Common mistake: Skipping the login banner (3.1.9) because it seems cosmetic. Assessors check for it specifically, and it takes about 10 minutes to configure. Don't leave easy points on the table.

VPN with encryption and MFA. No direct RDP to the internet.

Remote access to systems handling CUI must be encrypted, authenticated, logged, and routed through a managed gateway. These four practices together define what a compliant remote access architecture looks like.

How to implement:

• All remote access to CUI systems requires VPN, no exceptions for "quick access" over direct RDP
• VPN must use strong encryption: AES-256, TLS 1.2 or 1.3 for transport
• MFA is required for VPN authentication (this also satisfies 3.5.3 in the IA domain)
• Enable VPN logging: who authenticated, from what IP, at what time, how long the session lasted
• Never expose RDP (port 3389) directly to the internet, use a jump server, Azure Bastion, or VPN-then-RDP architecture
• Document which roles are authorized to perform privileged administrative functions remotely, and what the approval process is

Common mistake: Port 3389 open in the firewall for a specific server "because we need to get in remotely." This is an immediate assessor finding and a genuine ransomware risk. If you have RDP open to the internet today, close it before your assessment.

WPA2-Enterprise or WPA3, not shared pre-shared keys

Wireless access must be authorized before connections are allowed, and it must use proper authentication and encryption.

How to implement:

• Replace WPA2-PSK (pre-shared key) with WPA2-Enterprise or WPA3 on networks used to access CUI systems, this uses 802.1X authentication with individual credentials, not a shared password
• Set up a RADIUS server to handle 802.1X authentication: Windows Server NPS is built-in and free, or use a cloud RADIUS service
• Maintain a separate guest SSID on an isolated network, no bridge to CUI systems
• IoT devices (printers, cameras, smart devices) should be on an isolated SSID, not on the same network as CUI workstations
• Document which SSIDs are in scope for CUI and maintain a list of authorized devices

Common mistake: Using a shared WPA2 pre-shared key for the corporate network because it's easier to manage. With a PSK, anyone who knows the password can connect, there's no individual authorization, no per-user identity, and no way to revoke access for a specific person without changing the password for everyone.

MDM enrollment required. CUI on mobile must be encrypted.

Mobile devices that connect to CUI systems or store CUI data must be managed and encrypted.

How to implement:

• Implement Mobile Device Management (MDM), Microsoft Intune is the most common for Microsoft 365 environments
• Require device enrollment in MDM before granting access to corporate email or CUI systems via Conditional Access policy
• Enforce device encryption through MDM compliance policies (BitLocker on Windows, FileVault on Mac, built-in encryption on iOS/Android)
• Enable remote wipe capability for all enrolled devices, document that you have this configured
• If allowing BYOD (personal devices), define in policy whether personal devices can access CUI and what controls apply

Common mistake: Employees access corporate email, which may contain CUI discussions or attachments, on personal phones with no MDM enrollment. If that phone is lost or stolen, there's no remote wipe and no evidence of encryption. This is a gap that assessors will probe.

Control cloud services. Control USB devices.

These practices address two common data exfiltration vectors: personal cloud accounts and removable storage.

How to implement:

• Define approved external systems and cloud services in policy, employees should know which cloud storage services are approved for CUI (typically your organization's Microsoft 365 tenant, nothing else)
• Use Conditional Access to block personal Microsoft accounts from syncing on corporate devices
• Configure web filtering to block personal cloud storage services (Google Drive, Dropbox, personal OneDrive) on systems handling CUI
• Configure endpoint USB device control to restrict removable storage, this can be done via Microsoft Defender for Endpoint device control, Intune, or GPO
• If portable storage is required for business reasons, document an approval and logging process

Common mistake: No USB control whatsoever. An employee can plug in a personal thumb drive, copy CUI files to it, and walk out the door. There's no technical control, no log, and no way to detect it after the fact. Defender for Endpoint or Intune device control addresses this with minimal overhead.

CUI never goes on your public website or any public-facing system

Any system that is publicly accessible must not contain or process CUI. This sounds obvious, but contract deliverables, proposal documents, and technical specifications can contain CUI, and they sometimes end up in the wrong place.

How to implement:

• Audit public-facing systems annually for inadvertent CUI content, public SharePoint sites, public file shares, your company website
• Establish a review process before publishing any content derived from government contracts
• Ensure public SharePoint sites and Teams channels have no access to CUI storage locations
• Train staff to recognize CUI markings and understand that CUI cannot go to public systems

Common mistake: A contract deliverable that contains CUI gets emailed to a public project portal or posted to a shared client extranet without anyone checking whether it contains controlled information. A CUI marking review process before external sharing addresses this.