6.1 Access Control (AC) Domain: 22 Practices & Core Implementation

Access Control: Users, Functions, Remote Access & External Systems

Access Control is the largest NIST SP 800-171 Revision 2 family, with 22 Level 2 requirements. Four—3.1.1, 3.1.2, 3.1.20, and 3.1.22—also correspond to CMMC Level 1 safeguarding requirements. The remaining 18 are additional at Level 2; Level 2 still evaluates all 22.

Authorization and CUI flow

Requirements 3.1.1 and 3.1.2 ask who or what may access the system and which transactions or functions each authorized identity may perform. Evidence can include identity stores, account approvals, roles, device controls, application permissions, and tests using representative accounts. A current roster alone does not prove that configured access matches approval.

Requirement 3.1.3 controls CUI flow according to approved authorizations. It can apply inside the system and across connected systems. Mechanisms may include routing, gateways, labels, data-loss controls, application rules, or manual release procedures, but CMMC does not mandate one product.

Requirements 3.1.4–3.1.7 cover separation of duties, least privilege, use of nonprivileged accounts or roles for nonsecurity functions, and preventing nonprivileged users from executing privileged functions while capturing privileged execution in audit logs. Separation is risk-based; it does not mean every task always needs two people. A privileged administrator must still use an appropriate nonprivileged context for ordinary work.

Logon and session behavior

Requirement 3.1.8 limits unsuccessful logon attempts. The organization defines values and implements a mechanism such as lockout, delay, or another effective limit. The requirement does not publish a universal number of attempts or lockout duration.

Requirement 3.1.9 provides privacy and security notices consistent with applicable CUI rules. 3.1.10 uses a session lock with a pattern-hiding display after inactivity, while 3.1.11 automatically terminates a user session after an organization-defined condition. Lock and termination are different outcomes and can have different triggers.

Remote access: keep the numbers straight

These requirements do not say that 3.1.12 is “cryptographic authorization” or that 3.1.13 is the managed-gateway rule. A VPN, zero-trust gateway, bastion, or other architecture may implement several objectives, but the team traces each objective to the actual mechanism, authorization, activity, and person.

For 3.1.15, privileged remote actions and access to security-relevant information must be authorized. The requirement does not prohibit every privileged command; it demands controlled authorization tied to legitimate need.

Wireless and mobile devices

Requirement 3.1.16 authorizes wireless access before connection, and 3.1.17 protects wireless using authentication and encryption. The organization identifies the wireless technologies and demonstrates authorized configurations. WPA enterprise modes are common implementations, but the objective is not a vendor checklist.

Requirement 3.1.18 controls connections of mobile devices. 3.1.19 encrypts CUI on mobile devices and mobile computing platforms. Device inventory, connection approval, configured protection, key handling, and a representative test can support the objectives. Mobile-device management may be useful, but the requirement does not prescribe a specific MDM product or demand one architecture for every device.

Where cryptography protects CUI, 3.13.11 separately requires FIPS-validated cryptography. The team verifies the deployed module and validated conditions rather than accepting “AES-256” as sufficient.

External systems, portable storage, and public information

Requirement 3.1.20 verifies and controls or limits connections to, and use of, external systems. 3.1.21 limits use of portable storage devices on external systems. Policies must connect to enforcement and to the actual external systems used by personnel.

Requirement 3.1.22 controls CUI posted or processed on publicly accessible systems. The organization identifies authorized posters, reviews content before posting, and removes CUI discovered on a public system. It does not mean every public website belongs inside the CUI boundary; scope follows the system’s actual capability and relationship.

Evidence sequence

For an Access Control scenario:

1. Identify the user, process, device, data, function, and connection.
2. Select the exact requirement and its 800-171A objectives.
3. Examine approvals, policy, roles, configuration, and records.
4. Interview the personnel who authorize and administer access.
5. Test representative access or denial where appropriate.
6. Confirm the evidence covers the focused sample and current scope.

Suppose policy says terminated users are removed immediately, but a sampled account remains active. The policy supports intent; the directory and test show operation. The relevant objectives are not satisfied merely because the written rule is strong.