FutureFeed CMMC Education Series · Access Control
Access Control (AC): 3.1.5
The short version
If you’re responsible for CMMC compliance, here’s what this requirement comes down to. You need to:
- Give every user and process the least access the job needs, never higher
- Keep admin and other privileged accounts to a small, named set of people
- Treat security functions (like changing what’s logged or who can access what) as privileged, and limit who can touch them
- Review privileged 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
Least privilege comes down to one question: if this account is compromised, what’s the worst thing that could happen? The answer should be “not much.” You keep each account’s power as small as the job allows, so a stolen login is a small problem instead of a company-wide one.
The last control started this by limiting everyday users to their own tasks. This one zeroes in on the accounts that can do the most damage: admin accounts and security functions.
Privileged accounts are the keys to the kingdom. When one is compromised, the attacker inherits everything it can do. Every extra privilege you hand out makes your worst-case day a little bigger, which is exactly why power should be rare.
The biggest enemy of least privilege is a familiar phrase: “let’s just make them an admin in case they need it.” That “in case” is how accounts end up with power nobody remembers granting.
“Security functions” is the part people miss. It means things like creating accounts, changing what gets logged, tuning intrusion detection, and setting who can access what. Those don’t always feel like “admin,” but they carry the same kind of power, so they get the same tight limits.
The same principle applies to automated accounts. A service account should have only the permissions it needs to do its task, nothing more.
The more power an account has, the fewer accounts should have it. That’s the whole idea.
Your network admin has a privileged account to manage servers and accounts. Only two people hold that level of access, and only because their jobs require it. A regular employee who needs to run one reporting task gets exactly that permission, not blanket admin rights. Here’s why that matters: if the reporting account is compromised, the attacker can only run reports. If the administrator account is compromised, the attacker can control the whole environment. That’s why privileged access stays rare.
What you need to have in place
To be compliant, each of those boxes needs to be real and repeatable:
- Access set to the minimum each user and process needs, with no privileges handed out “just in case.”
- Privileged accounts limited to a small, named group whose jobs genuinely require them.
- Security functions treated as privileged: creating accounts, changing logging, tuning detection, and configuring permissions are limited, not open to everyone.
- Least privilege for automated accounts too, so service accounts and scheduled tasks carry only the permissions their job requires.
- Regular reviews of who and what holds privileged access, removing any that’s no longer needed, with records of who has it and why.
The goal is privileges no higher than necessary, especially for the accounts that can change your environment.
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 privileged-access decisions (usually your IT or security lead)
- Managers who confirm who genuinely needs elevated access
- Whoever reviews the privileged accounts
Tools
- Your identity system, with roles or groups and a way to manage admin rights
- The systems and applications where security functions are configured
- Somewhere privileged-access records and reviews are kept
Documents
- A policy defining privileged accounts and how least privilege is applied
- A list of privileged accounts (including service accounts), who or what holds them, and the reason for each
- Privileged-access review records with dates
- A note in your System Security Plan (SSP) describing how least privilege is applied
You don’t need heavy tooling. You need to show that elevated access is rare, justified, and reviewed.
When should I work on this
Build this right after 3.1.2. Least privilege is the principle; 3.1.2 applies it to everyday users, and this control applies it to the riskiest access you have. Do it while you’re first setting up roles and permissions. It’s much easier to start with tight permissions than to remove privileges after people have gotten used to having them. Starting tight also sets up the next two controls, which go deeper on how privileged accounts are actually used day to day.
Common challenges
There are too many admins.
Why it happens: Privileged rights get handed out for convenience during setup and never reduced afterward.
Recommendation: Cut privileged accounts down to the few who truly need them, with a reason on record for each.
Security functions aren’t treated as privileged.
Why it happens: Changing logging or detection settings doesn’t feel like “admin,” so those abilities are left wide open.
Recommendation: Treat configuring logging, detection, and access settings as privileged, and limit who can do it.
Privileged access is never reviewed.
Why it happens: Once granted, elevated access lingers as people change roles and no one circles back.
Recommendation: Review privileged accounts on a schedule and remove any access that’s no longer needed.
What good looks like
A compliant contractor can usually answer yes to all of these:
- Does every account carry only the least privilege its job needs?
- Are privileged and admin accounts held by a small, named group?
- Are security functions (logging, detection, access settings) limited to that group?
- Do your service accounts carry only the permissions their task requires?
- Can you show, with records, who has privileged access and why?
If any answer is no, that’s your next place to start.
Least privilege isn’t only about admin accounts. It also covers “security functions,” like changing what gets logged, tuning intrusion detection, or setting who can access what. Those can quietly carry as much risk as a full admin account, so they need the same tight limits, even when the person holding them isn’t called an administrator.
How this connects to other controls
This control doesn’t stand alone. A few close relationships:
- Limit transactions and functions (3.1.2): that control applies least privilege to everyday users; this one applies the same idea to your most powerful access.
- Non-privileged accounts and privileged functions (3.1.6, 3.1.7): these build directly on this control, covering how privileged accounts are used day to day.
- Separation of duties (3.1.4): least privilege limits how much one account can do; separation splits who does what. Together they keep power from concentrating in one place.
The requirement, word for word
For your reference, here’s the exact language so you’re working from the source and not a paraphrase:
Employ the principle of least privilege, including for specific security functions and privileged accounts.
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.6 (use non-privileged accounts for nonsecurity functions), and 3.1.7 (prevent non-privileged users from executing privileged functions) within NIST SP 800-171 Rev 2.
