CMMC NUGGET #10

System Identity & Access Management

AC.L2-3.1.1: Limit system access to authorized users, processes, and devices

This is the foundational access control requirement. Your IAM program must ensure that only authorized users, processes acting on their behalf, and approved devices can access organizational systems. Implementation requires:

• A documented list of authorized users and devices for each system
• Technical enforcement preventing unauthorized users from gaining access
• Processes for provisioning and deprovisioning access as personnel join, change roles, or leave

AC.L2-3.1.2: Restrict access to authorized transactions and functions

Users should only be able to execute the transactions and access the functions their role requires. RBAC is the standard implementation mechanism. Roles must be defined based on actual job requirements, documented, and enforced through system permissions rather than informal agreement.

AC.L2-3.1.3: Control the flow of CUI in accordance with approved authorizations

This control is broader than IAM alone and is one of the most commonly under implemented controls in the AC family. CUI flow control means restricting not just who can access CUI but where CUI can go once accessed. IAM addresses the identity component, but organizations must also implement:

• Data Loss Prevention (DLP) tools or policies preventing CUI from being sent to unauthorized destinations
• Email filtering rules preventing CUI from being forwarded to personal accounts
• Restrictions on copying CUI to removable media or unauthorized cloud storage
• Documentation in the SSP of all approved CUI flows within and outside the assessment boundary

Assessor Reality Check: Assessors evaluate AC.L2-3.1.3 well beyond user authentication. They will ask how your organization prevents CUI from flowing to unauthorized destinations after an authorized user accesses it. RBAC alone does not satisfy this control.

AC.L2-3.1.6: Use non-privileged accounts for non-security functions

Users with privileged accounts must use separate standard accounts for day-to-day activities such as email, web browsing, and general productivity work. Privileged accounts are used exclusively for tasks requiring elevated access. This requirement applies to system administrators, IT personnel, and any other users with elevated privileges. Document which accounts are privileged, who holds them, and what activities they are authorized for.

IA.L2-3.5.1: Identify system users, processes, and devices

Every entity interacting with your systems must be uniquely identified. This means:

• No shared accounts for human users. Every individual must have their own unique account
• Service accounts and automated processes must be uniquely identified and documented
• Devices within the CUI environment must be identified and inventoried
• Actions must be attributable to specific identified entities for audit purposes

IA.L2-3.5.2: Authenticate users, processes, and devices before allowing access

Authentication is the verification that an entity is who or what it claims to be. IAM systems must verify identity before granting access through mechanisms appropriate to the sensitivity of the resource. Password-only authentication is the minimum for local accounts with non-privileged access. MFA is required for privileged access and network access to all accounts under IA.L2-3.5.3.

IA.L2-3.5.3: Use multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts

This is the single most impactful IA control in the entire CMMC framework and one of the most commonly failed. MFA requires verification through at least two independent factors:

• Something you know (password, PIN)
• Something you have (authenticator app, hardware token, smart card)
• Something you are (biometric)

The full scope of IA.L2-3.5.3 covers:

• Local AND network access to privileged accounts: MFA is required whether the administrator is sitting at the console or connecting remotely
• Network access to non-privileged accounts: all standard users must use MFA when accessing systems over the network, not just administrators

Assessor Reality Check: Partial MFA implementation is one of the most common findings in this domain. Organizations that enforce MFA for remote access but not for local privileged access, or that enforce MFA for administrators but not for general network users, have an incomplete implementation that assessors will specifically probe.

CM.L2-3.4.9: Control and monitor user-installed software

Covered in depth in Nugget #9, but relevant here because IAM directly enables this control. By managing user privilege levels through your IAM program, you can technically prevent standard users from installing software without administrator approval. User privilege configuration is an IAM function. The monitoring and alerting component must be implemented separately through endpoint management tooling.

A compliant IAM program must manage identities through every phase of their existence:

The controls covered in this nugget span the AC, IA, and CM families. Each must be documented under its respective section in your SSP. For IAM specifically, your SSP should describe:

• Your IAM platform or toolset and how it enforces access policies
• Your RBAC structure and how roles are defined and assigned
• Your MFA implementation including which systems, which account types, and how exceptions are managed
• Your identity lifecycle process from provisioning through deprovisioning
• How CUI flow controls beyond authentication are implemented (for AC.L2-3.1.3)

For assistance implementing a compliant IAM framework, configuring MFA across your environment, or documenting IAM controls in your SSP, contact DTC’s C3PAO team.