1Overview
AC.L2-3.1.1 is the first requirement in the framework, it carries the maximum five-point weight, and it cannot sit on a plan of action at a Level 2 assessment. It is also among the most commonly self-assessed as implemented while being nowhere close.
The requirement reads like a description of having login accounts, and every company has login accounts, which is why it is so often marked complete without a second thought. What the requirement actually asks is different and harder: that you can name, in writing, everything authorized to reach your systems, and demonstrate that everything else is kept out. The distance between "we have passwords" and "here is our maintained list of authorized users, processes, and devices, and here is the enforcement that holds it" is where this control fails.
Limit system access to authorized users, processes acting on behalf of authorized users, and devices, including other information systems.
The sentence contains three objects of protection, users, processes, and devices, and the assessment tests each of them twice: once for whether it is identified, and once for whether access is actually limited to it. That produces the six assessment objectives that follow, and they are the level at which the control is judged.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.1 into six objectives. Read them as the examination questions, and note the structure: three ask whether a thing is identified, three ask whether access is limited to it.
Authorized users are identified. A maintained, written answer to who is allowed on these systems, not a list held in the administrator's memory.
Processes acting on behalf of authorized users are identified. The service accounts: the backup job, the scanner-to-email account, the ERP integration, the machine-monitoring account. Each one identified, with an owner.
Devices (and other systems) authorized to connect to the system are identified. A real inventory: workstations, servers, the machine controllers, the shop-floor terminals, the CMM computer, the engineer's laptop, anything with a connection into the environment.
System access is limited to authorized users. The identification from [a] is enforced, and departures come off the list promptly.
System access is limited to processes acting on behalf of authorized users. The service accounts from [b] are constrained to what they need, and no unidentified process has access.
System access is limited to authorized devices (including other systems). The inventory from [c] is enforced somewhere, so an unknown machine does not simply gain access.
The three identification objectives and the three limitation objectives depend on each other. Identification without enforcement fails the second three, and enforcement without documentation fails the first three. A contractor who believes the control is implemented usually has partial enforcement and no documentation, which fails all six.
3Failure Patterns
The failures that recur on real floors are consistent, and they are rarely about competence. They are about the gap between an environment and the record of it.
The shared operator login
A terminal logged in as "operator" or "shop" since installation, because individual logins slow the line. If it can reach CUI, this single account defeats objectives [a] and [d] at once, because "operator" is not an identified user and no one can say who was actually at the keyboard. The remedy, individual accounts with fast switching, badge login, or restricting what the terminal can reach, is a workflow change rather than a settings change.
The service accounts nobody owns
Every environment more than a few years old carries accounts created for tools long replaced, some still holding broad privileges, none with a recorded owner. Objective [b] requires each identified with a purpose and an owner, and objective [e] requires each constrained. The discovery routinely surprises the administrator who inherited them.
The device inventory that does not exist
Asked for a device inventory, most shops produce a purchasing spreadsheet or an aging network diagram, and neither is objective [c]. The inventory must reflect what is connected today, including the machine controllers, which are computers whether or not anyone treats them as such. This is also where a scoping decision shows its value: a deliberate boundary keeps this inventory small.
The accounts of departed employees
Objective [d] is tested simply: the assessor takes a list of recent departures from human resources and checks whether their accounts still function. Without a written deprovisioning procedure, they often do, and each one is a direct, demonstrable failure of access limited to authorized users.
The personal laptop with remote access
An engineer working evenings from a personal laptop with a VPN profile is an unauthorized device holding authorized credentials, which fails objective [f] regardless of how legitimate the user is. Remote access is solvable through managed devices or virtual desktops, but trust in the individual is not one of the six objectives.
4Ownership
No control belongs to one person, and 3.1.1 makes the point clearly, because the lists it requires are maintained by IT while the facts inside them are known only to other departments. Assigning these pieces by name, before remediation begins, is the difference between a control that stays satisfied and one that decays between assessments.
| Role | Responsibility for this control |
|---|---|
| IT lead or system administrator | Owns the implementation: the directory, the security groups, the service account cleanup, and the device enforcement mechanism. Produces the exports and configuration evidence. |
| Human resources | Owns the trigger that makes objective [d] work: hires, departures, and role changes reach IT the day they happen, through a defined step in onboarding and offboarding. |
| Department supervisors | Validate the lists, because only the floor supervisor knows whether everyone with access to a terminal still needs it. They confirm their sections of the roster at each review. |
| Program lead | Owns the cadence: reviews happen on schedule, sign-offs are retained, and the evidence stays current rather than being reconstructed before the assessment. |
| Executive sponsor | Accountable for the whole, since a senior official affirms the company's compliance. The sponsor does not build the lists, but the signature rides on them. |
5Tooling
For most small and midsize contractors this control is built almost entirely with Microsoft tooling already present in the environment or already in the license. The gap is rarely missing software; it is that the software was never configured for this purpose and its output was never kept as evidence. The mapping runs by objective pair.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] and [d] | Active Directory or Entra ID, security groups, Group Policy logon rights | The directory is the authoritative user list, security groups gate the CUI shares, and a scheduled PowerShell export becomes the dated review record. Account expiration and a disable-on-departure step close the departed-account gap. |
| [b] and [e] | AD service accounts, group Managed Service Accounts, PowerShell enumeration | A one-time sweep for accounts with service principal names, non-expiring passwords, or years-old password changes produces the discovery list. Migrating to gMSAs removes shared passwords, and each remaining account gets an owner and least-privilege membership. |
| [c] and [f] | AD computer objects, Intune, Network Policy Server with 802.1X, Conditional Access | Domain-joined objects and Intune enrollment form the device inventory. Enforcement is where shops stop short: 802.1X or switch-level control keeps the unknown machine off the network, and Conditional Access does the same for cloud resources. |
| Evidence, all six | Windows Security event log, group membership exports | Logon, account creation, and account deletion events (4624, 4720, 4726) with dated group exports form the operating-over-time record, provided log retention is configured, which is its own requirement family. |
Two caveats. Shop-floor equipment that cannot join a domain or enroll, the machine controllers and older test equipment, is handled by network segmentation, which satisfies objective [f] by controlling what those devices can reach rather than what runs on them. And owning the tool is not implementing the objective. Active Directory exists in every shop that fails 3.1.1; the objective is satisfied by the configuration, the maintained lists, and the retained records, and the assessor looks past the license to those three things.
6Evidence
Implementation and evidence are separate deliverables, and 3.1.1 needs both. This is the satisfied version on the table in the assessment room.
| Evidence | What it demonstrates |
|---|---|
| Access control policy and procedure | The written rules for how access is requested, approved, granted, and removed, describing the operation as it runs. |
| Authorized user list with review records | Objectives [a] and [d]. The current list plus dated review records, because a two-year-old list proves the opposite of what is wanted. |
| Service account inventory | Objectives [b] and [e]. Every non-human account, its purpose, its owner, its privilege level. |
| Device inventory | Objectives [c] and [f]. What is authorized to connect, kept current, including shop-floor and lab equipment inside the boundary. |
| Provisioning and deprovisioning records | Tickets or forms showing access granted with approval and removed at departure, sampled against HR records. |
| Enforcement demonstration | Live configuration showing the controls doing the limiting: group memberships, network access control, or the environment's equivalent. |
Two properties matter throughout. The evidence must describe the environment as it runs, because the assessor compares the paper to the floor. And it must show operation over time, review records with multiple dates and tickets spanning months, since a stack of documents all created the week before the assessment tells its own story. One further point in this control's favor: the lists it forces you to build, users, service accounts, and devices, are the raw material for a dozen later requirements, so a contractor who does 3.1.1 honestly finds the next several controls cheaper.
Building the lists means walking the floor
Every failure pattern here has the same root, the gap between the record and what is actually connected and logged in. Finding it is onsite work: the shop-floor terminals, the controllers, the wiring closet, the conversations with the people who use the systems. That is the readiness work this practice does, and 3.1.1 is usually where it starts.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.1. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.1[a] through 3.1.1[f]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov