Access Control (AC)¶

Domain: Access Control (AC)
Requirements in this domain: 22
Assessment Objectives in this domain: 70

AC.L2-3.1.1¶

AC.L2-3.1.1[a]¶

Assessment Objective

authorized users are identified.

Collection Approach: Document

Potential Evidence Examples

System Security Plan (SSP) or Account Management Policy/SOP that defines the process for requesting, approving, and provisioning accounts, and states who is responsible for maintaining the authoritative list of authorized users and their assigned roles. Pair with a current export of that user list (e.g., Active Directory OU/group listing or IAM user roster) to show the policy is actually followed.

Assessment Guide – Further Discussion

Is a list of authorized users maintained that defines their identities and roles [a]?

AC.L2-3.1.1[b]¶

Assessment Objective

processes acting on behalf of authorized users are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Account Management Policy/SOP that identifies which system processes and services (e.g., scheduled tasks, application service accounts, API integrations) are permitted to act on behalf of users, and how those service/process accounts are requested, approved, and tracked separately from human user accounts.

AC.L2-3.1.1[c]¶

Assessment Objective

devices (including other systems) authorized to connect to the system are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, Asset/Device Management Policy, or network onboarding SOP that defines the process for authorizing devices (workstations, servers, network gear, and other systems) to connect to the environment, including who approves new devices and how they are added to an authoritative inventory (e.g., AD computer objects, NAC device database, CMDB).

AC.L2-3.1.1[d]¶

Assessment Objective

system access is limited to authorized users.

Collection Approach: Screen Share

Potential Evidence Examples

Live demonstration (screen share) of the login enforcement mechanism — for example, an unauthorized/disabled username rejected at the domain or application logon prompt — plus a corresponding authentication log entry showing the denied attempt, confirming that only accounts on the authorized-user list can reach the system.

Assessment Guide – Further Discussion

Are account requests authorized before system access is granted [d,e,f]?

AC.L2-3.1.1[e]¶

Assessment Objective

system access is limited to processes acting on behalf of authorized users.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the directory or IAM console filtered to service/process accounts, showing each service account is mapped to an approved owner/purpose per the account-request records, and that no unassigned or "orphan" service accounts are active.

Assessment Guide – Further Discussion

Are account requests authorized before system access is granted [d,e,f]?

AC.L2-3.1.1[f]¶

Assessment Objective

system access is limited to authorized devices (including other systems).

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the network access control tool, switch port security configuration, or asset inventory reconciliation showing that only devices on the approved device list are permitted network/system access (e.g., 802.1X authentication success/failure log, NAC quarantine of an unregistered device).

Assessment Guide – Further Discussion

Are account requests authorized before system access is granted [d,e,f]?

AC.L2-3.1.2¶

AC.L2-3.1.2[a]¶

Assessment Objective

the types of transactions and functions that authorized users are permitted to execute are defined

Collection Approach: Document

Potential Evidence Examples

SSP, Access Control Policy, or role/permission matrix (RBAC design document) that enumerates the specific transactions and functions (e.g., read/write/execute, application modules, administrative actions) each user role is permitted to perform.

Assessment Guide – Further Discussion

Are access control lists used to limit access to applications and data based on role and/or identity [a]?

AC.L2-3.1.2[b]¶

Assessment Objective

system access is limited to the defined types of transactions and functions for authorized users.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the role/permission configuration in Active Directory, the application, or the IAM platform showing assigned privileges match the roles defined in the SSP or RBAC matrix, distinguishing privileged from non-privileged accounts, together with a demonstration of a non-privileged user being denied a privileged transaction (e.g., a standard user blocked from an admin menu item).

Assessment Guide – Further Discussion

Is access for authorized users restricted to those parts of the system they are explicitly permitted to use (e.g., a person who only performs word-processing cannot access developer tools) [b]?

AC.L2-3.1.3¶

AC.L2-3.1.3[a]¶

Assessment Objective

information flow control policies are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Information/Data Flow Policy describing how CUI is allowed to move within the network and to external destinations, including the rules that govern the flow (e.g., CUI may only traverse the CUI-enclave VLAN and approved encrypted channels).

AC.L2-3.1.3[b]¶

Assessment Objective

methods and enforcement mechanisms for controlling the flow of CUI are defined.

Collection Approach: Document

Potential Evidence Examples

Document listing the specific enforcement points on the CUI network — firewalls, layer-3 routers/switches, IDS/IPS, DLP, proxy, or email gateway — and describing the mechanism each uses to enforce the information-flow policy (e.g., ACLs, DLP content rules, VLAN segmentation).

AC.L2-3.1.3[c]¶

Assessment Objective

designated sources and destinations (e.g., networks, individuals, and devices) for CUI within systems and between interconnected systems are identified.

Collection Approach: Artifact

Potential Evidence Examples

Network diagram and/or data-flow diagram (including external system interconnections) that labels the authorized sources and destinations for CUI — hosts, subnets/VLANs, or individuals/roles — sufficient to trace where CUI is permitted to originate and terminate, both internally and across system boundaries.

Assessment Guide – Further Discussion

• Are designated sources of regulated data identified within the system (e.g., internal network and IP address) and between interconnected systems (e.g., external networks, IP addresses, ports, and protocols) [c]?
• Are designated destinations of regulated data identified within the system (e.g., internal network and IP address) and between interconnected systems (external networks and IP addresses) [c]?

AC.L2-3.1.3[d]¶

Assessment Objective

authorizations for controlling the flow of CUI are defined.

Collection Approach: Document

Potential Evidence Examples

SSP, network security policy, or interconnection agreement that specifies the authorized source-destination pairings (allow/deny rules) governing CUI flow, e.g., a matrix or policy statement defining which zones, systems, or partners may exchange CUI and under what conditions.

Assessment Guide – Further Discussion

Are authorizations defined for each source and destination within the system and between interconnected systems (e.g., allow or deny rules for each combination of source and destination) [d]?

AC.L2-3.1.3[e]¶

Assessment Objective

approved authorizations for controlling the flow of CUI are enforced.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the live firewall rule base, router ACLs, or DLP policy showing the allow/deny rules from the SSP/policy are actually configured and enforced (e.g., a rule permitting CUI-zone-to-approved-partner traffic and a default-deny rule blocking all other flows), ideally paired with a log entry showing a denied/blocked out-of-policy flow.

Assessment Guide – Further Discussion

Are approved authorizations for controlling the flow of regulated data enforced within the system and between interconnected systems (e.g., traffic between authorized sources and destinations is allowed and traffic between unauthorized sources and destinations is denied) [e]?

AC.L2-3.1.4¶

AC.L2-3.1.4[a]¶

Assessment Objective

the duties of individuals requiring separation to reduce the risk of malevolent activity are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Account Management/Separation-of-Duties Policy identifying the specific functions, roles, or transaction combinations that must be separated because performing them together would create a conflict of interest or excessive privilege (e.g., the same person cannot both request and approve their own access, or administer both the network and the security logging tool that audits it).

Assessment Guide – Further Discussion

Does system documentation identify the system functions or processes that require separation of duties (e.g., function combinations that represent a conflict of interest or an over-allocation of security privilege for one individual) [a]?

AC.L2-3.1.4[b]¶

Assessment Objective

organization-defined duties of individuals requiring separation are separated.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the directory/IAM console showing the roles identified as needing separation are in fact assigned to different individuals (e.g., the network administrator group and the security/audit administrator group have no overlapping membership).

AC.L2-3.1.4[c]¶

Assessment Objective

separate accounts for individuals whose duties and accesses must be separated to reduce the risk of malevolent activity or collusion are established

Collection Approach: Screen Share

Potential Evidence Examples

Live demonstration of the separation being enforced — e.g., the individual who manages security logs cannot log in to network devices to alter ACLs, or the account requester cannot also approve their own request in the ticketing/IAM workflow.

AC.L2-3.1.5¶

AC.L2-3.1.5[a]¶

Assessment Objective

privileged accounts are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Privileged Account Management Policy that defines what constitutes a privileged account (e.g., domain admin, local admin, security-tool admin) paired with a current export of privileged group membership (e.g., AD "Domain Admins"/"Enterprise Admins" membership list) confirming the definition is applied.

Assessment Guide – Further Discussion

Are privileged accounts documented and is when they may be used defined [a]?

AC.L2-3.1.5[b]¶

Assessment Objective

access to privileged accounts is authorized in accordance with the principle of least privilege.

Collection Approach: Artifact

Potential Evidence Examples

Access-request/approval record or least-privilege attestation showing that each privileged account was granted only the minimum permissions needed for the individual's duties (e.g., a scoped admin role rather than full domain admin), along with periodic access-review evidence confirming privileges remain minimized.

Assessment Guide – Further Discussion

Are users assigned privileged accounts to perform their job functions only when it is necessary [b]?

AC.L2-3.1.5[c]¶

Assessment Objective

security functions are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or policy that enumerates the security functions requiring privileged access — e.g., managing access-control configuration, altering system security settings, or maintaining the privileged-account list itself.

Assessment Guide – Further Discussion

Are necessary security functions identified (e.g., access control configuration, system configuration settings, or privileged account lists) that must be managed through the use of privileged accounts [c]?

AC.L2-3.1.5[d]¶

Assessment Objective

access to security functions is authorized in accordance with the principle of least privilege.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of permission settings on the identified security functions/tools (e.g., SIEM administration console, firewall management interface, AD security group management) showing access is restricted to the named privileged accounts only, with a listing of who holds that access.

Assessment Guide – Further Discussion

Is access to privileged functions and security information restricted to authorized employees [d]?

AC.L2-3.1.6¶

AC.L2-3.1.6[a]¶

Assessment Objective

nonsecurity functions are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, Account Management Policy, or Acceptable Use Policy that distinguishes nonsecurity (day-to-day business) functions from security/administrative functions and defines which roles are considered non-privileged.

Assessment Guide – Further Discussion

Are nonsecurity functions and non-privileged roles defined [a,b]?

AC.L2-3.1.6[b]¶

Assessment Objective

users are required to use non-privileged accounts or roles when accessing nonsecurity functions.

Collection Approach: Screen Share

Potential Evidence Examples

Live demonstration showing a privileged (admin) account is blocked from, or not used for, nonsecurity activities such as web browsing or email — for example, admin credentials fail or are refused when used to launch a standard user application, confirming users must switch to a non-privileged account for everyday tasks.

Assessment Guide – Further Discussion

• Are nonsecurity functions and non-privileged roles defined [a,b]?
• Is it required that nonsecurity functions only be accessed with the use of non-privileged accounts? How is this verified [b]?

AC.L2-3.1.7¶

AC.L2-3.1.7[a]¶

Assessment Objective

privileged functions are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Privileged Access Policy that documents which system functions are considered privileged (e.g., system administration, security configuration, audit-log management) and therefore restricted to authorized administrators.

Assessment Guide – Further Discussion

Are the privileged system functions documented (e.g., functions that involve the control, monitoring or administration of the system, including security functions and log management) [a]?

AC.L2-3.1.7[b]¶

Assessment Objective

non-privileged users are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or policy defining which roles/accounts are non-privileged and confirming those roles are excluded from the privileged-function list above.

AC.L2-3.1.7[c]¶

Assessment Objective

non-privileged users are prevented from executing privileged functions.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share/live demonstration of a non-privileged user attempting a privileged action (e.g., installing software, changing a security setting) and being denied by OS/application controls (e.g., UAC prompt requiring admin credentials, application role restriction).

Assessment Guide – Further Discussion

Do documented procedures describe the configuration of the system to ensure system roles do not grant non-privileged users the ability to execute privileged functions [c]?

AC.L2-3.1.7[d]¶

Assessment Objective

the execution of privileged functions is captured in audit logs.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the audit log source (SIEM or native OS/application log) showing that privileged-function execution — including elevation events (e.g., "runas," sudo, UAC approval) — is captured with timestamp and account identity, sufficient to determine who executed a privileged action and when.

Assessment Guide – Further Discussion

• Is it possible to identify who enabled privileges at any particular time [d]?
• Do procedures describe the configuration of system settings to capture the execution of all privileged functions in audit logs [d]?

AC.L2-3.1.8¶

AC.L2-3.1.8[a]¶

Assessment Objective

the means of limiting unsuccessful logon attempts is defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Account Management/Password Policy specifying the organization-defined threshold for consecutive unsuccessful logon attempts and the resulting action (e.g., account lockout after 5 failed attempts for 30 minutes).

Assessment Guide – Further Discussion

Is there a defined threshold for the number of unsuccessful logon attempts for which the system takes action to prevent additional attempts [a]?

AC.L2-3.1.8[b]¶

Assessment Objective

the defined means of limiting unsuccessful logon attempts is implemented.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of the Group Policy Object (or equivalent OS/application/network-device setting) implementing the defined lockout threshold, ideally paired with a test lockout event or log entry showing the control triggered as configured.

Assessment Guide – Further Discussion

Is a mechanism for limiting the number of unsuccessful logon attempts implemented and does it use the defined threshold [b]?

AC.L2-3.1.9¶

AC.L2-3.1.9[a]¶

Assessment Objective

privacy and security notices required by CUI-specified rules are identified, consistent, and associated with the specific CUI category

Collection Approach: Document

Potential Evidence Examples

SSP or Privacy/Security Notice Policy identifying the required logon/consent banner language and any CUI-category-specific notice requirements (e.g., markings or handling notices tied to a particular CUI category authorized by the CUI Registry).

Assessment Guide – Further Discussion

• Are requirements identified for privacy and security notices, and do the implemented practices match those identified requirements [a,b]? Discrepancies may indicate a deficient process and/or an incomplete practice.
• Are there any special requirements associated with the specific CUI category [a]?

AC.L2-3.1.9[b]¶

Assessment Objective

privacy and security notices are displayed.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of the actual logon/consent banner text displayed to users before system access is granted (workstation, VPN, and/or application login screens), and, where applicable, photos of posted physical notices in areas where paper CUI is handled.

Assessment Guide – Further Discussion

Are appropriate notices displayed in areas where paper-based CUI is stored and processed [b]?

AC.L2-3.1.10¶

AC.L2-3.1.10[a]¶

Assessment Objective

the period of inactivity after which the system initiates a session lock is defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Session Management Policy defining the organization-set period of inactivity (e.g., 15 minutes) that triggers a session lock.

Assessment Guide – Further Discussion

If session locks are not managed centrally, how are all computer users made aware of the requirements and how to configure them [a,b,c]?

AC.L2-3.1.10[b]¶

Assessment Objective

access to the system and viewing of data is prevented by initiating a session lock after the defined period of inactivity.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of the Group Policy Object or endpoint-management configuration enforcing the defined inactivity timeout, ideally demonstrated live by allowing a session to sit idle and observing the lock engage at the configured interval.

Assessment Guide – Further Discussion

If session locks are not managed centrally, how are all computer users made aware of the requirements and how to configure them [a,b,c]?

AC.L2-3.1.10[c]¶

Assessment Objective

previously visible information is concealed via a pattern-hiding display after the defined period of inactivity.

Collection Approach: Document

Potential Evidence Examples

Screen share/photo of the lock-screen or screensaver that appears after the inactivity timeout, confirming it conceals previously displayed content (e.g., a generic lock screen with no visible application data) rather than merely dimming or minimizing the screen.

Assessment Guide – Further Discussion

• If session locks are not managed centrally, how are all computer users made aware of the requirements and how to configure them [a,b,c]?
• Does the session lock hide previously visible information (e.g., replacing what was visible with a lock screen or screensaver that does not include sensitive information) [c]?

AC.L2-3.1.11¶

AC.L2-3.1.11[a]¶

Assessment Objective

conditions requiring a user session to terminate are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Session Management Policy defining the conditions that require a user session to terminate (e.g., maximum session duration, defined inactivity period, or explicit logoff requirement).

Assessment Guide – Further Discussion

• Are the conditions in which a user session must be terminated described (e.g., after a period of inactivity or after a defined time limit) [a]?
• Are user sessions terminated based on organizationally defined conditions [a,b]?

AC.L2-3.1.11[b]¶

Assessment Objective

a user session is automatically terminated after any of the defined conditions occur.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the VPN concentrator, RDP/Citrix, or OS Group Policy configuration enforcing automatic session termination at the defined conditions (max connection time, idle timeout), ideally with a log entry showing an automatic disconnect.

Assessment Guide – Further Discussion

Are procedures documented that describe how to configure the system to enable automatic termination of user sessions after any of the defined conditions occur [b]?

AC.L2-3.1.12¶

AC.L2-3.1.12[a]¶

Assessment Objective

remote access sessions are permitted.

Collection Approach: Document

Potential Evidence Examples

SSP or Remote Access Policy stating whether and under what conditions remote access is permitted for the organization.

Assessment Guide – Further Discussion

Do policies identify when remote access is permitted and what methods must be used [a,b]?

AC.L2-3.1.12[b]¶

Assessment Objective

the types of permitted remote access are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Remote Access Policy identifying the approved remote-access methods (e.g., VPN client, VDI, RDP gateway) and prohibiting all other methods.

Assessment Guide – Further Discussion

Do policies identify when remote access is permitted and what methods must be used [a,b]?

AC.L2-3.1.12[c]¶

Assessment Objective

remote access sessions are controlled.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the VPN/remote-access gateway configuration showing remote sessions are restricted to approved users/groups and methods (e.g., default-deny with explicit allow rules, group-based access policies).

Assessment Guide – Further Discussion

Are systems configured to permit only approved remote access sessions (e.g., disallow remote access sessions by default) [c]?

AC.L2-3.1.12[d]¶

Assessment Objective

remote access sessions are monitored.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of remote-access logs (VPN concentrator or SIEM) showing session start/stop, source, and user identity are captured and reviewed, demonstrating active monitoring of remote connections.

Assessment Guide – Further Discussion

Are automated or manual mechanisms employed for monitoring remote connections? If the monitoring is manual, does it occur at a frequency commensurate with the level of risk [d]?

AC.L2-3.1.13¶

AC.L2-3.1.13[a]¶

Assessment Objective

cryptographic mechanisms to protect the confidentiality of remote access sessions are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Cryptographic/Remote Access Policy identifying the specific FIPS-validated cryptographic mechanism used to protect remote-access session confidentiality (e.g., TLS 1.2, IPsec), including the FIPS 140-2/140-3 validation certificate number for the module (software or hardware) implementing it — not just the algorithm name.

Assessment Guide – Further Discussion

• Are cryptographic mechanisms used for remote access sessions (e.g., Transport Layer Security (TLS) and Internet Protocol Security (IPSec) using FIPS-validated encryption algorithms) defined and implemented [a,b]?
• Note that simply using an approved algorithm is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140.

AC.L2-3.1.13[b]¶

Assessment Objective

cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the VPN concentrator or remote-access gateway configuration showing the FIPS-validated cryptographic module/mode is enabled and enforced for all remote sessions (e.g., "FIPS mode" toggled on, cipher suite restricted to FIPS-approved algorithms).

Assessment Guide – Further Discussion

• Are cryptographic mechanisms used for remote access sessions (e.g., Transport Layer Security (TLS) and Internet Protocol Security (IPSec) using FIPS-validated encryption algorithms) defined and implemented [a,b]?
• Note that simply using an approved algorithm is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140.

AC.L2-3.1.14¶

AC.L2-3.1.14[a]¶

Assessment Objective

managed access control points are identified and implemented.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share/network diagram identifying each managed access control point (e.g., VPN concentrator, remote-access gateway, jump box) through which remote connections must pass, and how many exist in the environment.

Assessment Guide – Further Discussion

How many managed access control points are implemented [a]?

AC.L2-3.1.14[b]¶

Assessment Objective

remote access is routed through managed network access control points.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of firewall/routing configuration or network diagram demonstrating that remote-access traffic has no path into the environment except through the identified managed access control points (i.e., no bypass routes).

Assessment Guide – Further Discussion

Is all remote access routed through the managed access control points [b]?

AC.L2-3.1.15¶

AC.L2-3.1.15[a]¶

Assessment Objective

privileged commands authorized for remote execution are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Remote Administration Policy listing which privileged/administrative commands are authorized to be executed remotely and the operational justification for allowing remote execution of each.

Assessment Guide – Further Discussion

Does system documentation identify system administration or security functions that can be executed remotely [a]?

AC.L2-3.1.15[b]¶

Assessment Objective

security-relevant information authorized to be accessed remotely is identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Remote Administration Policy identifying which categories of security-relevant information (e.g., audit logs, security configuration data) may be accessed remotely and by whom.

AC.L2-3.1.15[c]¶

Assessment Objective

the execution of the identified privileged commands via remote access is authorized.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of group/role membership (e.g., AD security group for remote administrators) showing that only individuals with documented operational need can execute the identified privileged commands remotely, ideally paired with a remote-session log showing a privileged command execution tied to an authorized account.

Assessment Guide – Further Discussion

Is execution of the identified privileged commands via remote access only authorized for documented operational needs [c]?

AC.L2-3.1.15[d]¶

Assessment Objective

access to the identified security-relevant information via remote access is authorized.

Collection Approach: Artifact

Potential Evidence Examples

Screen share of access permissions on the identified security-relevant information/systems showing remote access is limited to authorized personnel, plus remote-access routing evidence (e.g., jump box or VPN logs) showing how and from where that access occurs.

AC.L2-3.1.16¶

AC.L2-3.1.16[a]¶

Assessment Objective

wireless access points are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Wireless Network documentation listing every authorized wireless access point (AP) by location, SSID, and controller, kept current as an inventory.

Assessment Guide – Further Discussion

Is an updated list of approved network devices providing wireless access to the system maintained [a]?

AC.L2-3.1.16[b]¶

Assessment Objective

wireless access is authorized prior to allowing such connections.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the Wireless LAN Controller (WLC) or NAC (e.g., Cisco ISE) authentication profile showing devices/users must be authorized (e.g., 802.1X, certificate, or MAC authentication) before a wireless connection is granted.

Assessment Guide – Further Discussion

• Are network devices providing wireless access configured to require users or devices be authorized prior to permitting a wireless connection [b]?
• Is wireless access to the system authorized and managed [b]?

AC.L2-3.1.17¶

AC.L2-3.1.17[a]¶

Assessment Objective

wireless access to the system is protected using encryption.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the WLC security settings showing wireless clients must authenticate (e.g., WPA2/WPA3-Enterprise with 802.1X, or a restricted pre-shared key) before connecting; if a PSK is used, evidence that access to the key is limited to authorized personnel (e.g., key distribution/rotation record).

Assessment Guide – Further Discussion

• Is wireless access limited only to authenticated and authorized users (e.g., required to supply a username and password) [a]?
• If the organization is securing its wireless network with a pre-shared key, is access to that key restricted to only authorized users [a]?

AC.L2-3.1.17[b]¶

Assessment Objective

wireless access to the system is protected using authentication.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the WLC encryption settings showing FIPS-validated cryptography (e.g., AES via WPA2/WPA3 in FIPS mode) protects wireless traffic, including the FIPS 140-2/140-3 certificate number for the module in use — the algorithm name alone (e.g., "AES") is not sufficient.

Assessment Guide – Further Discussion

• Is wireless access encrypted using FIPS-validated cryptography [b]?
• Note that simply using an approved algorithm is not sufficient; the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140.

AC.L2-3.1.18¶

AC.L2-3.1.18[a]¶

Assessment Objective

mobile devices that process, store, or transmit CUI are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Mobile Device Policy maintaining a current inventory of mobile devices authorized to process, store, or transmit CUI (e.g., MDM-enrolled device list).

Assessment Guide – Further Discussion

Is a list of mobile devices that are permitted to process, store, or transmit CUI maintained [a,b]?

AC.L2-3.1.18[b]¶

Assessment Objective

the connection of mobile devices is authorized.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the MDM or NAC console showing only devices on the authorized inventory can enroll/connect (e.g., device-certificate or compliance-based conditional access), with an example of an unauthorized/non-compliant device being blocked.

Assessment Guide – Further Discussion

• Is a list of mobile devices that are permitted to process, store, or transmit CUI maintained [a,b]?
• Is the system configured to only permit connections from identified, authorized mobile devices [b]?

AC.L2-3.1.18[c]¶

Assessment Objective

mobile device connections are monitored and logged.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of MDM connection/compliance logs feeding a SIEM (or log-source configuration showing the MDM as an ingested source), demonstrating mobile-device connections are actively logged and monitored.

AC.L2-3.1.19¶

AC.L2-3.1.19[a]¶

Assessment Objective

mobile devices and mobile computing platforms that process, store, or transmit CUI are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Mobile Device Policy maintaining a current inventory of mobile devices and mobile computing platforms (e.g., laptops, tablets, smartphones) authorized to process, store, or transmit CUI.

Assessment Guide – Further Discussion

Is a list maintained of mobile devices and mobile computing platforms that are permitted to process, store, or transmit CUI [a]?

AC.L2-3.1.19[b]¶

Assessment Objective

encryption is employed to protect CUI on identified mobile devices and mobile computing platforms.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the MDM encryption policy (or native device FIPS-validated encryption settings, e.g., BitLocker, FileVault in FIPS mode) showing CUI on identified mobile devices is encrypted using a FIPS-validated algorithm/module, citing the applicable FIPS certificate.

Assessment Guide – Further Discussion

Is CUI encrypted on mobile devices using FIPS-validated algorithms [b]?

AC.L2-3.1.20¶

AC.L2-3.1.20[a]¶

Assessment Objective

connections to external systems are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, network diagram, or Interconnection Security Agreement (ISA)/MOU listing every connection to systems outside the assessment boundary (e.g., cloud services, partner networks, contractor systems).

Assessment Guide – Further Discussion

Are all connections to external systems outside of the assessment scope identified [a]?

AC.L2-3.1.20[b]¶

Assessment Objective

use of external systems is identified.

Collection Approach: Document

Potential Evidence Examples

SSP or policy identifying which external systems (contractor-, partner-, or vendor-managed systems; personal devices) are permitted to connect to or use organizational systems, and under what conditions.

Assessment Guide – Further Discussion

Are external systems (e.g., systems managed by contractors, partners, or vendors; personal devices) that are permitted to connect to or make use of organizational systems identified [b]?

AC.L2-3.1.20[c]¶

Assessment Objective

connections to external systems are verified.

Collection Approach: Artifact

Potential Evidence Examples

Evidence confirming authorized-connection requirements are enforced for each external system — e.g., an ISA/MOU or SLA, and, for cloud services, proof of at least a FedRAMP Moderate (or DoD-equivalent) authorization such as a FedRAMP Marketplace listing, ATO letter, or provider attestation.

Assessment Guide – Further Discussion

Are methods employed to ensure that only authorized connections are being made to external systems (e.g., requiring log-ins or certificates, access from a specific IP address, or access via Virtual Private Network (VPN)) [c,e]?

AC.L2-3.1.20[d]¶

Assessment Objective

use of external systems is verified.

Collection Approach: Artifact

Potential Evidence Examples

Evidence that the organization actively verifies external-system connections are authorized and expected — e.g., a periodic review of connected devices/systems, an inventory reconciliation report, or MDM/NAC compliance check results for BYOD or partner-owned endpoints.

Assessment Guide – Further Discussion

Are methods employed to confirm that only authorized external systems are connecting (e.g., if employees are receiving company email on personal cell phones, is the contractor checking to verify that only known/expected devices are connecting) [d]?

AC.L2-3.1.20[e]¶

Assessment Objective

connections to external systems are controlled/limited.

Collection Approach: Screen Share

Potential Evidence Examples

Screen share of the firewall rule set or cloud security-group configuration restricting connections to/from external systems to only the authorized endpoints, protocols, and ports.

Assessment Guide – Further Discussion

Are methods employed to ensure that only authorized connections are being made to external systems (e.g., requiring log-ins or certificates, access from a specific IP address, or access via Virtual Private Network (VPN)) [c,e]?

AC.L2-3.1.20[f]¶

Assessment Objective

use of external systems is controlled/limited.

Collection Approach: Screen Share

Potential Evidence Examples

Policy statement and/or technical control (e.g., firewall/DLP rule, MDM restriction) showing organizational use of external systems is limited — for example, prohibiting storage of CUI on personal cloud accounts, enforced through both written policy and a technical control.

Assessment Guide – Further Discussion

Is the use of external systems limited, including by policy or physical control [f]?

AC.L2-3.1.21¶

AC.L2-3.1.21[a]¶

Assessment Objective

use of organizational portable storage devices containing CUI on external systems is identified and documented.

Collection Approach: Document

Potential Evidence Examples

SSP, Removable Media Policy, or Acceptable Use Policy that identifies which portable storage devices (e.g., organization-issued encrypted USB drives) are authorized for use with external systems, and documents that authorization.

Assessment Guide – Further Discussion

Are the portable storage devices authorized for external use identified and documented [a]?

AC.L2-3.1.21[b]¶

Assessment Objective

limits on the use of organizational portable storage devices containing CUI on external systems are defined.

Collection Approach: Document

Potential Evidence Examples

SSP or Removable Media Policy defining the specific circumstances under which CUI-containing portable storage devices may be used on external systems (e.g., management pre-approval required) and any conditions attached (e.g., mandatory encryption, authorized personnel only).

Assessment Guide – Further Discussion

• Are the circumstances defined in which portable storage devices containing CUI may be used on external systems (e.g., with management approval) [b]?
• Are limitations stipulated for the use of portable storage devices containing CUI on external systems (e.g., authorized personnel only, encrypted drives required) [b]?

AC.L2-3.1.21[c]¶

Assessment Objective

use of organizational portable storage devices containing CUI on external systems is limited as defined.

Collection Approach: Document

Potential Evidence Examples

Evidence that the defined limitations are actually followed — e.g., a device check-out/authorization log, encryption-enforcement configuration on approved USB drives (e.g., BitLocker To Go policy), or a sampled approval record for an external-use portable device.

AC.L2-3.1.22¶

AC.L2-3.1.22[a]¶

Assessment Objective

individuals authorized to post or process information on publicly accessible systems are identified.

Collection Approach: Document

Potential Evidence Examples

SSP, Website Governance Plan, or Public Release Policy identifying by name or role the individuals authorized to post/process information on publicly accessible systems (e.g., public website, social media).

AC.L2-3.1.22[b]¶

Assessment Objective

procedures to ensure CUI is not posted or processed on publicly accessible systems are identified.

Collection Approach: Document

Potential Evidence Examples

SSP or Website Governance/Public Release Policy describing the procedures used to prevent CUI from being posted or processed on publicly accessible systems (e.g., mandatory pre-publication review checklist).

AC.L2-3.1.22[c]¶

Assessment Objective

a review process is in place prior to posting of any content to publicly accessible systems.

Collection Approach: Artifact

Potential Evidence Examples

Sampled evidence of the pre-posting approval workflow (e.g., email approval chain, ticket, or SharePoint request/approval record) showing content was reviewed and approved before being published to a public-facing system.

Assessment Guide – Further Discussion

Does information on externally facing systems (i.e., publicly accessible) have a documented approval chain for public release [c]?

AC.L2-3.1.22[d]¶

Assessment Objective

content on publicly accessible information systems is reviewed to ensure that it does not include CUI.

Collection Approach: Artifact

Potential Evidence Examples

Sampled evidence that already-published public content is periodically reviewed for inadvertent CUI exposure — e.g., a web-content audit log, review checklist, or change-log entry documenting the review and its outcome.

AC.L2-3.1.22[e]¶

Assessment Objective

mechanisms are in place to remove and address improper posting of CUI.

Collection Approach: Artifact

Potential Evidence Examples

Incident Response SOP or web-change SOP describing how improperly posted CUI is identified, removed, and remediated, ideally supported by an example of a past corrective action (e.g., takedown ticket) if one has occurred.