The Access Control Domain: the foundation of every other control family

What the Access Control Domain Is For

Access Control is the first domain in the NIST SP 800-171 Revision 2 framework, and it is also the domain that most directly shapes how every other domain operates. The twenty-two requirements within AC define who is permitted to reach the CMMC environment, what they are permitted to do once inside, and how their sessions are managed from initial login through termination. Every other control family in the standard assumes that these access decisions have been made correctly.

The Audit and Accountability controls depend on knowing which authorized actor performed which action. The Configuration Management controls depend on knowing who is authorized to approve or implement a change. The Media Protection controls depend on knowing who can physically access storage that contains CUI. When Access Control is implemented poorly, the failures compound across the rest of the framework.

For defense contractors approaching CMMC Level 2, the Access Control domain typically produces the largest volume of assessment evidence and the widest range of findings. This is not because AC is harder than other domains. It is because AC touches every system, every user, and every connection pathway into the CMMC boundary. An assessor evaluating AC is effectively evaluating whether the contractor has defined the boundary in the first place.

This page walks through the structure of the twenty-two AC controls, groups them into four functional clusters that reflect how they operate together in practice, and provides practitioner commentary on the implementation patterns that come up most often in readiness work. Each control references a dedicated reference card with the full assessment objectives and methods sourced verbatim from CMMC Assessment Guide Level 2 v2.13.

The Structure of the 22 Controls

The standard lists the AC requirements sequentially from 3.1.1 through 3.1.22, but the controls operate in four distinct clusters. Recognizing these clusters makes the domain easier to work with during readiness planning and gives assessment teams a cleaner way to organize evidence.

The first cluster covers account and access authorization. These seven controls (3.1.1 through 3.1.7) establish who is permitted into the environment, what they are permitted to do, and how privileged functions are separated from routine use. This is the foundation of the domain. If this cluster is weak, the rest of the domain cannot compensate.

The second cluster covers session management. These four controls (3.1.8 through 3.1.11) govern what happens during an active session, including how failed logins are handled, what notices are displayed at login, how long idle sessions can remain open, and how sessions are terminated. These controls are often treated as routine configuration items, but assessors look closely at whether the settings are applied consistently across the full scope.

The third cluster covers remote, wireless, and mobile access. These eight controls (3.1.12 through 3.1.19) address every path into the CMMC environment that does not originate from inside the physical perimeter. Remote access, wireless networks, and mobile devices each carry their own requirements, and contractors with distributed workforces or manufacturing floors often find this cluster to be the most operationally complex.

The fourth cluster covers external systems and public information. These three controls (3.1.20 through 3.1.22) address connections that reach outside the boundary and information that is made publicly available. The cluster is small but frequently underestimated. Late-stage assessment findings in this area tend to trace back to external connections the contractor did not realize were in scope.

The first cluster establishes the baseline of the domain. Every other control in AC assumes that these seven are working correctly. The authorization chain that runs through this cluster is the reference point for every other access decision the environment will make.

AC.L2-3.1.1Authorized Access Control

The foundational requirement of the domain. Every user, process, and device with access to the CMMC environment must be authorized, and that authorization must be traceable to a documented decision. Findings in this area rarely involve the complete absence of access controls. They more often involve accounts that exist without clear authorization, shared credentials that bypass individual accountability, and orphaned accounts that remain active after employees have left the organization. The assessor will ask to see the list of authorized users and will compare it against what the systems actually permit.

AC.L2-3.1.2Transaction and Function Control

Authorization extends beyond the user level to the transaction and function level. A user who is authorized to reach a system is not automatically authorized to perform every action within that system. Role-based access control provides the mechanism, but the implementation detail is what assessors evaluate. They want to see that roles are defined, that users are assigned to roles intentionally, and that the assignments reflect the principle of least privilege from the start rather than accumulating through time.

AC.L2-3.1.3Control CUI Flow

The flow of CUI through the environment must be controlled in accordance with approved authorizations. This is where many contractors encounter an unexpected depth of evidence work. It is not sufficient to state that CUI flows only through approved paths. The contractor must document the approved flows, implement technical controls that enforce those flows, and produce evidence that unauthorized flows are prevented or detected.

AC.L2-3.1.4Separation of Duties

Separation of duties requires that no single individual has the ability to complete a sensitive action end-to-end without oversight. In small organizations this control is frequently the source of friction, because roles naturally concentrate in fewer people. The assessable question is not whether duties are perfectly separated across many individuals, but whether the organization has identified the sensitive functions, recognized where separation is not possible, and implemented compensating controls such as review, logging, or management approval to address the concentration.

AC.L2-3.1.5Least Privilege

Users and processes should have only the privileges necessary to perform their assigned functions. The principle is straightforward. The assessable evidence is not. Contractors often implement least privilege for new accounts and then allow privilege to accumulate as users change roles, take on new responsibilities, or inherit access from predecessors. Periodic review of privilege assignment, documented and actioned, is the signal that least privilege is operating rather than merely declared.

AC.L2-3.1.6Non-Privileged Account Use

Users who hold privileged accounts for administrative work must use non-privileged accounts for nonsecurity functions. An administrator checking email or browsing a vendor site should not be doing so from the same account they use to modify system configurations. The control exists to reduce the blast radius of a compromised session. Implementation usually requires separate accounts per user for administrative and routine activity, and the assessor will look for that separation in practice.

AC.L2-3.1.7Privileged Functions

Non-privileged users must be prevented from executing privileged functions, and when privileged functions are executed, the execution must be captured in audit logs. This control sits at the intersection of AC and AU. The access side prevents unauthorized execution. The audit side records authorized execution. Both sides must be working for the control to pass.

This cluster interacts tightly with the Identification and Authentication domain, which governs how users are identified and authenticated in the first place, and with the Personnel Security domain, which governs how authorization decisions originate from employment and role assignments. A failure in PS or IA will produce findings in AC, because the authorization chain breaks upstream of where the AC controls operate.

The second cluster governs what happens during active sessions. These four controls are often treated as routine settings, but assessors verify that the settings are applied consistently across the full assessment scope.

AC.L2-3.1.8Unsuccessful Logon Attempts

Systems must limit the number of consecutive unsuccessful logon attempts and take protective action when the limit is reached. The protective action is typically account lockout for a defined period, but the specific threshold and duration are contractor decisions that need to be documented and applied uniformly. Findings here often involve systems where the setting is defined at a group policy level but specific systems or accounts have drifted from the policy.

AC.L2-3.1.9Privacy and Security Notices

A system use notification must be displayed before granting access, consistent with applicable rules, regulations, and contractual obligations. The content of the banner is guided by federal practice, and the display must occur at login rather than after authentication. The implementation is mechanical, but the documentation needs to reflect what the banner contains and where it is displayed.

AC.L2-3.1.10Session Lock

Systems must prevent further access after a defined period of inactivity by initiating a session lock that remains in effect until the user reauthenticates. The session lock is a displayed control, typically a screen lock with pattern-hiding behavior, and the reauthentication must involve the same identification and authentication mechanisms that control initial access. In manufacturing environments where workstations are shared, the session lock implementation needs to address the reality that multiple users operate the same physical endpoint.

AC.L2-3.1.11Session Termination

Sessions must be terminated automatically after a defined condition or time period, distinct from the session lock. Where session lock suspends access pending reauthentication, session termination ends the session entirely and requires a new authentication cycle. The distinction matters for assessment evidence. Contractors frequently configure session lock and assume it satisfies both controls, which it does not.

Session management is one of the clearest examples of controls that look trivial in isolation and become complex in practice once the scope expands to include every system, every application, and every remote access pathway that touches CUI. Uniform enforcement across the full boundary is the assessable question.

The third cluster addresses every path into the CMMC environment that does not originate from inside the physical perimeter. The eight controls in this cluster apply differently to different operational environments, and they are the area where contractors with distributed workforces or manufacturing floors encounter the most implementation complexity.

AC.L2-3.1.12Control Remote Access

Remote access sessions must be monitored and controlled. The mechanism is typically a managed VPN or equivalent remote access solution that centralizes authentication, logging, and policy enforcement. The assessable evidence includes the remote access policy, the enforcement point configuration, and the logging that demonstrates monitoring in practice.

AC.L2-3.1.13Remote Access Confidentiality

Cryptographic mechanisms must protect the confidentiality of remote access sessions. In practice, this requirement is satisfied by FIPS-validated cryptography applied to the remote access channel. The validation status of the cryptographic implementation matters because non-validated implementations, even if algorithmically identical, do not satisfy the control.

AC.L2-3.1.14Remote Access Routing

Remote access must be routed through managed access control points. The control prevents remote connections from terminating directly at internal systems without passing through a defined enforcement point. The routing requirement is straightforward in theory and complicated in practice, particularly in environments where legacy remote access solutions coexist with modern ones.

AC.L2-3.1.15Privileged Remote Access

Privileged commands executed via remote access and access to security-relevant information must be authorized. This control layers on top of 3.1.12 by adding a specific authorization requirement for remote administrative activity. The assessable evidence includes the documented authorization scheme, the mechanisms that enforce it, and the logging that captures privileged remote actions.

AC.L2-3.1.16Wireless Access Authorization

Wireless access must be authorized before it is allowed. The authorization covers both the wireless infrastructure itself and the devices connecting to it. In defense manufacturing environments, wireless networks often proliferate for operational reasons, and the authorization boundary can become unclear. Documented authorization for every wireless network that touches the CMMC boundary is the expected evidence.

AC.L2-3.1.17Wireless Access Protection

Wireless access must be protected using authentication and encryption. The specific technical requirements involve FIPS-validated cryptography and strong authentication protocols. Legacy wireless deployments using older protocols are a common source of findings in this area, because the protocols were acceptable when deployed but no longer meet current standards.

AC.L2-3.1.18Mobile Device Connection

The connection of mobile devices to the CMMC environment must be controlled. The control applies to smartphones, tablets, and any portable computing device that connects to systems containing CUI. The implementation typically involves mobile device management, documented policy on approved device types, and technical enforcement of the policy.

AC.L2-3.1.19Encrypt CUI on Mobile

CUI stored on mobile devices and mobile computing platforms must be encrypted. The encryption must be FIPS-validated, and the implementation must cover the full lifecycle of CUI on the device. This control frequently interacts with the MP domain, because the same storage device can be treated as a mobile computing platform under AC and as portable media under MP.

This cluster is where the multi-factor authentication requirement from the IA domain most visibly intersects with AC. Remote access, privileged remote access, and certain wireless access scenarios require multi-factor authentication under IA.L2-3.5.3, and the implementation of MFA becomes part of the AC evidence for these controls. A separate practitioner analysis of the MFA implementation and its interaction with adjacent controls is available in the MFA implementation white paper.

The final cluster addresses connections and information flows that extend outside the defined boundary. It is the smallest cluster in the domain but the one most likely to produce late-stage surprises in assessment work.

AC.L2-3.1.20External Connections

Connections to and use of external systems must be verified and controlled or limited. An external system is any system that is not under the contractor's control, which includes cloud services, partner systems, and vendor platforms. The control requires that the contractor know which external systems connect to the CMMC environment, that the connections are intentional, and that the use is bounded. Mapping every external connection is often the longest single task in preparing for this control.

AC.L2-3.1.21Portable Storage Use

The use of portable storage devices on external systems must be limited. The concern is data movement via portable media that crosses between the CMMC environment and systems outside the boundary. Technical enforcement typically involves endpoint controls that restrict what can be written to removable storage, combined with policy that governs the use of portable media in the first place.

AC.L2-3.1.22Control Public Information

Information posted or processed on publicly accessible systems must be controlled. The control exists to prevent CUI from being posted to public websites, marketing materials, or other externally visible platforms. The assessable evidence includes the review process for publicly posted information and the policy that governs what is permitted.

The cluster is compact but the scope work it requires can be substantial, particularly for organizations that have accumulated cloud services and partner integrations over time without a central inventory of what connects to what.

Where Access Control Intersects with Other Domains

The Access Control domain does not operate in isolation. Its decisions flow into every other domain in the standard, and its effectiveness depends on upstream decisions made elsewhere. Recognizing these interactions is part of the practitioner reading of the framework.

The clearest interaction is with Identification and Authentication. AC determines whether a user is authorized to reach a resource. IA determines whether the entity requesting access is who they claim to be. Authorization without reliable identification is meaningless, which is why the two domains are evaluated together in practice.

Audit and Accountability depends on AC for its referential integrity. Audit records capture actor identity and action. If the actor identity is unreliable because AC permitted shared accounts or allowed privileges to accumulate beyond documented authorization, the audit records lose the interpretability that makes them useful for accountability.

Configuration Management relies on AC for the authorization chain behind every configuration change. A configuration change is authorized because the person making it holds the access permissions that authorize the change, and those permissions were granted through the AC domain. A weak AC implementation produces a weak CM implementation downstream.

Media Protection extends AC decisions into the physical realm. Portable storage, backup media, and removable devices all fall under MP, but the question of who is permitted to access or move such media originates in AC. The encryption requirement in AC.3.1.19 for mobile CUI is complemented by the MP requirements for media sanitization and marking.

System and Communications Protection implements the technical boundaries that AC relies on. The network segmentation that separates the CMMC environment from the rest of the contractor's network is an SC control, and the effectiveness of that segmentation determines where AC decisions apply.

Personnel Security is the upstream source of most AC authorizations. The decision to grant a user access originates with an employment relationship and a role assignment, both of which are governed by PS. When PS is weak, AC inherits that weakness because authorizations are made against personnel records that are incomplete or outdated.

These interactions are not abstract. During readiness work, findings that appear to be AC findings often trace back to gaps in one of these adjacent domains. Resolving the AC finding requires addressing the upstream cause.

Common Implementation Pitfalls

Certain patterns come up repeatedly in Access Control readiness work. Recognizing them during self-assessment reduces the risk of discovering them during the C3PAO assessment.

Documented authorization that does not match actual access. The authorization records show one set of permissions. The systems grant a different set. The gap typically opens over time as users change roles, take on new responsibilities, or receive temporary access that is never revoked. A periodic reconciliation between documented authorization and actual system permissions is the only reliable way to keep this gap from widening.

Privileged access that has expanded beyond its original scope. Privileged accounts are frequently created for legitimate purposes and then retained past the period when the elevated privilege was needed. The accumulation is invisible until someone conducts a privilege review, which many organizations do not perform on a defined schedule. The assessable question is not whether every privileged account is justified at creation, but whether the organization has a mechanism for detecting and removing privilege that is no longer needed.

Service accounts without ownership. Service accounts are created for applications and automated processes, often during initial system deployment, and then they persist without clear ownership. When the original administrator leaves the organization, the service account continues to function, but no one can say what it does or whether its permissions remain appropriate. A service account inventory with documented ownership is not a glamorous deliverable, but it closes a common gap.

Wireless boundaries that are assumed rather than verified. Contractors often believe their wireless network is logically separated from their CMMC environment because the wireless SSID is distinct or because the wireless traffic is routed through a firewall. The assumption holds until someone verifies that wireless clients cannot actually reach CUI-bearing systems. Verification involves testing, not documentation review.

External system inventory that is incomplete. The count of external systems connected to the CMMC environment is typically larger than the contractor initially believes. Cloud services added for specific projects, vendor integrations set up by individual departments, and third-party platforms connected during acquisitions all tend to accumulate without central visibility. The inventory exercise for AC.3.1.20 often reveals connections that the compliance team did not know existed.

Remote access pathways that predate current policy. Organizations with a history of remote work, legacy VPN deployments, or vendor maintenance connections frequently have remote access pathways that were configured before current policies were in place. The pathways continue to function, but their alignment with AC.3.1.12 through AC.3.1.15 has not been verified. A full inventory of every inbound remote access pathway, documented and tested, addresses this.

Where to Start

For an organization new to the Access Control domain, the first work is not technical. It is inventory.

The foundational deliverable is an accurate list of user accounts with documented authorization for each, including the role the account serves, the systems it can reach, and the personnel record that supports the authorization. From that list, every other AC control becomes tractable. Least privilege can be evaluated against the documented roles. Privileged access can be reviewed against the justifications. Session policies can be applied uniformly because the scope of systems is known.

The second deliverable is the boundary itself. AC controls apply to the CMMC assessment scope, and the scope has to be defined before the controls can be implemented. A precise boundary diagram, identifying which systems are in scope and which are not, and which connections cross the boundary, is the companion document to the user account inventory.

With the account inventory and the boundary defined, the domain work becomes a structured walk through the twenty-two controls with a clear picture of what each one applies to. Without those two foundational documents, AC implementation tends to become a series of technical configurations that may or may not reflect the actual environment.