3.1.1 — Who Gets In

The One-Liner

If you can’t name every person and device that can access your CUI systems right now, you fail this requirement.

What It Says

Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).

What It Actually Means

You need three lists, and they need to be current:

1. Every person who can log into your CUI systems — by name, not by team
2. Every automated process (scheduled tasks, service accounts, API connections) — each one tied to a person who owns it
3. Every device (workstations, phones, servers, printers) — each one approved and tracked

No shared logins. No mystery service accounts. No random laptops connecting to the network.

When someone leaves, their access dies the same day. When a device is decommissioned, it comes off the list. This is the foundation — everything else in Access Control builds on it.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are your authorized users identified?	A maintained list — not a stale spreadsheet from last year
2	Are your authorized processes identified?	Service accounts documented with an owner’s name
3	Are your authorized devices identified?	A device inventory from MDM or asset management
4	Is access actually limited to those users?	Unauthorized people can’t log in — prove it
5	Is access actually limited to those processes?	No rogue scripts or forgotten cron jobs
6	Is access actually limited to those devices?	Unregistered devices get blocked, not just logged

---

What to Have Ready on Assessment Day

Documents they’ll review: Access control policy, account list with names, authorized device list, recent termination records, disabled account records, system audit logs

People they’ll talk to: Whoever manages accounts, your sysadmins, your security lead

Live demos they’ll ask for: “Show me how you create an account.” “Show me what happens when someone leaves.” “Plug in an unauthorized device — show me it’s blocked.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me your list of authorized users. How do you know it’s current?”
• “Walk me through what happens when someone leaves the company.”
• “How do you prevent unauthorized devices from connecting?”
• “Show me a recent example of a disabled account after a termination.”
• “Who owns this service account? What does it do?”

Real-World Example

A 60-person defense sub runs their user list out of Entra ID. When HR enters a termination in BambooHR, an automated workflow disables the Entra account, revokes VPN access, and wipes the MDM-managed device — all within 30 minutes. The IT manager reviews the disabled account list weekly. Devices are enrolled through Intune; anything not enrolled gets blocked by Conditional Access.

That’s what “yes” looks like for all six questions.

---

Where Companies Trip Up

Shared accounts. “admin@company.com” used by three people. The assessor will ask who performed a specific action, and you won’t be able to answer.

Ghost accounts. Former employees still in Active Directory months after leaving. Run a quarterly access review — compare your user list against HR’s active employee list.

Orphan service accounts. That SQL service account from 2019 that nobody remembers creating. Every automated process needs a documented owner.

No device inventory. You know your users but you can’t list every device on the network. Your MDM or asset management tool is the answer.

---

How to Talk About This

To a CEO or Board

We can show exactly who has access to our CUI systems, when they were approved, and by whom. When someone leaves, access is revoked the same day. No orphaned accounts, no shared logins, no unmanaged devices.

To an Engineering Team

Every identity — human and service — is tracked in our IdP. Device trust is enforced through MDM compliance. Offboarding triggers automated deprovisioning. The device inventory is always current because it’s pulled from the MDM, not a spreadsheet.

---

Connected Requirements

Requirement	Why it matters here
3.5.1 — Prove Who You Are	Gives you the identity foundation this control depends on
3.5.2 — Verify Before Entry	Verifies identity before granting the access you control here
3.1.2 — What They Can Do	Once someone’s in, this limits what they can do
3.9.2 — When People Leave	The offboarding process that feeds this control

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: AC.L2-3.1.1 | SPRS Weight: 5 points | POA&M Eligible: No