FutureFeed CMMC Education Series · Access Control
Access Control (AC): 3.1.1
The short version
If you’re responsible for CMMC compliance, here’s what this requirement comes down to. You need to:
- Give access only to people you’ve approved, and start everyone at “no access” until you do
- Inventory and review your service accounts and automated logins, and limit each to only what it needs
- Let only approved, managed devices reach systems that process Controlled Unclassified Information (CUI)
- Review who and what has access regularly, and keep dated records
If you already have those things and can prove them, you’re well on your way. Now let’s talk about what each one actually looks like.
In plain English
Think of this control as deciding who you trust inside your environment. Every person, every automated process, and every device has to earn that trust before it’s allowed in. The lock on your front door is the familiar image, but the real point is simpler: every connection to your CUI environment should have a reason to be there.
At any moment, you should be able to answer two questions about every person, process, and device in your environment:
- Who or what is it?
- Did we approve it?
There are three kinds of “who” to think about, and all three count:
- People: your employees and contractors.
- Processes: automated logins, service accounts, and apps that talk to other apps.
- Devices: laptops, phones, and servers.
Default to “no.” Access has to be earned through approval. That single habit is most of this control.
A new project needs a shared drive that holds CUI. Before anyone can open it, their manager approves access tied to their job. An automated backup runs under its own login, scoped to just the backup task and nothing more. Only company laptops that meet your rules can connect, so a personal laptop is turned away even with the right password. Every few months you review the list and remove anyone who no longer needs it. That’s what this requirement is asking you to do.
What you need to have in place
To be compliant, each of those boxes needs to be real and repeatable:
- A “no access” default, so access is granted only after someone approves it.
- An approval step tied to the person’s job, before an account is created.
- An inventory of service accounts and automated logins, reviewed on a schedule and each limited to the least it needs to do its job.
- Device rules so only approved, managed devices can reach systems that process CUI.
- Regular access reviews and prompt removal when access is no longer needed.
The through-line is simple: nothing gets in by default, and you can show why everything that is in was allowed.
A new stop every Tuesday and Thursday.
Our twice-weekly series breaking CMMC down one step at a time. Opt in and we’ll send each one to your inbox.
What you need to prove it
Think in three buckets. An assessor will want all three, so it helps to build them at the same time.
People
- Someone who owns access decisions (usually your IT or security lead)
- Managers who approve access requests
- Whoever runs the periodic access reviews
Tools
- Your identity system (for many contractors, Microsoft Entra ID or Active Directory)
- Device management that enforces approved devices (for example Intune or an endpoint tool)
- Somewhere access logs and reviews are kept
Documents
- An access control policy covering how access is granted, reviewed, and removed
- Access request and approval records
- An inventory of accounts (including service accounts) and approved devices
- Access review records with dates
- A note in your System Security Plan (SSP) describing the process
You don’t need enterprise everything. You need the decision written down, and records that match the decision.
When should I work on this
This is where the technical work really begins, after your people and governance families are in place. Access Control is the largest family in the standard and one an assessor spends real time on, so it’s worth doing carefully. Start with this control, because the rest of the family builds on it. It also leans on work you’ve already done: your Personnel Security offboarding is what removes access when someone leaves, and you can’t limit access to systems and devices you haven’t inventoried yet.
Common challenges
Access is granted by default or by habit.
Why it happens: New accounts get broad access “to be safe,” or a new person is simply cloned from a similar user.
Recommendation: Start from no access and grant only what the role needs, with the approval on record.
Service accounts get forgotten.
Why it happens: Automated logins are set up once and never reviewed, often carrying far more rights than they use.
Recommendation: Inventory them, scope each to least privilege, and review them on a schedule like you do for people.
Unapproved devices reach CUI.
Why it happens: A valid password is treated as enough, so a personal or unmanaged device connects to CUI systems.
Recommendation: Require approved, managed devices for CUI systems and block the rest, even when the credentials are correct.
What good looks like
A compliant contractor can usually answer yes to all of these:
- Is the default “no access” until someone approves it?
- Are your service accounts inventoried and limited to what they need?
- Can only approved, managed devices reach systems that process CUI?
- Can you prove, with dates, who and what has access, and that you review it?
If any answer is no, that’s your next place to start.
Access control is not only about people. Automated logins (service accounts) and devices count as “who” too, and they’re the ones most often missed. A device with a valid password is not automatically an approved device.
How this connects to other controls
This control doesn’t stand alone. A few close relationships:
- Personnel Security: your offboarding process is what removes access when someone leaves, and screening supports granting it in the first place.
- Identification & Authentication: this control decides who is allowed in; that family proves people are who they say they are, with passwords and MFA. They work as a pair.
- Asset inventory: you can’t limit access to systems and devices you haven’t identified, so your inventory feeds this control directly.
The requirement, word for word
For your reference, here’s the exact language so you’re working from the source and not a paraphrase:
Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
Every organization implements these controls a little differently. If you’re not sure whether your approach would satisfy an assessor, join one of our upcoming webinars or schedule a 15 Minutes with FutureFeed session. We’d rather answer your questions now than have you discover them during an assessment.
CMMC: Everything You Need to Know to Get Started (6th Edition)
Want the full compliance framework and the funding resources available to defense contractors? Our guide has it.
Sources
- NIST SP 800-171 Rev 2, Access Control (3.1)
- Related standards: NIST SP 800-53 Rev 5 (AC-2, AC-3, AC-17) · DFARS 252.204-7012
