Requirements 3.1.1 and 3.1.2 are written as access outcomes, not as a prescriptive account-lifecycle checklist. A practical way to prove them is disciplined provisioning, deprovisioning, and access review.
For most small defense contractors, the requirement is only as real as the evidence behind it — so the useful test is whether it can be traced to a specific system inside the FCI/CUI boundary, an owner, and a current artifact.
The rule in plain English
3.1.1 limits access to authorized users, processes, and devices. 3.1.2 limits those authorized entities to the transactions and functions they are permitted to execute.
Account management therefore becomes evidence infrastructure: the contractor should be able to show why access was granted, what level was approved, and when it was removed or changed.
How to implement it without overbuilding
Use an access-request workflow tied to role and system-owner approval. Create separate handling for privileged access, service accounts, temporary access, and external users.
Periodic review should compare current permissions with current job need; it should not be a rubber-stamp screenshot exercise.
What evidence to keep
Keep access requests, approvals, directory/group exports, privileged-role listings, inactive-account reports, deprovision tickets, and completed access reviews.
Pick a sample account and show the full lifecycle from request to current entitlement or removal.
Where teams get into trouble
Typical gaps are orphaned access after role changes, service accounts with no owner, temporary access that becomes permanent, and group memberships nobody can explain.
Small-contractor walkthrough
A new quality manager needs access to a CUI file share but not administrative rights. The provisioning record should show the request, role-based approval, group membership, and later review so the company can explain both authorization and permitted function.
- Define account owners and approvers.
- Require documented provisioning.
- Separate privileged access.
- Review inactive/external accounts.
Decisions to document before assessment
Before marking this topic ready, make four decisions explicit: define account owners and approvers; require documented provisioning; separate privileged access; and review inactive/external accounts. Assign an owner and an evidence location to each decision.
Manual deep review: users, processes, devices, and permitted functions
3.1.1 is broader than employee accounts. Identify authorized users, processes acting on behalf of authorized users, and devices or other systems permitted to connect. Service identities, automation, application connectors, managed endpoints, servers, and relevant external systems therefore belong in the access-control story. Perfect human-user provisioning does not explain why an orphaned service account or unmanaged device can still reach CUI.
Create an authoritative basis for each category. Human users can be tied to job role and system-owner approval; service or process identities need an owner and business purpose; devices can be governed through enrollment, certificates, management state, network controls, or another mechanism appropriate to the environment. Reconcile these records to live directory, application, and device data rather than relying on a policy list created for assessment.
3.1.2 begins after login: what transactions and functions may the authorized identity execute? Define role and permission boundaries at file shares, applications, databases, administrative consoles, and business workflows. A quality manager may need read/write access to a controlled quality repository but no domain administration; an engineer may need CAD data but no payroll function. Group membership helps only when the group has a defined purpose, approver, and actual permission set.
Provisioning should create a lifecycle record linking request, approval, role, system, and privilege. Periodic review should present real entitlements—not only usernames—so managers see privileged roles, groups, application permissions, service identities, device authorizations, and external accounts. Before assessment, sample a new hire, a transfer, a service account, and a device, then demonstrate one prohibited function is denied.
- Access request and approval.
- User/group/application entitlement export.
- Service-account owner and purpose.
- Device authorization evidence.
- Completed review and remediation record.
Manual assessment cross-check
Sample one human account, one service identity, and one authorized device, then demonstrate one system function the human user should not be able to execute.
Use CMMC Account Management: Provisioning, Deprovisioning, and Periodic Access Review (3.1.1–3.1.2) as an operating guide, not as a substitute for the controlling source. Before publication or assessment use, re-open the current NIST SP 800-171 Rev. 2 requirement, the corresponding NIST SP 800-171A assessment objectives, and the DoD CMMC Level 2 Assessment Guide. Confirm that every mandatory statement on the page maps to those sources or to a clearly labeled organizational implementation choice.
Additional objective-level implementation notes
Authorization should be traceable from business need to effective permission. For a human user, connect the access request to the groups, application roles, and file permissions actually granted. For a service identity, record owner, purpose, credential management, and permitted systems. For a device, document how authorization is decided and technically enforced.
Periodic access review should present entitlements, not only a list of active usernames. Review privileged roles, application permissions, service identities, devices, external accounts, and temporary access. There is no single universal review interval in 3.1.1–3.1.2; choose a cadence that fits risk and use event-driven reviews after transfers, terminations, new systems, or major role changes.
Final manual spot check
For a final spot check, select one employee, one service account, and one managed device. For each, show the authorization basis and the effective access in the live system. Then select one transaction or function the employee should not perform and demonstrate that the system denies it. This proves both halves of the topic: only authorized identities and devices enter the environment, and authorized users are still limited to the functions their role permits.
A short working check
- ✓Define account owners and approvers.
- ✓Require documented provisioning.
- ✓Separate privileged access.
- ✓Review inactive/external accounts.
- ✓Perform entitlement reviews.
- ✓Close access after role/employment changes.
Common questions
Does CMMC prescribe quarterly access reviews?
No universal quarterly interval is stated in 3.1.1–3.1.2. Choose and document a risk-based cadence.
Can group membership be evidence?
Yes, when groups are tied to approved roles and the organization can show how membership is granted and reviewed.
Are service accounts covered?
Processes acting on behalf of users are part of the access-control concept, so service identities need governance.
Is an HR termination list enough?
No. It should trigger and reconcile to actual technical access removal.
Do service accounts and devices matter for 3.1.1?
Yes. The requirement includes users, processes acting on behalf of users, and devices or other systems.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
