CMMC Level 2 Practice 3.1.1: Limit system access to authorized users, processes acting on behalf of authorized users, and

CMMC Level 2 Practice 3.1.1 requires you to prevent any system access except by explicitly authorized users and explicitly authorized “processes acting on behalf of users” (service accounts, scheduled tasks, application identities). Operationalize it by defining an authorization standard, enforcing it through IAM and system configuration, and proving it with access inventories, approvals, and audit logs mapped to your CUI environment. ¹

Key takeaways:

• Scope the rule to the CUI environment and its boundary, then control access at the identity, system, and application layers. ²
• “Processes acting on behalf of authorized users” must be treated like identities with ownership, least privilege, and lifecycle controls. ¹
• Evidence wins assessments: access lists, provisioning tickets, account reviews, and logs that show enforcement. ³

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2, and Practice 3.1.1 is one of the controls assessors use to quickly determine whether you run disciplined access governance or rely on informal admin habits. The requirement sounds simple (“limit access”), but most findings come from gaps in operational details: shared admin accounts, service accounts no one owns, “temporary” access that never expires, and systems joined to directories without clear group-based authorization.

Treat 3.1.1 as a gate: every path into your CUI environment must require an authorized identity (human or non-human), and every identity must have a documented reason to exist, a defined privilege set, and a lifecycle. Your goal is not just to be secure; it is to be explainable under assessment. CMMC assessments are evidence-driven, and you should expect the assessor to ask, “Show me who is authorized, who approved it, how it’s enforced, and how you know it stays that way.” ²

This page gives requirement-level implementation steps you can hand to IT and security operators, plus the artifacts you need to retain so you can pass a CMMC Level 2 assessment without scrambling.

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.1 (Limit system access to authorized users, processes acting on behalf of authorized users, and).” ¹

What the operator must do:
You must ensure systems that store, process, or transmit CUI only allow access by:

1. authorized users (human identities), and
2. authorized processes acting for those users (non-human identities such as service accounts, app registrations, agents, scheduled tasks).
   Practically, this means you define authorization rules, implement them in IAM and system configs, and continuously prevent and detect unauthorized accounts, sessions, and application-to-application access. ¹

Plain-English interpretation (what this really means)

• No anonymous access. If a system can be reached, it must require an identity that is known and approved.
• No “it works so we kept it” accounts. Every account or token must have an owner, a purpose, and an approval trail.
• Non-human access counts. If a script connects to a database or an agent pulls files, that “process” needs the same governance as a person: provisioning, least privilege, monitoring, and removal when no longer needed. ¹

A good internal test: if you cannot answer “who approved this identity and why does it exist?” you do not meet the intent of 3.1.1.

Who it applies to (entity and operational context)

Entities: Defense contractors and federal contractors handling CUI who are seeking or maintaining CMMC Level 2. ³

Operational context and scope boundaries:

• Applies to the CUI environment (systems, networks, apps, endpoints, and identity providers within the defined boundary).
• Includes on-prem, cloud, and SaaS components where CUI is stored, processed, or transmitted, plus supporting infrastructure that grants access (IdP, PAM, directory services). ²

If your boundary definition is sloppy, 3.1.1 becomes hard to prove. Your access control story must match your documented scope.

What you actually need to do (step-by-step)

Step 1: Create a “control card” for 3.1.1 (owner, triggers, exceptions)

Write a one-page runbook that answers:

• Control owner (IT/security role, named team)
• Systems in scope (tie to the CUI boundary)
• Trigger events (new hire, role change, termination, new system, new integration)
• Standard access paths (SSO, VPN, privileged access method)
• Exception rules (break-glass, emergency changes) and how they’re approved This is the artifact assessors implicitly expect when they ask, “Walk me through how access is granted.” ³

Step 2: Define “authorized” in a way engineers can implement

Document minimum authorization criteria:

• Identity proofing standard (HR feed, contract verification for third parties)
• Approval authority (manager + system owner, or data owner for CUI systems)
• Least privilege rule (role-based groups; deny-by-default where possible)
• Authentication baseline (tie to your broader access control policy set) Keep it short and enforceable. A long policy that isn’t implemented fails in assessment.

Step 3: Inventory access paths and identities (human + non-human)

Build and maintain these inventories for in-scope systems:

• Human identities: directory users, local accounts, privileged accounts, third-party accounts
• Non-human identities: service accounts, API keys, OAuth app registrations, certificates, shared mailboxes used for automation, RPA bots
• Access paths: VPN, bastion hosts, RDP/SSH, SaaS admin portals, CI/CD runners, device management tools Your inventory becomes the backbone for evidence (what exists) and operations (what must be controlled). ¹

Step 4: Enforce authorization at the directory and system layers

Operators should implement:

• Centralized identity where feasible (SSO/IdP) for in-scope apps
• Group-based authorization for systems and applications (avoid direct user-to-resource grants)
• Disable/ban shared accounts except approved break-glass with strict controls
• Remove local admin by default; grant via controlled workflows
• Default-deny for network access to administrative interfaces (allow lists, jump hosts) This is where 3.1.1 becomes real: configuration prevents unauthorized access even if someone knows a password or finds an exposed service.

Step 5: Treat “processes acting on behalf of users” as first-class identities

For each non-human identity, require:

• Named business owner and technical owner
• Defined purpose (system-to-system integration, backup job, monitoring agent)
• Least privilege permissions and scoped secrets
• Credential storage standard (secrets manager, certificate management)
• Rotation / expiry expectation aligned to your engineering reality (set a rule you can follow)
• Deprovision trigger (app retired, integration replaced, owner leaves) Assessors regularly probe service accounts because they are common escalation paths. ¹

Step 6: Operationalize lifecycle: provisioning, changes, deprovisioning

Build an access workflow that produces traceable records:

• Request (ticket), approval, implementation evidence, and closure
• Immediate termination handling (disable accounts, revoke sessions/tokens, remove group memberships)
• Periodic access review process for in-scope systems (cadence is your choice; pick one you can sustain) Your workflow should cover employees and third parties. “Authorized” means you can show the authorization happened and is still valid. ³

Step 7: Monitor and prove enforcement (control health checks)

Minimum monitoring outcomes:

• Alert on new privileged accounts, new service principals, new API keys, disabled MFA (if used), and anomalous logins to in-scope systems
• Periodic reconciliation: inventory vs directory vs system local accounts
• Track remediation items to closure with a clear owner and due date This turns 3.1.1 from a one-time setup into an operating control. ²

Where Daydream fits (earned, not bolted-on)

If you struggle to keep “who owns the control, what evidence is required, and whether it ran” straight across multiple systems, Daydream can host the 3.1.1 control card, define the minimum evidence bundle, and track recurring control health checks to closure so you can respond to assessors with a consistent packet instead of a scavenger hunt. ³

Required evidence and artifacts to retain (minimum evidence bundle)

Keep evidence tied to the CUI boundary and the assessment period:

• Access control policy / standard defining authorization requirements for in-scope systems. ¹
• System access lists (exports/screenshots) showing group membership or role assignments for key systems in scope.
• Provisioning records (tickets/requests) with approvals for new access and privilege changes.
• Deprovisioning records for terminations and third-party offboarding (request + completion proof).
• Service account register with owner, purpose, privileges, credential storage method, and last review date.
• Access review outputs (review attestations, findings, and remediation tickets).
• Audit logs or IAM reports demonstrating enforcement (successful/failed logins, privilege escalations, admin actions) for representative in-scope systems.
• Exception records for break-glass/emergency access (approval + time-bounded access + post-incident review).

Tip: Store evidence in a named location with a retention rule that matches how you support audits and customer diligence. ²

Common exam/audit questions and hangups (what assessors press on)

• “Show me the list of authorized users for System X. Who approved each one?”
• “How do you prevent local accounts from bypassing SSO?”
• “Which service accounts exist, and who owns them?”
• “How do you detect unauthorized account creation?”
• “Walk me through a termination. How quickly do you remove access and revoke tokens?”
• “Do third parties have accounts in your boundary? How are they authorized and monitored?” ²

Hangup pattern: teams can describe intent but cannot produce current exports, approvals, and logs for the exact systems in scope.

Frequent implementation mistakes (and how to avoid them)

1. Relying on policy statements without enforceable configs.
   Fix: map each in-scope system to its enforcement point (IdP group, local group policy, SaaS role, PAM rule).

2. Ignoring non-human identities.
   Fix: create a service account/app identity register and require ownership, least privilege, and offboarding triggers. ¹

3. Shared admin accounts “for convenience.”
   Fix: require named accounts for admins; keep break-glass accounts rare, controlled, and logged.

4. No consistent approval trail.
   Fix: standardize on a ticket type/workflow for access grants and privilege changes, including third parties and contractors.

5. Boundary drift.
   Fix: tie your access inventories and reviews to the CUI system boundary and update both when architecture changes. ³

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk still matters operationally:

• Unauthorized access to CUI can trigger contract consequences, incident response obligations, and loss of customer trust.
• From a CMMC assessment standpoint, weak access controls are easy to validate and hard to explain away. If you cannot show authorization and enforcement, you invite findings. ²

Practical execution plan (30/60/90-day)

First 30 days (stabilize and scope)

• Confirm the CUI boundary and list in-scope systems and identity providers. ²
• Publish the 3.1.1 control card: owner, workflow, exceptions, and evidence bundle. ³
• Start identity inventory: human accounts, privileged accounts, and service accounts for your highest-risk systems.

Days 31–60 (enforce and standardize)

• Convert direct entitlements into group/role-based access for key systems.
• Implement or tighten joiner/mover/leaver workflows with approvals and completion proof.
• Stand up a service account register with required fields (owner, purpose, privileges, credential storage).
• Begin log collection for authentication and admin actions for in-scope systems you expect to demo in an assessment. ¹

Days 61–90 (prove and sustain)

• Run your first formal access review cycle and track remediation to closure.
• Test termination/offboarding with a tabletop: verify access removal across systems and tokens.
• Add recurring control health checks: new privileged account detection, service principal creation, and local admin drift.
• Package an “assessor-ready” evidence set for a sample system to confirm you can answer questions end-to-end. ²

Frequently Asked Questions

What counts as a “process acting on behalf of an authorized user” for 3.1.1?

Non-human identities that access systems or data, such as service accounts, app registrations, API keys, automation jobs, agents, and CI/CD runners. Treat each as an identity that must be explicitly authorized, owned, and least-privileged. ¹

Does 3.1.1 require SSO everywhere?

The requirement is to limit access to authorized users and processes, not to mandate a specific architecture. SSO often makes authorization easier to enforce and evidence easier to produce, but you can meet the requirement with other enforceable controls if they are documented and consistently operated. ¹

How do we handle third-party access (MSPs, consultants) to systems in the CUI boundary?

Require named accounts, documented approvals, time-bounded access where feasible, and monitoring equivalent to employees. Keep offboarding triggers explicit in your workflow so access ends when the engagement ends. ²

Are local accounts automatically noncompliant?

No, but they are a common source of unauthorized access because they can bypass centralized governance. If you keep local accounts, document why, restrict them, monitor them, and include them in access reviews and offboarding steps. ¹

What evidence is most persuasive to an assessor for 3.1.1?

Current access lists tied to your boundary, provisioning/deprovisioning tickets with approvals, and logs showing authentication and admin actions for representative systems. Also expect scrutiny on service account ownership and permissions. ²

We have “temporary” elevated access. What do assessors expect?

They expect you to control it with approvals, clear scope, and an endpoint (auto-expiration or documented removal). Keep the request, approval, and proof of removal together so the story is complete. ³

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170