CMMC Assessment Checklist
Download our CMMC assessment checklist!
.jpg?ext=.jpg)
Access Control: The CMMC Domain That Trips Up Most Contractors
Quick answer: Access Control (AC) is the largest domain in CMMC Level 2, comprising 22 of the 110 NIST SP 800-171 requirements. Contractors most often fail AC assessments due to overprivileged accounts, broad VPN access that doesn't enforce least privilege, and insufficient monitoring of remote sessions. Closing these gaps requires identity-scoped access, documented privilege reviews, and audit logs that prove—not just describe—enforcement.
Defense contractors preparing for CMMC Level 2 certification quickly discover that not all domains carry equal weight. Of the 110 security requirements drawn from NIST SP 800-171, 22 fall under Access Control—more than any other of the framework's 14 domains. That concentration alone makes AC the domain most likely to generate assessment findings, but the real challenge isn't the number of requirements. It's that Access Control asks contractors to prove, not just document, that the right people have the right access to the right systems at the right time.
This matters more now than it did a few years ago. A contractor can no longer point to an access control policy on paper and call it done. Assessors expect to see access logs, segmentation evidence, and session records that confirm the policy is actually working in a live environment.
This post breaks down what the Access Control domain actually requires, where contractors most often stumble, and what a defensible, assessment-ready access control program looks like in practice.
What Does the CMMC Access Control Domain Actually Require?
Access Control requirements (numbered 3.1.1 through 3.1.22 in NIST SP 800-171) fall into five practical categories:
- Authorized access (3.1.1–3.1.2): Limit system access to authorized users, processes, and devices, and restrict what those users can actually do once they're in.
- Least privilege enforcement (3.1.4–3.1.7): Separate duties among individuals, require non-privileged accounts for routine tasks, and prevent standard users from executing privileged functions.
- Session management (3.1.8–3.1.11): Limit failed login attempts, lock sessions after inactivity, and terminate sessions automatically under defined conditions.
- Remote access controls (3.1.12–3.1.15): Monitor and encrypt remote sessions, route connections through managed access points, and authorize any remote execution of privileged commands.
- External and mobile connections (3.1.16–3.1.22): Authorize wireless access, encrypt Controlled Unclassified Information (CUI) on mobile devices, and control connections to external systems and portable storage.
Each category builds on the last. A contractor that nails user authentication but ignores session termination, or secures the network perimeter but leaves remote access unmonitored, still has an incomplete Access Control posture—and an incomplete posture is exactly what assessors are trained to find.
Why Do So Many Contractors Struggle with This Specific Domain?
Access Control requirements are deceptively simple to state and genuinely difficult to make operational across a real organization with real turnover, real vendors, and real legacy systems. Three patterns show up repeatedly in assessment findings.
Overprivileged accounts outlast their original purpose
Access tends to accumulate. An employee who needed elevated privileges for a single project retains them long after the project ends. A departing contractor's credentials stay active for weeks. Shared administrative accounts get passed along informally, with no record of who used them or when. None of this is malicious—it's organizational drift—but it directly violates the least privilege principle at the heart of requirements 3.1.5 through 3.1.7.
Broad VPN access gets mistaken for compliant remote access
Many contractors treat a working VPN connection as evidence of secure remote access. It isn't. A VPN proves a user was authenticated; it says nothing about whether that user's reach was limited to only the systems their role requires. Assessors specifically look for identity-scoped access that enforces least privilege over the network, not just at login. Broad VPN access—where any authenticated user can reach far more of the network than their job demands—is one of the most common reasons AC findings surface during assessment.
Third-party and subcontractor access gets overlooked
Accountability for vendor and subcontractor access sits with the prime contractor, regardless of who actually granted or manages that access. If a contractor can't produce evidence of how a subcontractor's access was scoped, logged, and eventually revoked, that gap becomes the contractor's assessment risk—not the vendor's.
How Can Contractors Build an Access Control Program That Holds Up to Assessment?
Choose a remediation approach based on what's actually failing. If the issue is account sprawl, start with a privilege audit. If it's remote access, prioritize segmentation. Most contractors need some combination of the following.
Conduct a full privilege review before anything else. Catalog every account with access to CUI-adjacent systems, confirm each one maps to a current role and business need, and remove or downgrade anything that doesn't. This single step resolves a large share of least privilege findings before an assessment ever begins.
Replace broad network access with identity-scoped connections. Instead of granting VPN users reach across the network, limit each user, vendor, and subcontractor to the specific applications and data stores their role requires. This directly satisfies the intent behind requirements 3.1.1, 3.1.2, and 3.1.20, and it gives assessors a concrete, testable boundary to evaluate rather than a policy statement to take on faith.
Build logging into the access design, not around it. Access logs, policy decisions, and segmentation events need to be retained in a form that supports audit review and incident reconstruction. Logging added as an afterthought rarely produces the kind of clean evidence trail an assessor expects to see during a Level 2 review.
Enforce session controls consistently across every system that touches CUI. Automatic session locks, defined termination conditions, and limits on failed login attempts are straightforward to implement but easy to apply inconsistently across a mixed environment of cloud systems, on-premises servers, and remote endpoints. Consistency matters as much as the control itself.
Document ownership of third-party access explicitly. Assign a named internal owner for every subcontractor or vendor connection, with clear responsibility for on-boarding, scope, logging, and revocation. This closes the accountability gap that assessors increasingly probe during Phase 2-era reviews.
Treat Access Control as an Operational Discipline, Not a Checklist
The Access Control domain has more moving parts than any other section of CMMC Level 2 for a reason: access is where most breaches actually begin, and it's where policy intentions most often diverge from daily practice. Contractors that pass assessment comfortably tend to share one trait—they've stopped treating access control as a document to produce and started treating it as a system to operate and monitor continuously.
Start with the privilege review. It's the fastest way to surface how far your current environment has drifted from a true least-privilege model, and it will tell you exactly where the remaining 21 Access Control requirements still need work.
Frequently Asked Questions
How many requirements are in the CMMC Access Control domain?
The Access Control domain contains 22 requirements, numbered 3.1.1 through 3.1.22 in NIST SP 800-171. It's the largest of the 14 domains that make up CMMC Level 2's 110 total controls.
What's the most common reason contractors fail Access Control assessments?
Overprivileged accounts and broad VPN access are the two most frequent causes. Both typically reflect a least privilege gap—users or connections that reach further into the network than their role actually requires.
Does CMMC Access Control apply to subcontractors and vendors?
Yes. The prime contractor remains accountable for how subcontractor and vendor access is scoped, logged, and revoked, even when that access is technically managed by the third party itself.
Is a VPN enough to satisfy CMMC's remote access requirements?
Not on its own. A VPN authenticates a user but doesn't inherently enforce least privilege. CMMC's remote access requirements (3.1.12–3.1.15) expect monitored, encrypted sessions routed through managed access points, with network reach limited to what each role actually needs.
What should contractors do first if they haven't started on Access Control?
Begin with a full privilege audit across every system that touches CUI. Identifying and removing unnecessary access is typically the fastest way to reduce assessment risk across the entire domain.
