Access Control for CMMC Level 2: What Defense Contractors Need to Prove Before an Assessment

Access Control is where CMMC stops being a policy project and becomes an operating discipline.

For defense contractors handling Controlled Unclassified Information (CUI), the basic question is simple: who can access CUI, how did they get that access, what systems can they use, and how do you know the access is still appropriate?

The answer is rarely simple.

Most small and mid-sized contractors have grown their access model over time. Employees were added to shared drives because a project was urgent. Administrators kept standing privileges because it was convenient. Remote access expanded during the work-from-home years. External service providers received broad rights to support the environment. Engineers moved between programs, but their old permissions stayed in place.

That is normal business drift. It is also exactly what CMMC Level 2 is designed to expose.

Even with the Department of Defense's 2026 suspension of CMMC Phase II third-party assessment requirements, the underlying obligations have not gone away. DFARS 252.204-7012 still points contractors handling covered defense information toward NIST SP 800-171. SPRS scores and annual affirmations still need to be accurate. Prime contractors still ask hard questions. And when assessments resume or customer reviews tighten, Access Control will remain one of the highest-signal areas of the program.

If your company cannot show that access to CUI is limited, approved, monitored, reviewed, and removed when no longer needed, the rest of the security program will be difficult to defend.

Why Access Control Carries So Much Weight

NIST SP 800-171 Rev. 2 starts with Access Control for a reason.

Before discussing encryption, vulnerability scanning, logging, or incident response, the model asks whether the organization restricts access to authorized users, processes, devices, and transactions. In plain English: keep the right people in, keep everyone else out, and prove the difference.

That matters because CUI exposure usually does not start with an exotic attack. It starts with ordinary access problems:

• A terminated employee account is still active.
• A subcontractor keeps access after the work ends.
• A shared mailbox receives CUI with no clear owner.
• A cloud file library is open to a broad internal group.
• A help desk technician has global admin rights all day, every day.
• A personal device connects to systems that store CUI.
• A user can copy CUI into an unsanctioned sync tool.
• A remote access path bypasses multi-factor authentication.

None of those issues require a nation-state exploit. They are governance failures.

That is why assessors look closely at Access Control. If the access model is loose, it tells them the organization may not understand its CUI boundary, may not have mature account management, and may not be able to enforce least privilege in day-to-day operations.

Start With the CUI Boundary

You cannot manage access to CUI until you know where CUI lives.

This is the first place many contractors stumble. They try to solve Access Control as an identity and permissions problem without first defining the systems, repositories, users, and workflows that are actually in scope.

Start by identifying every place CUI is stored, processed, or transmitted:

• Microsoft 365, Google Workspace, or another collaboration tenant
• Engineering file shares and CAD repositories
• Email and secure messaging tools
• ERP, MRP, ticketing, or quality systems
• Endpoint devices used by employees and contractors
• Backup systems
• Remote access platforms
• Cloud storage and project portals
• Managed service provider tools
• Subcontractor exchange methods

Then identify who needs access to each location and why.

The "why" matters. CMMC does not expect every employee to access every controlled file because the company is small or because collaboration is easier that way. Access should be tied to role, contract, program, customer need, job function, and authorized business purpose.

If your CUI boundary is vague, Access Control evidence will be vague. The assessor will see broad groups, unclear ownership, inherited permissions, and exceptions nobody can explain. A clean boundary makes the rest of the control family much easier to implement.

Least Privilege Has to Be Operational

Everyone agrees with least privilege in theory. The test is whether the company actually operates that way.

For CMMC Level 2, least privilege means users should receive only the access necessary to perform authorized functions. That includes ordinary users, administrators, service accounts, vendors, temporary staff, and external service providers.

A practical least privilege program should include:

• Role-based access groups tied to job duties and programs
• Named owners for CUI repositories
• Documented approval before access is granted
• Separate administrative accounts for privileged work
• Time-limited access for temporary needs
• Removal of access when roles change
• Restrictions on who can create external sharing links
• Restrictions on local administrator rights
• Service accounts with defined purpose and ownership
• Periodic reviews of group membership and privileged roles

The trap is assuming a policy statement is enough.

It is not.

An assessor will not be satisfied by a sentence that says, "The organization enforces least privilege." They will expect to see how access is requested, who approves it, how it is provisioned, how exceptions are handled, how privileged accounts are controlled, and how access is reviewed.

This is where TalonPoint PolicyPack can be useful as a starting structure. A good access control policy, account management procedure, and user access review process help turn the principle of least privilege into a repeatable workflow. The policy does not secure the environment by itself, but it gives leadership, IT, security, and the MSP a common operating model.

Account Lifecycle Management Is Evidence-Rich

Access Control is heavily dependent on account lifecycle discipline.

Every user account has a beginning, middle, and end. CMMC assessment readiness improves when each stage is controlled and documented.

For new users, the company should be able to show:

• Who requested access
• What role or program justified the access
• Who approved it
• What systems and groups were assigned
• Whether security awareness training was completed
• Whether MFA was enrolled before access to CUI systems was allowed

For role changes, the company should be able to show:

• When the role changed
• Which old access was removed
• Which new access was added
• Who approved the change
• Whether CUI repository access was reviewed

For terminations, the company should be able to show:

• When HR or management notified IT
• When accounts were disabled
• Whether sessions and tokens were revoked
• Whether company devices were returned
• Whether external service providers were notified if needed
• Whether shared passwords, keys, or admin credentials were rotated when appropriate

This does not need to be complicated. Many smaller contractors can run this through a ticketing system, HR checklist, identity platform, or controlled spreadsheet. The important part is that the process is consistent, timely, and auditable.

If access changes happen through hallway conversations, emails, and memory, the evidence will fall apart under scrutiny.

Privileged Access Deserves Special Treatment

Administrative access is one of the most sensitive areas in a CMMC Level 2 environment.

Privileged users can change configurations, create accounts, disable protections, access broad data sets, modify logs, install software, alter security settings, and affect the confidentiality of CUI. That is why privileged access should be narrower, more closely monitored, and more formally approved than ordinary user access.

Defense contractors should pay attention to:

• Global administrator roles in Microsoft 365 or Google Workspace
• Domain admin and local admin rights
• Firewall, VPN, and network device administration
• Endpoint management platform rights
• Backup platform administration
• Security monitoring and EDR console access
• MSP administrative accounts
• Break-glass accounts
• Cloud subscription or tenant owner roles

Standing admin access should be the exception, not the default. Where possible, use separate admin accounts, privileged identity management, approval workflows, just-in-time elevation, strong MFA, and alerting for high-risk administrative actions.

At a minimum, privileged account evidence should answer four questions:

1. Who has privileged access?
2. Why do they need it?
3. Who approved it?
4. When was it last reviewed?

Do not overlook external service providers. If your MSP has administrative rights into your CUI environment, those accounts are part of your access control story. Their responsibilities should be reflected in your System Security Plan, contracts, procedures, and incident response process.

Remote Access Is Still a High-Risk Path

Remote work is normal. Remote access to CUI is still high risk.

For CMMC Level 2, contractors should be able to explain and prove how remote access is authorized, protected, monitored, and limited. That includes employee access from home, travel access, vendor support, MSP administration, and any remote maintenance path into systems that store, process, or transmit CUI.

Key questions include:

• Is MFA required for all remote access to CUI systems?
• Are unmanaged or personal devices allowed?
• Is VPN access limited by group, role, or device posture?
• Are remote sessions logged?
• Can users download CUI to local devices?
• Are split tunneling and clipboard/file transfer controlled where relevant?
• Are foreign access locations blocked or reviewed?
• Are vendor remote support sessions approved and recorded when appropriate?
• Are inactive remote access accounts disabled?

The mistake is treating remote access as a network checkbox. A VPN alone does not prove strong access control. The company still needs identity controls, device controls, authorization rules, logging, monitoring, and a clear decision about where CUI may be accessed from.

If CUI can be reached from any laptop, in any location, by any user with a password and a second factor, the access model is probably too loose.

Separation of Duties Prevents Quiet Failure

Separation of duties is not just for large enterprises.

In a small defense contractor, one person may wear several hats. That is unavoidable. But the organization still needs to think deliberately about which duties should not be combined without oversight.

Examples include:

• The person requesting access should not be the only approver.
• The person administering security tools should not be the only person reviewing alerts.
• The person creating accounts should not be the only person reviewing account lists.
• The MSP should not define its own access without company approval.
• Developers should not freely promote code or configuration into production without review.
• Finance, HR, contracts, and program data should not be broadly accessible because the company is small.

Separation of duties does not always require a new department. It can be as simple as documented manager approval, executive review of privileged access, monthly spot checks, or requiring two people to approve sensitive changes.

The goal is to prevent quiet failure. When one person can request, approve, implement, and review their own access, mistakes and abuse become much harder to detect.

Do Not Ignore Public Information and External Sharing

Access Control also includes controlling what can be posted, shared, or made publicly accessible.

That matters for defense contractors because CUI exposure often happens through ordinary collaboration features:

• Public links in cloud storage
• Shared folders with external guests
• Email forwarding to personal accounts
• Project portals with weak guest governance
• Screen sharing during meetings
• Uploads to AI tools, translation tools, or file conversion websites
• Marketing or case study material that includes sensitive program details

Your CUI handling rules should clearly define how external sharing is approved, which tools may be used, whether guest accounts are allowed, who can create sharing links, how links expire, and how external access is reviewed.

This is also where security awareness training and Access Control connect. Users need practical rules they can follow under deadline pressure. "Protect CUI" is too vague. "Do not create anonymous sharing links for CUI; use the approved secure portal and verify the recipient" is actionable.

What Evidence Should Be Ready

For Access Control, evidence should connect policy, implementation, and review.

A strong evidence package may include:

• Access control policy and account management procedure
• CUI data flow and system boundary documentation
• Role or group access matrix
• User access request and approval samples
• Termination and role-change tickets
• MFA configuration screenshots or reports
• Privileged access list and review records
• Remote access configuration evidence
• External guest access reports
• Service account inventory
• Administrative account list
• Access review meeting notes or signoffs
• SSP sections describing identity, access, remote access, and external provider roles
• POA&M items for known access gaps

Do not wait until the week before an assessment to collect this. Access evidence ages quickly. A screenshot from last year may not prove the current state. A quarterly access review that only happened once may not prove an operating process.

The best evidence is produced by the normal process of running the business securely.

A Practical 30-Day Access Control Cleanup Plan

If your Access Control program is not ready, start with a focused 30-day cleanup.

Week one: define the CUI boundary. Identify systems, repositories, users, external providers, and remote access paths that touch CUI.

Week two: clean up user and group access. Remove obvious stale users, disable inactive accounts, document group owners, and eliminate broad access where it is not justified.

Week three: review privileged and remote access. Confirm who has administrative rights, separate admin accounts where possible, verify MFA coverage, and document MSP or vendor access.

Week four: formalize the workflow. Publish or update the access control policy, create a standard access request process, document termination steps, and schedule recurring access reviews.

This will not solve every NIST SP 800-171 requirement. It will, however, reduce real risk and give your company a much stronger foundation for CMMC Level 2 readiness.

Final Thought

Access Control is not glamorous. That is why it is often neglected.

But for defense contractors, it is one of the clearest indicators of whether the cybersecurity program is real. If access to CUI is controlled with discipline, many other parts of the program become easier: incident response, auditing, configuration management, media protection, remote work security, and subcontractor oversight.

If access is unmanaged, everything else becomes harder to trust.

The practical standard is simple: know where CUI lives, know who can reach it, require a business reason, approve access before granting it, review it regularly, remove it quickly, and keep evidence as the work happens.

That is the kind of Access Control program that can survive customer scrutiny, SPRS affirmation pressure, and a future CMMC Level 2 assessment.