Access control.
Who can touch CUI, and how that gets enforced. The largest Level 2 family.
Access Control is 22 of Level 2’s 110 requirements — one in five. It governs who and what may reach a system that touches CUI, what they’re allowed to do once they’re in, and how remote and wireless access get controlled. Nearly every other family assumes AC is already working: audit logs (AU) record what authorized accounts did; incident response (IR) investigates what an account should not have done. What follows breaks down AC’s 22 requirements.
This page explains the family. It does not replace the requirement text or assessment objectives.
01What this family protects
Access Control protects the boundary between people (and the processes and devices acting for them) and the systems that hold CUI. It answers a small set of questions that sound simple and aren’t: who is allowed in, what are they allowed to do once they’re there, and does that change when the connection is remote, wireless, or from a personal device. Get AC wrong, and every other family’s protections sit behind a door that doesn’t actually check who’s knocking.
02The rule says
All 22 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.1 has the full text and discussion for each; Source Library covers when to open it.
| § | Requirement |
|---|---|
| 3.1.1 | Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). |
| 3.1.2 | Limit system access to the types of transactions and functions authorized users are permitted to execute. |
| 3.1.3 | Control the flow of CUI in accordance with approved authorizations. |
| 3.1.4 | Separate the duties of individuals to reduce the risk of malevolent activity without collusion. |
| 3.1.5 | Employ the principle of least privilege, including for specific security functions and privileged accounts. |
| 3.1.6 | Use non-privileged accounts or roles when accessing nonsecurity functions. |
| 3.1.7 | Prevent non-privileged users from executing privileged functions, and capture the execution of such functions in audit logs. |
| 3.1.8 | Limit unsuccessful logon attempts. |
| 3.1.9 | Provide privacy and security notices consistent with applicable CUI rules. |
| 3.1.10 | Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity. |
| 3.1.11 | Terminate (automatically) a user session after a defined condition. |
| 3.1.12 | Monitor and control remote access sessions. |
| 3.1.13 | Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. |
| 3.1.14 | Route remote access via managed access control points. |
| 3.1.15 | Authorize remote execution of privileged commands and remote access to security-relevant information. |
| 3.1.16 | Authorize wireless access prior to allowing such connections. |
| 3.1.17 | Protect wireless access using authentication and encryption. |
| 3.1.18 | Control connection of mobile devices. |
| 3.1.19 | Encrypt CUI on mobile devices and mobile computing platforms. |
| 3.1.20 | Verify and control/limit connections to and use of 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. |
03In practice
In a shop with a handful of IT staff, AC mostly comes down to three ordinary habits done consistently, plus two that are easy to skip because they only matter at the edges.
Account discipline (3.1.1–3.1.8). A defined list of who has an account, what each account is allowed to do, and a process for removing access when someone leaves — not a spreadsheet nobody updates. Least privilege (3.1.5) means the CAD/CAM operator’s account can open and edit drawings, not administer the server it runs on. Non-privileged day-to-day accounts (3.1.6) mean nobody does routine work while logged in as an administrator, because that account is the one thing standing between a phishing click and a compromised domain.
Session hygiene (3.1.9–3.1.11). Screens that lock, sessions that end, notices that say what people are agreeing to. Small, and rarely the reason an assessment stalls.
Remote and wireless access (3.1.12–3.1.17). This is where most of the actual engineering work sits: a managed VPN or access-control point instead of a bare RDP port facing the internet, encryption on that connection, and monitoring that shows who connected and when. Wireless, if it exists on a network segment anywhere near CUI, needs the same authentication and encryption bar.
Devices and external systems (3.1.18–3.1.22). Mobile devices that touch CUI need encryption and a way to be controlled (or a policy that says CUI doesn’t go on them at all, which is often the simpler answer for a small shop). External systems — a prime’s portal, a personal cloud account, another company’s network — get verified and controlled before anything connects, and public-facing systems (a website, a shared portal) get checked for what they might accidentally expose.
04Where it fails
More often, the gap is not a missing control; it’s an account list that used to be accurate. Someone left eight months ago and still has network access because offboarding is a step someone remembers, not a step the system enforces. A close second: a shared administrator login everyone knows, used for routine work because it’s easier than requesting individual accounts — which quietly erases 3.1.5 and 3.1.6 at the same time.
Remote access is the other recurring gap, usually from convenience rather than neglect: a vendor or an MSP technician gets a standing VPN credential for occasional support work, and that credential outlives the specific job it was created for. None of this is exotic. It’s what happens when access decisions get made once, under time pressure, and never revisited.
05What evidence may look like
Everyday records, not a special compliance binder: a current account list or Active Directory export showing group membership tied to roles; offboarding tickets showing access was pulled on a departure date; VPN configuration and connection logs; a mobile-device management policy and enrollment list; and a short written note on what “least privilege” means for each role at the organization, even if it’s two paragraphs. An assessor is checking whether the practice is real and consistent, not whether the paperwork is elaborate.
06At the shop
Blanchard Tool & Machining is the desk’s fictional composite (any resemblance to an actual company is coincidental). Blanchard’s CAD/CAM share is role-based: machinists can open and mark up drawings for their own jobs; only the two-person IT team and the engineering lead can move files between the share and the primes’ portals. The regional MSP that handles remote monitoring connects through a managed VPN with its own logged, revocable credential — not the domain administrator account — and that credential gets reviewed every quarter, not left running indefinitely. When a machinist left last year, the offboarding ticket that pulled his badge access also pulled his share access the same afternoon, because IT built the two into one checklist after an earlier close call.
07Commonly confused with
Identification & Authentication (IA). AC decides what an authorized identity is allowed to do; IA decides how a system confirms that identity in the first place — passwords, multifactor, replay resistance. They work together at every login: IA authenticates, then AC authorizes. See Identification & Authentication.
System & Communications Protection (SC). AC governs who may open a remote connection at all (3.1.12–3.1.15); SC governs how that connection’s traffic is protected once it’s open (encryption, boundary devices). A remote-access requirement that mentions encryption is usually doing both jobs at once. See System & Communications Protection.
08Cross-desk links
Account discipline, least privilege, and access review are the same operational muscle the lab’s Privacy & Identity material addresses from a broader angle, not tied to any one framework. It is useful background for building the habits AC assumes; it is not a substitute for AC’s own requirement text, and nothing on that page is itself a CMMC requirement.
09Sources
| Document | What it’s for |
|---|---|
| NIST SP 800-171 Rev. 2, §3.1 | Full requirement text and discussion for all 22 AC requirements. |
| NIST SP 800-171A | Assessment objectives — how an assessor determines MET for each AC requirement. |
| CMMC Level 2 Scoping Guidance | What’s in scope before AC requirements get assessed against it. |
| 32 CFR 170.4 | Defines “CMMC Level 2 security requirement” and ties the 800-171 R2 families to the CMMC Program. |