Access Control for CMMC: Implementing the 22 AC Domain Requirements

Understanding the Access Control Domain

Access Control is the largest and most foundational control family in the NIST SP 800-171 framework, comprising 22 of the 110 total security requirements. These requirements govern who can access your systems, what they can do once they have access, and how those access decisions are enforced across your entire environment. For defense contractors pursuing CMMC Level 2 certification, the Access Control domain often requires the most significant implementation effort and represents the area where assessors spend the most time during evaluations.

The breadth of the Access Control family reflects its fundamental importance to information security. Every other security control in the CMMC framework depends on effective access control. Your encryption is meaningless if unauthorized users can access decrypted data. Your audit logs are useless if attackers can access systems without being identified. Your incident response plan is irrelevant if you cannot control who has access to your systems in the first place.

This comprehensive guide walks through all 22 Access Control requirements, organized into logical groupings, with practical implementation guidance for each. Whether you are building your access control program from scratch or refining an existing implementation, this guide provides the detailed understanding you need for successful CMMC certification.

Account Management Requirements (AC 3.1.1 – 3.1.2)

The first two requirements establish the foundation of access control by addressing who is authorized to access your systems and how those authorizations are managed throughout the user lifecycle.

Requirement 3.1.1 mandates that you limit system access to authorized users, processes acting on behalf of authorized users, and devices including other systems. This means maintaining a definitive list of who and what is authorized to access each system in your environment. Every user account must be traceable to an authorized individual with a documented business need for access. Every device connecting to your network must be identified and authorized. Every automated process must be associated with a responsible owner.

Implementing this requirement effectively requires a formal account management process that covers the entire lifecycle of user accounts from creation through modification to eventual removal. When a new employee joins your organization, there should be a documented process for requesting, approving, and provisioning their system access based on their role and responsibilities. The approval should come from someone with authority to grant access, typically the employee’s manager and the system owner.

Requirement 3.1.2 limits access to the types of transactions and functions that authorized users are permitted to execute. This is the principle of least privilege applied at the functional level. A user may be authorized to access a system, but that does not mean they should have unrestricted access to every function within that system. An accounts payable clerk needs access to the financial system but should not have the ability to modify system configurations or access engineering data.

Role-based access control is the most common and effective method for implementing this requirement. Define roles that correspond to job functions within your organization, assign appropriate permissions to each role, and then assign users to roles based on their responsibilities. This approach is scalable, auditable, and easier to manage than assigning permissions individually to each user.

Information Flow Control (AC 3.1.3 – 3.1.5)

Requirements 3.1.3 through 3.1.5 address how CUI flows through and between your systems, focusing on controlling that flow to prevent unauthorized access or disclosure.

Requirement 3.1.3 requires you to control the flow of CUI in accordance with approved authorizations. This means understanding your CUI data flows — where CUI enters your environment, how it moves between systems and users, where it is stored, and how it exits your environment — and implementing controls at each point to ensure the information flows only through approved channels to approved recipients.

Practical implementations include data loss prevention tools that monitor and control the movement of CUI across email, cloud services, removable media, and printing. Network segmentation that restricts CUI to designated network zones prevents unauthorized flow between segments. Email encryption policies that automatically encrypt messages containing CUI ensure protected transmission. SharePoint or file share permissions that restrict CUI document libraries to authorized users prevent unauthorized access to stored CUI.

Requirement 3.1.4 separates the duties of individuals to reduce the risk of malevolent activity without collusion. Separation of duties ensures that no single individual has complete control over a critical process. For example, the person who approves a new user account should not be the same person who provisions the account in the system. The administrator who manages backup systems should not be the only person who reviews backup logs for anomalies.

Requirement 3.1.5 employs the principle of least privilege, including for specific security functions and privileged accounts. This requirement goes beyond basic role-based access to mandate that even within authorized roles, users should have the minimum access necessary. Administrative access should be granted only when needed and should use separate administrative accounts rather than elevating the privileges of standard user accounts.

Unsuccessful Logon and Session Controls (AC 3.1.8 – 3.1.11)

These requirements address how your systems handle authentication failures and manage user sessions to prevent unauthorized access through brute force attacks or unattended sessions.

Requirement 3.1.8 limits unsuccessful logon attempts. Your systems must enforce a maximum number of consecutive failed login attempts and take an appropriate action when the limit is reached, such as locking the account for a period of time or requiring administrator intervention to unlock it. This prevents attackers from systematically guessing passwords through brute force or credential stuffing attacks. A common implementation locks accounts after five consecutive failed attempts for a minimum of fifteen minutes.

Requirement 3.1.9 provides privacy and security notices consistent with applicable CUI rules. Before users authenticate to your systems, they should see a banner that informs them the system is for authorized use only, that their activities may be monitored, and that unauthorized access may result in disciplinary or legal consequences. This banner serves both a legal and deterrent function.

Requirement 3.1.10 uses session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. This means your systems must automatically lock after a defined inactivity period, typically fifteen minutes or less, and display a screen saver or lock screen that does not reveal any CUI or system information. Users must re-authenticate to resume their session.

Requirement 3.1.11 terminates user sessions after a defined condition such as a period of inactivity or a specific time of day. This goes beyond session lock by actually ending the session rather than simply locking it. Session termination is particularly important for remote access sessions, which should be terminated after extended periods of inactivity to reduce the window of opportunity for session hijacking.

Remote Access Controls (AC 3.1.12 – 3.1.15)

Remote access represents one of the highest-risk access paths in any environment, and these requirements impose specific controls on how remote connections to your systems are managed and protected.

Requirement 3.1.12 requires you to monitor and control remote access sessions. Every remote access connection must be logged, and the logs must capture sufficient detail to identify the user, the time and duration of the session, and the resources accessed. Monitoring should include both real-time alerting for suspicious activities and periodic review of remote access logs for anomalous patterns.

Requirement 3.1.13 employs cryptographic mechanisms to protect the confidentiality of remote access sessions. All remote access connections must be encrypted using FIPS-validated cryptographic modules. This typically means implementing VPN solutions that use approved encryption algorithms such as AES-256 for data protection and approved protocols such as IKEv2 or TLS 1.2 and above for session establishment.

Requirement 3.1.14 routes remote access via managed access control points. Rather than allowing direct remote connections to individual systems, all remote access should pass through a centralized access point such as a VPN gateway or remote access server. This centralization allows you to apply consistent security policies, perform thorough logging, and maintain a single point of control for all remote connections.

Requirement 3.1.15 authorizes remote execution of privileged commands and remote access to security-relevant information. When administrators need to perform privileged actions remotely, those actions must be specifically authorized and logged. Organizations should implement privileged access management solutions or at minimum require explicit authorization and enhanced logging for remote administrative sessions.

Wireless Access Controls (AC 3.1.16 – 3.1.17)

Wireless networks introduce unique access control challenges due to the broadcast nature of radio communications and the difficulty of physically restricting wireless signal propagation.

Requirement 3.1.16 authorizes wireless access prior to allowing such connections. Only authorized devices should be able to connect to your wireless networks, and the authorization process should verify both the device and the user. Enterprise wireless authentication using WPA3-Enterprise or WPA2-Enterprise with 802.1X authentication provides strong device and user verification.

Requirement 3.1.17 protects wireless access using authentication and encryption. Wireless networks that carry CUI must use strong encryption and authentication mechanisms. Open wireless networks or networks using weak encryption such as WEP or WPA-Personal are not acceptable. Guest wireless networks must be completely isolated from networks that process CUI, with no ability for traffic to flow between them.

Mobile Device and External System Controls (AC 3.1.18 – 3.1.20)

These requirements address access from mobile devices and connections to external systems that may not be under your direct control.

Requirement 3.1.18 controls connection of mobile devices. If your organization allows mobile devices to access systems containing CUI, those devices must be managed and controlled. This typically requires a mobile device management solution that enforces encryption, screen lock requirements, remote wipe capability, application restrictions, and compliance checking before granting access.

Requirement 3.1.19 encrypts CUI on mobile devices and mobile computing platforms. Any CUI stored on mobile devices must be encrypted using FIPS-validated cryptographic mechanisms. This applies to smartphones, tablets, laptops used in a mobile capacity, and any other portable computing devices that may contain CUI.

Requirement 3.1.20 verifies and controls connections to and use of external systems. When your systems connect to external systems such as cloud services, business partner networks, or contractor systems, those connections must be verified and controlled. This includes understanding the security posture of external systems, establishing appropriate agreements regarding security requirements, and implementing technical controls to protect your systems from risks introduced by external connections.

Publicly Accessible Content and Additional Controls (AC 3.1.21 – 3.1.22)

The final two requirements in the Access Control family address specific scenarios that are often overlooked but important for comprehensive access control.

Requirement 3.1.21 limits access to CUI posted or processed on publicly accessible systems. If your organization operates any publicly accessible systems such as public websites or file transfer servers, you must ensure that CUI cannot be posted to or accessed from these systems. Implement review and approval processes for content published to public-facing systems to prevent accidental CUI disclosure.

Requirement 3.1.22 controls CUI posted or processed on publicly accessible systems. This requirement works in conjunction with 3.1.21 to ensure that even if CUI inadvertently appears on a public system, controls are in place to detect and remove it promptly. Regular reviews of publicly accessible content should be conducted to verify that no CUI has been inadvertently published.

Implementation Strategy and Best Practices

Implementing all 22 Access Control requirements is a significant undertaking that benefits from a structured approach. Begin by documenting your current access control posture against each requirement. Identify which requirements are fully met, partially met, and not met. This gap analysis forms the basis for your implementation plan.

Prioritize your implementation based on risk. Requirements related to privileged access control, remote access protection, and CUI flow control typically represent the highest risk areas and should be addressed first. Account management and session controls, while important, may be lower risk in environments where other compensating controls exist.

Invest in a centralized identity and access management platform that can enforce access policies consistently across your environment. Solutions like Microsoft Active Directory with Entra ID provide integrated capabilities for account management, role-based access control, multi-factor authentication, conditional access, and session management that address many of the Access Control requirements from a single platform.

Document everything thoroughly. Access control policies, procedures, role definitions, access approval records, and access review results are all evidence that assessors will request during your CMMC assessment. Establishing good documentation practices from the beginning saves significant effort during assessment preparation.

Conduct regular access reviews to verify that user permissions remain appropriate over time. People change roles, responsibilities evolve, and projects end, but access permissions often persist long after they are no longer needed. Quarterly access reviews by system owners help identify and remove excessive permissions before they become a compliance issue or a security risk.

Easy Compliances offers comprehensive CMMC training that covers all 22 Access Control requirements with practical implementation guidance tailored to defense contractors. Our compliance toolkit includes access control policy templates, role definition frameworks, and access review procedures that streamline your implementation effort. Start mastering the largest CMMC control family today with our expert resources.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top