FutureFeed CMMC Education Series · Access Control
Access Control (AC): 3.1.7
The short version
If you’re responsible for CMMC compliance, here’s what this requirement comes down to. You need to:
- Make sure regular users can’t run privileged functions like creating accounts, patching, or changing security tools
- Base that on the authorized privileges you’ve already defined (who’s allowed to do what)
- Log every time a privileged function runs, so misuse can be spotted
- Keep those logs and actually review them
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
This control does two jobs at once. First, a regular user simply can’t perform privileged functions: creating accounts, applying patches, running system integrity checks, managing encryption keys, or turning off your antivirus or intrusion detection. Those actions are walled off to authorized privileged users only. Second, whenever a privileged function does run, it’s recorded in your audit logs.
Why both? The wall stops the obvious problem. The log catches the one that gets through: a compromised admin account, or a trusted insider misusing their access. You can’t investigate what you never recorded.
This is really the payoff of the least-privilege decisions you already made. Once you’ve defined who’s authorized for what, this control enforces that line and keeps a record every time someone crosses it.
Wall off the powerful actions, and record them every time they run.
A regular employee tries to install software or create a new user account and simply can’t; the system won’t let a non-privileged account do it. When an authorized admin creates that account, the action lands in the audit log with who did it, what they did, and when. Months later, if anyone questions how an account appeared, you can point to the record. And if an attacker ever rode in on a stolen admin login, that same log is where you’d catch the unusual privileged activity.
What you need to have in place
To be compliant, each of those boxes needs to be real and repeatable:
- Privileged functions restricted to authorized users, so non-privileged accounts can’t run them. This flows straight from your least-privilege decisions.
- Protection for your security tools, so a regular user can’t disable antivirus, intrusion detection, or logging.
- Logging that captures privileged-function use: who ran it, what they did, and when.
- Retention and review of those logs, so the record is actually useful when you need it.
- Records or configuration proving both the restriction and the logging.
Two halves, always together: prevent the action, and capture it when it happens.
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
- The IT or security lead who sets authorized privileges and configures logging
- Whoever reviews the privileged-function logs
- The business and data owners who defined the roles this control enforces
Tools
- Identity or operating-system controls that block privileged functions for non-privileged users
- Audit logging on the systems where privileged functions happen
- Somewhere logs are stored and reviewed (a log store or SIEM)
Documents
- A policy stating privileged functions are restricted and logged
- Configuration showing non-privileged users can’t run privileged functions
- Audit-log samples showing privileged-function execution is captured
- Records that the logs are reviewed, with dates
- A note in your System Security Plan (SSP) describing both halves
You need to show two things: the line holds, and you have a record every time it’s crossed.
When should I work on this
Build this right after 3.1.5 and 3.1.6. It’s the enforcement-and-detection end of least privilege: those controls decide who holds power and how they use it, and this one makes sure everyone else is blocked and every use is recorded. It also reaches into Audit and Accountability, because it introduces a logging requirement, so it’s a natural moment to start setting up your logging. Do the “prevent” part when you set permissions, and stand up the “capture” part alongside your audit logging.
Common challenges
Regular users can quietly do privileged things.
Why it happens: Permissions are looser than assumed, so a “normal” account can still install software or change settings.
Recommendation: Test it. Confirm a non-privileged account actually can’t run privileged functions, and tighten whatever it can.
Privileged actions aren’t logged.
Why it happens: Logging is on for some systems but not the ones where admin actions actually happen, so there’s no record.
Recommendation: Turn on audit logging where privileged functions run, capturing who did what and when.
The logs exist but no one looks.
Why it happens: Events are captured but never reviewed, so misuse sits unnoticed until it’s a real problem.
Recommendation: Review privileged-function activity on a schedule, or route it to something that alerts you.
What good looks like
A compliant contractor can usually answer yes to all of these:
- Can a regular, non-privileged account be blocked from running privileged functions?
- Are security tools (antivirus, detection, logging) protected from being turned off by regular users?
- Is every use of a privileged function captured in your audit logs?
- Do you actually review that privileged activity?
If any answer is no, that’s your next place to start.
This control has two halves, and the logging half is the one people forget. Blocking non-privileged users isn’t enough on its own; the requirement also says to capture privileged-function execution in your audit logs. That log is how you catch the case the wall can’t stop, a compromised admin account or a trusted insider. If you’re preventing but not logging, you’ve only done half the control.
How this connects to other controls
This control doesn’t stand alone. A few close relationships:
- Least privilege and non-privileged accounts (3.1.5, 3.1.6): those decide who holds power and how they use it; this one enforces the line for everyone else and records every crossing. Together they are the privileged-access core of the family.
- Limit transactions and functions (3.1.2): the standard notes this control is a condition met by the authorized privileges you defined there.
- Audit & Accountability (3.3): the logging half lives here too. That family goes deeper on what to log, how long to keep it, and how to review it.
The requirement, word for word
For your reference, here’s the exact language so you’re working from the source and not a paraphrase:
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
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 requirements: see also 3.1.2 (limit transactions and functions), 3.1.5 (least privilege), 3.1.6 (non-privileged accounts for nonsecurity functions), and 3.3.1 (audit logging) within NIST SP 800-171 Rev 2.
