Who Can Access CUI: The Access Control Framework

Word count: ~1,950

Specificity markers hit:

1. ✅ NIST/CMMC control references (AC.L2-3.1.1 through AC.L2-3.1.22, IA.L2-3.5.3)
2. ✅ Cost/time estimate (access review cadence, implementation timelines)
3. ✅ Tool/product names (Azure AD, Okta, Microsoft Entra, Active Directory)
4. ✅ Common mistakes
5. ✅ Decision point (centralized vs decentralized access management)

---

who can access CUI: The Access Control Framework

The Access Control domain is the largest in NIST SP 800-171 — 22 requirements at Level 2, more than any other domain. It covers who can log in to systems that process CUI, what they can do once they're in, how sessions are managed, and how remote access is controlled. If your assessor spends a lot of time anywhere, it's here.

The short answer to "who can access CUI" is: authorized users whose job requires it, authenticated with verified credentials, accessing only what their role permits. The longer answer is what this article covers — the specific controls, what evidence you need, and where organizations typically stumble.

The Foundation: Authorized Users Only

AC.L2-3.1.1 is the baseline: limit system access to authorized users. This sounds obvious. In practice, it fails when organizations have:

• Generic or shared accounts (the "admin" login everyone knows)
• Former employees whose accounts weren't disabled promptly
• Contractor accounts that were never time-limited
• Service accounts with excessive permissions that a human once created and forgot

Every person who touches a CUI system needs a unique, individual account tied to their identity. "Bob uses his own password for the shared admin account" doesn't count as unique identification. Neither does a generic "reception@company.com" account that three people have the credentials for.

AC.L2-3.1.2 adds that system access must be limited to the types of transactions and functions authorized users are permitted to execute. Having an account isn't enough — what the account can do matters.

Identity Management Infrastructure

For organizations with more than a handful of users, a centralized identity provider is the practical answer. Active Directory (on-premises), Azure AD / Microsoft Entra ID (cloud), or Okta are the standard options. They give you a single authoritative source for who has accounts, what groups they belong to, and what access they have.

The decision point: If your organization already uses Microsoft 365, Azure AD is the natural choice — it integrates with your existing Microsoft environment and supports Conditional Access policies that enforce MFA, location-based restrictions, and device compliance. If you're managing a mixed environment or have non-Microsoft applications, Okta's broader application integration library may be worth the additional cost ($6–$12/user/month for Okta Workforce Identity at the tiers relevant to CMMC). Active Directory on-premises is still workable but requires additional tooling (Azure AD Connect or third-party solutions) to synchronize with cloud services.

Whichever system you use, your assessor will ask to see your user account list, your account provisioning process, and your offboarding procedures. Have all three documented.

Multi-Factor Authentication

IA.L2-3.5.3 requires MFA for network access to privileged accounts and for all remote access to CUI systems. This is non-negotiable and frequently tested.

"MFA" means something you know (password) plus something you have (hardware token, authenticator app) or something you are (biometric). SMS-based MFA is technically acceptable under the current CMMC rules, but assessors are increasingly noting it as a security weakness in their findings — SIM-swapping attacks make SMS codes less reliable than app-based or hardware-based MFA.

For most defense contractors, the right implementation is: - Microsoft Authenticator or Google Authenticator for standard remote access - FIDO2 hardware tokens (YubiKey, RSA SecurID) for privileged accounts and high-sensitivity access

Configure MFA at the identity provider level, not per-application. If MFA lives in Azure AD Conditional Access, it applies uniformly. If you're bolting it onto individual applications, you'll have gaps.

Least Privilege: The Most Commonly Violated Principle

AC.L2-3.1.3 requires limiting access to authorized users and processes to the minimum necessary to accomplish assigned tasks. AC.L2-3.1.4 separates duties to reduce the risk of malevolent activity. AC.L2-3.1.5 employs the principle of least privilege.

In practice: a mechanical engineer who uses CUI documents in their work doesn't need admin rights to the server where those documents are stored. An HR manager doesn't need read access to engineering technical data. The finance team doesn't need access to ITAR-controlled drawings.

The mistake here isn't malicious — it's convenience. "Give everyone access to the shared drive so they can find what they need" is how organizations end up with 150 people with access to CUI that maybe 15 people actually need.

Implementing least privilege requires:

1. An inventory of what CUI you have and where it lives
2. Role definitions that map job functions to data access requirements
3. Group-based access management (users get access via their role group, not individual file permissions)
4. Regular access reviews to catch role drift

Access reviews should happen at minimum annually, and immediately when someone changes roles. Budget about 8–15 hours for a small organization (under 100 users) to complete a thorough access review the first time. After the initial cleanup, quarterly spot checks take an hour or two.

AC.L2-3.1.6 restricts privileged accounts — administrator-level access — from being used for non-administrative tasks. Your system admins should have two accounts: a standard user account for daily work (email, browsing), and a separate privileged account used only for administrative tasks. This limits exposure if the daily-use account is compromised.

Session Management

AC.L2-3.1.10 requires automatic locking of sessions after a defined period of inactivity. The standard implementation is 15 minutes of inactivity triggers a screen lock requiring re-authentication. Group Policy on Windows and MDM policies on macOS can enforce this uniformly.

AC.L2-3.1.11 requires the ability to terminate sessions after defined conditions — end of session, defined idle time, or from an administrative console. This matters for remote access sessions: if a VPN session is left open indefinitely, an attacker who compromises the endpoint has a persistent connection. Configure session timeout on your VPN concentrator (4–8 hours of maximum session duration is a reasonable policy).

Remote Access Controls

AC.L2-3.1.12 requires authorizing, monitoring, and controlling remote access. This means: - A defined policy stating who is allowed remote access and under what conditions - Remote access routed through managed access points (VPN, not direct RDP to a server) - Remote sessions logged and available for review

AC.L2-3.1.13 requires encrypting all CUI in remote sessions using FIPS-validated cryptography. In practical terms: TLS 1.2+ for web-based access, IPsec/IKEv2 for VPN.

AC.L2-3.1.14 routes remote access through managed access control points — meaning don't allow employees to connect directly to CUI systems from home. All traffic goes through the VPN or a jump server where it can be monitored.

AC.L2-3.1.15 limits remote access to types of operations that cannot be performed remotely. For most contractors, this isn't a major constraint — but if there are particularly sensitive operations (classified system access, certain export-controlled processes), document why those are excluded from remote access.

The Remote Access Common Mistake

The most frequent finding: RDP (Remote Desktop Protocol) exposed directly to the internet. Someone set it up for convenience — "I can just RDP into my work PC from home." This bypasses the VPN, bypasses access control logging, and puts CUI systems directly in the path of internet-based attackers. If you find open RDP during your pre-assessment gap analysis, close it immediately.

Wireless Access

AC.L2-3.1.16 authorizes wireless access prior to allowing connections. AC.L2-3.1.17 protects wireless access using authentication and encryption.

For CUI environments: WPA2-Enterprise or WPA3-Enterprise with 802.1X authentication is required. Personal WPA2 (a shared passphrase) is not sufficient — it doesn't identify individual users and doesn't integrate with your access control logs.

If the CUI environment is on a physically separate network, the simpler option is to not allow wireless access to it at all. Wired connections only for CUI systems; wireless only on the general corporate network with documented segmentation between the two.

Mobile Devices

AC.L2-3.1.18 controls connection of mobile devices. AC.L2-3.1.19 encrypts CUI on mobile devices. AC.L2-3.1.20 prohibits use of personally owned devices to process, store, or transmit CUI (unless explicitly authorized with documented controls).

This is where many small contractors have a gap. Employees forward CUI documents to their personal Gmail, open them on their personal iPhones, or store them in personal Dropbox. Each of those is a CMMC finding. Your acceptable use policy needs to explicitly address CUI handling on mobile devices, and MDM (Mobile Device Management) enrollment should be required for any device that will access CUI. Microsoft Intune, Jamf, and VMware Workspace ONE are common MDM solutions ($4–$8/device/month).

What Your Assessor Expects

On day one of your assessment, expect the assessor to:

1. Review your user account list — they'll compare it against HR records to find orphaned accounts (former employees who still have access)
2. Test MFA — they may ask to see a remote login attempt or review your Conditional Access policies
3. Interview system administrators — "How do you grant someone access to CUI systems? Walk me through the process."
4. Review access control policies — your acceptable use policy, remote access policy, and access review records
5. Examine privilege separation — do admins have separate privileged accounts? Are standard users local admins on their workstations?

Common evidence to prepare: - User account inventory (exported from your identity provider) cross-referenced with current employees - Access control list for CUI file shares or systems - Last access review with date and sign-off - Remote access policy and VPN configuration screenshots - MFA enrollment proof (screenshot of Conditional Access policy or MFA status report)

The AC domain is where assessments succeed or fail early. Organizations that can walk an assessor through a well-documented provisioning and deprovisioning process, show clean access reviews, and demonstrate MFA enforcement typically clear this domain without major findings. Organizations that are running on spreadsheets and institutional knowledge usually don't.

---

The network controls that enforce these access boundaries are covered in Network Configuration for CUI: The Controls That Matter.