CMMC Level 2: Access Control & Identity Requirements

Access Control (AC) and Identification & Authentication (IA) form the largest practice areas in CMMC Level 2, comprising 34 of the 110 total requirements. These domains establish who can access your systems, how they prove their identity, and what they can do once authenticated.

Access Control Domain Overview

The Access Control domain contains 22 practices from NIST SP 800-171 section 3.1. These requirements govern who can access your systems, what they can do, and how you control that access for both internal users and remote connections.

Account Management (3.1.1 - 3.1.2)

Building on Level 1, these practices require formal account management processes:

• 3.1.1: Limit system access to authorized users, processes, and devices
• 3.1.2: Limit access to authorized transaction types and functions

Implementation guidance: Implement role-based access control (RBAC) with documented roles mapped to job functions. Conduct quarterly access reviews to verify users still need their assigned permissions.

Information Flow Control (3.1.3)

3.1.3: Control the flow of CUI in accordance with approved authorizations.

What this means: You must control how CUI moves within your environment and to external parties. This includes email, file transfers, and data exports.

Implementation example:

• Deploy Data Loss Prevention (DLP) tools to monitor CUI movement
• Restrict USB drive usage on systems processing CUI
• Control which applications can access CUI repositories
• Implement email policies preventing CUI in unencrypted messages

Separation of Duties (3.1.4)

3.1.4: Separate the duties of individuals to reduce the risk of malevolent activity without collusion.

Implementation example:

• The person who requests access shouldn't approve their own request
• System administrators shouldn't be the only ones reviewing audit logs
• Financial approvals require multiple signers above thresholds
• Security assessors shouldn't assess systems they helped configure

Least Privilege (3.1.5 - 3.1.8)

These four practices establish the principle of minimum necessary access:

• 3.1.5: Employ the principle of least privilege, including for specific security functions and privileged accounts
• 3.1.6: Use non-privileged accounts when accessing nonsecurity functions
• 3.1.7: Prevent non-privileged users from executing privileged functions and capture their execution in audit logs
• 3.1.8: Limit unsuccessful logon attempts

Implementation guidance:

• IT admins should use separate accounts for admin tasks vs. daily email
• Implement Privileged Access Management (PAM) solutions
• Configure account lockout after 3-5 failed login attempts
• Remove local administrator rights from standard user accounts
• Use just-in-time (JIT) privileged access where possible

Session Controls (3.1.9 - 3.1.12)

• 3.1.9: Provide privacy and security notices consistent with CUI rules
• 3.1.10: Use session lock with pattern-hiding displays after inactivity
• 3.1.11: Terminate user sessions after defined conditions
• 3.1.12: Monitor and control remote access sessions

Implementation example:

• Display login banners warning about authorized use and monitoring
• Configure screensaver lock after 15 minutes of inactivity
• Terminate idle VPN sessions after 30 minutes
• Log all remote access connections with source IP and duration

Remote Access (3.1.12 - 3.1.15)

Remote access to CUI requires strong controls:

• 3.1.12: Monitor and control remote access sessions
• 3.1.13: Employ cryptographic mechanisms to protect remote access confidentiality
• 3.1.14: Route remote access via managed access control points
• 3.1.15: Authorize remote execution of privileged commands and access to security-relevant information

Implementation guidance:

• Require VPN with strong encryption (AES-256) for all remote access
• Implement multi-factor authentication for remote connections
• All remote access should route through a single, monitored gateway
• Explicitly authorize and log any remote privileged access
• Consider Virtual Desktop Infrastructure (VDI) to keep CUI off personal devices

Wireless Access (3.1.16 - 3.1.17)

• 3.1.16: Authorize wireless access prior to allowing connections
• 3.1.17: Protect wireless access using authentication and encryption

Implementation example:

• Use WPA3 or WPA2-Enterprise with RADIUS authentication
• Separate guest WiFi from corporate network
• Disable WPS (WiFi Protected Setup)
• Maintain an inventory of authorized wireless access points
• Conduct periodic scans for rogue access points

Mobile Devices (3.1.18 - 3.1.19)

• 3.1.18: Control connection of mobile devices
• 3.1.19: Encrypt CUI on mobile devices and mobile computing platforms

Implementation guidance:

• Implement Mobile Device Management (MDM) for company devices
• Require device encryption and strong PINs/passcodes
• Enable remote wipe capability
• Prohibit CUI on personal (BYOD) devices, or implement containerization
• Disable USB debugging and require security patches

External Systems (3.1.20 - 3.1.22)

• 3.1.20: Verify and control/limit connections to external systems
• 3.1.21: Limit use of portable storage devices on external systems
• 3.1.22: Control CUI posted or processed on publicly accessible systems

Implementation example:

• Maintain an approved list of external systems/cloud services
• Require contractual security agreements with external system providers
• Block or encrypt USB devices through endpoint policies
• Never allow CUI on public-facing websites or social media

Identification and Authentication Domain Overview

The IA domain contains 12 practices from NIST 800-171 section 3.5. These requirements ensure you can reliably identify users and devices before granting access and that those identities are verified through strong authentication.

User Identification (3.5.1 - 3.5.2)

• 3.5.1: Identify system users, processes, and devices
• 3.5.2: Authenticate identities before granting access

These baseline requirements from Level 1 are enhanced at Level 2 with more rigorous implementation.

Multi-Factor Authentication (3.5.3)

3.5.3: Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.

MFA implementation requirements:

• Privileged accounts: MFA required for both local and network access
• Non-privileged accounts: MFA required for network access
• Use authenticator apps, hardware tokens, or FIDO2 keys (avoid SMS when possible)
• Enroll all accounts in MFA before granting access to CUI systems

Replay-Resistant Authentication (3.5.4)

3.5.4: Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.

What this means: Authentication credentials should be unique per session so captured credentials can't be reused (replayed) by attackers.

Implementation: Modern protocols like Kerberos, TLS client certificates, and TOTP-based MFA are inherently replay-resistant. Avoid legacy protocols like NTLM where possible.

Identifier Management (3.5.5 - 3.5.6)

• 3.5.5: Prevent reuse of identifiers for a defined period
• 3.5.6: Disable identifiers after a defined period of inactivity

Implementation guidance:

• Never reassign usernames of former employees to new hires
• Disable accounts after 90 days of inactivity
• Implement automated account lifecycle management
• Review inactive accounts monthly

Authenticator Management (3.5.7 - 3.5.11)

These practices govern how you manage passwords, tokens, and other authentication methods:

• 3.5.7: Enforce minimum password complexity and change of characters when creating new passwords
• 3.5.8: Prohibit password reuse for a specified number of generations
• 3.5.9: Allow temporary passwords for system logons with immediate change requirement
• 3.5.10: Store and transmit only cryptographically-protected passwords
• 3.5.11: Obscure feedback of authentication information

Modern password guidance:

• Minimum 12-14 characters (or 8+ with MFA)
• Prohibit reuse of last 24 passwords
• Check passwords against breach databases (haveibeenpwned)
• Store passwords using strong hashing (bcrypt, Argon2)
• Display dots or asterisks when typing passwords
• Force password change on first login for new accounts

Common Implementation Challenges

Legacy Systems

Older systems may not support MFA or modern authentication protocols. Options include:

• Place legacy systems behind a jump server that requires MFA
• Network-segment legacy systems with additional monitoring
• Document compensating controls in your System Security Plan
• Create a Plan of Action & Milestones (POA&M) for remediation

Service Accounts

Automated processes can't do interactive MFA. Best practices include:

• Use managed service accounts with automatic password rotation
• Implement certificate-based authentication where possible
• Restrict service account permissions to minimum necessary
• Monitor service account usage for anomalies

Evidence for Assessment

Prepare the following documentation for your C3PAO assessment:

• Access Control Policy and procedures
• User account inventory with role assignments
• MFA enrollment reports
• Group Policy Object (GPO) exports showing password policies
• Remote access architecture diagrams
• Mobile device management reports
• Account review meeting minutes
• Screenshots of login banners
• VPN configuration showing encryption settings

Key Takeaways

• Access Control and Identity are the largest CMMC domains (34 practices)
• Multi-factor authentication is required for all network access
• Remote access must be encrypted, monitored, and routed through managed gateways
• Least privilege and separation of duties reduce insider threat risk
• Mobile devices and external systems require explicit controls

Next in the Series

Continue to CMMC Level 2: Audit, Accountability & Risk to learn about logging, monitoring, and risk assessment requirements.

Ready to simplify your CMMC compliance? Get early access to Pretorin and let AI help you track your implementation progress.