DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.1

By Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager

DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.1

Note: Important Change as of November 2021
The Department of Defense announced a major overhaul to the Cybersecurity Maturity Model Certification (CMMC) program. No new contracts will feature CMMC compliance requirements until the Department completes its rulemaking process for CMMC 2.0. Read our summary of the changes, Goodbye CMMC 1.0, Hello CMMC 2.0. For more detailed information, visit the CMMC website.


Keiter’s Cybersecurity team will continue to monitor the rollout of the CMMC program and update you on new information and changing requirements for DoD contractors.

CMMC Maturity Level (ML) 1 Practices: Overview of AC.L1-3.1.1

Editor’s note: This article is one of a series of articles about the CMMC Maturity Level (ML) 1 Practices. In these articles we dive in to the CMMC Practice Guides and provide our thoughts about the practices and what contractors should consider. The CMMC ecosystem is still developing, and as those developments occur, we will update these articles accordingly. As such, we hope that these articles represent an evergreen CMMC ML-1 resource.

Practice Number: AC.L1-3.1.1
Practice: Limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems).

Assessment Objectives
Determine if:
[a] authorized users are identified;
[b] processes acting on behalf of authorized users are identified;
[c] devices (and other systems) authorized to connect to the system are identified;
[d] system access is limited to authorized users;
[e] system access is limited to processes acting on behalf of authorized users; and
[f] system access is limited to authorized devices (including other systems).

(source: CMMC ML-1 Assessment Guide)

Overview of AC.L1-3.1.1

Despite having six Assessment Objectives, it is useful to think of this practice as having two overall requirements:

  1. Organizations need to know of all user accounts, whether they are associated with a person [a], service [b], or a device [c], that can connect to in-scope systems/data.
  2. Organizations need to limit access of those user accounts to authorized users [d, e, f].

Assessment Objectives [a], [b], and [c] only differ from each other in the type of account to which they refer.

  • [a] refers to accounts that relate to people, i.e., employees and contractors of the entity.
  • [b] refers to processes acting on behalf of authorized users. An example of this is a service account. For example, let’s say you have an application on your corporate network that can export Adobe Acrobat (PDF) files to a shared folder. It is likely that the application will require rights to the network to write those PDF files, and those rights will be granted via a user account. Other examples may include accounts that are used to process backup jobs, database operations, and network security functions.
  • [c] is a catch-all for all other accounts not captured in [a] or [b], though its names printers in the Assessment Guide’s Further Discussion. In this context, multi-function scanners and printers frequently can email attachments or write files to networks. The accounts used by these devices to accomplish those tasks must also be known to the entity.

Assessment Objectives [d], [e], and [f] only differ from each other in the type of account to which they refer. Additionally, whereas [a], [b], and [c] describe organization requirements to know all of the authorized accounts, [d], [e], and [f] provide for the control requirements around those accounts.

When it comes to access authorization, organizations should have controls over four key areas:

  1. New account access
  2. Disabled account access
  3. Access modifications
  4. Periodic access reviews

New Account Access

Organizations should have a documented process to authorize new users prior to granting them access to networks and systems. This should apply to ALL new accounts, including human users [d], service accounts [e], and devices [f].

A new user access process should feature documented requests and approvals being provided to a system administrator, who then grants the access in accordance with the request. The documentation should clearly indicate the level of access (roles, permissions, etc.) that the user should be granted, and should be maintained so that it can be provided to a CMMC assessor. The most common example for most organizations will be new employee access, but the process should function for service accounts and devices as well. In these cases, the need for the account would be both generated and granted by IT. So, to avoid any single person from requesting, approving, and granting access, we recommend that accounts created by IT be approved by a senior IT official, a COO, or CEO, depending on the size of the organization.

Common Pitfall
Organizations going through compliance efforts for the first time frequently have multiple departments with individuals responsible for granting access to different systems.

We often see organizations where IT departments are responsible for granting access to infrastructure systems like networks and email, and service delivery teams are responsible for granting access to the specialized software used to service clients. In our experience, organizations that can consolidate the compliance responsibilities for access controls to as few departments as possible have the most success.

Disabled Account Access

Organizations should have a documented process to ensure that employees who no longer need access have their access deactivated in a timely fashion. This is especially important when employees leave a company. Typically, an employee separation is communicated by the HR Department to the IT Department, and from there the IT department is responsible for disabling the employee’s access. If multiple company departments manage employee access to systems, then the HR Department will have to communicate the separation to every person or team that controls access for the employee. We recommend disabling employee access on or before the end of their last day. As an extra layer of precaution, for employees who are being terminated for cause, we recommend disabling all their access before they are notified that their employment is being terminated.

Access Modifications

Organizations should also have a process in place to increase and decrease account access as the employee’s job responsibilities change. If the employee transfers from one department to another, an official request and approval should be provided to the IT department and other system owners to ensure that access is adjusted as necessary.

Key to Success
IT auditors prefer to have system generated populations whenever they are available. Related to access control, organizations should be able to generate system generated lists that show new users, disabled users, and modified users. These populations should provide the timestamp that the change took place.

With these populations, your assessor is likely to select a sample of the items on that list to ensure that access was granted/modified after it was approved, and that access was disabled for former employees on or before their last day.

Periodic Access Reviews

Each of the processes described so far are manual processes, and as such, they are susceptible to human error. Additionally, they are considered “preventative controls” designed to prevent people from obtaining or retaining unauthorized access. Preventative manual controls should be supplemented with “detective” controls to find instances where something slipped through the cracks. In the context of user access, if someone makes a mistake, e.g., a HR Team member forgets to communicate an employee separation to a system administrator, organizations should have processes in place to detect and correct those issues. Most organizations with detective user access controls implement a quarterly user access review. Although there is variability in exactly how such a review is structured, we generally see processes where system owners generate or are provided system generated lists of users and their corresponding access levels. The system owners then review the access to ensure that no terminated employees or terminated vendors appear on the list and the current access levels for users are appropriate. If access is inappropriate, the system owner would notate as such in the review and submit a request for change to the system administrator.

Because the CMMC specifically identifies service accounts and device accounts, this review should include those accounts as well.


“If it wasn’t documented, it didn’t happen.” This is the approach auditors of all stripes take to their work. If a user was granted access, but there is no evidence of approval, someone’s recollection that they called the IT team will not be sufficient. To comply with the CMMC’s requirements for AC.L1-3.1.1, organizations will need to quickly implement rigorous access approval, disabling, and review processes, document everything, and ensure they can create complete, system generated population reports.

For many organizations used to handling requests such as these over the phone, in person, or over email, there will likely be a bit of a culture shock. Employees are guaranteed to be frustrated when IT staff tell people to “fill out a form and get it approved” before they can grant access. Management must ensure they fully support IT and communicate the importance of compliance to the entire company.

Interested in learning more about CMMC services for your defense contracts? Contact us. We are here to help.


CMMC AB February 2021 Town Hall Meeting Debrief

Share this Insight:

About the Author

Christopher Moschella

Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager

Chris is a Senior Manager in Keiter’s Risk Advisory Services. Chris has a strong combination of IT skills, which range from IT audit and internal control assessments, including general computer controls and application controls, to full stack web development. Most recently, Chris developed a Cybersecurity web application that assesses an organization’s resistance to social engineering attacks. Chris shares his cybersecurity insights on our blog.

More Insights from Christopher Moschella

The information contained within this article is provided for informational purposes only and is current as of the date published. Online readers are advised not to act upon this information without seeking the service of a professional accountant, as this article is not a substitute for obtaining accounting, tax, or financial advice from a professional accountant.


Contact Us