FutureFeed CMMC Education Series · Access Control
Access Control (AC): 3.1.8
The short version
If you’re responsible for CMMC compliance, here’s what this requirement comes down to. You need to:
- Set a limit on how many times someone can fail a login before the account locks
- Apply that limit to both local logins and logins over the network
- Decide what happens after the limit is hit (a temporary lockout that releases on its own, or a manual unlock)
- Write down your chosen settings and keep them applied consistently
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 answers one question: how many chances should an attacker get to guess a password? Not many, and never unlimited.
Attackers guess passwords by trying thousands of combinations, fast. This control puts a stop to that. After a set number of failed attempts, the account locks, which turns an unlimited guessing game into a handful of chances before the door closes.
NIST tells you to limit the attempts, but it doesn’t hand you a magic number. You pick a reasonable threshold and decide how long a lockout lasts. It applies whether someone is logging in at the keyboard or coming in over the network, which is the part people forget.
Lockouts are usually temporary, releasing on their own after a set time. That’s on purpose: it stops an attacker from locking out your whole company as a nuisance, and it keeps a fat-fingered employee from being stuck for a day.
Nobody should get unlimited guesses at a password. That’s the whole idea.
Your systems are set to lock an account after five failed password attempts. When a real employee mistypes a few times, they get a short lockout and can try again in fifteen minutes or call the help desk. When an attacker’s script tries hundreds of passwords, it hits the limit almost immediately and gets nowhere. The same limit applies whether the attempt comes from inside the office or across the internet.
What you need to have in place
To be compliant, each of those boxes needs to be real and repeatable:
- A defined limit on consecutive failed logon attempts.
- A defined response when the limit is reached, such as a temporary lockout that auto-releases, or a manual unlock.
- Coverage for local and network logins, not just someone sitting at the machine.
- Consistent application across your systems, at the operating-system level and in applications where it makes sense.
- Records of your chosen settings and proof they’re configured.
You pick the numbers; the control just requires that a limit exists and holds.
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 and maintains the lockout settings
- The help desk who handles unlock requests
- Whoever verifies the settings are actually applied
Tools
- Your identity system or operating-system policy (for many contractors, the account lockout policy in Microsoft Entra ID or Active Directory)
- Application-level lockout where an app handles its own logins
- Somewhere the settings are recorded
Documents
- A policy stating your lockout threshold and what happens when it’s hit
- Configuration showing the lockout is enforced, for local and network logins
- A note in your System Security Plan (SSP) describing the settings
You don’t need much here. You need to show a limit exists, covers network logins, and is actually turned on.
When should I work on this
This is a quick, high-value technical win. Do it when you’re configuring your identity and login settings, alongside your authentication controls. Most identity platforms have an account-lockout setting built in, so it’s usually a matter of turning it on, choosing sensible values, and confirming it reaches the systems that don’t sit behind your main login.
Common challenges
There’s no limit at all.
Why it happens: Default settings never got changed, so accounts quietly allow unlimited password attempts.
Recommendation: Set a lockout threshold in your identity system and confirm it’s actually on.
Only some systems enforce it.
Why it happens: The main login enforces a lockout, but an application or a remote-access path doesn’t.
Recommendation: Apply the limit to both local and network logins, and check the systems that sit outside your main identity provider.
Lockouts cause chaos, so someone turns them off.
Why it happens: A too-strict or permanent lockout frustrates users or invites denial-of-service, so it gets disabled.
Recommendation: Use a temporary lockout that auto-releases after a set time. It protects you without stranding people.
What good looks like
A compliant contractor can usually answer yes to all of these:
- Is there a set limit on failed login attempts?
- Does it apply to both local and network logins?
- Does a lockout release safely (temporary, or a clear unlock path)?
- Can you show the configuration that enforces your limit?
If any answer is no, that’s your next place to start.
NIST doesn’t hand you a specific number here. It says to limit unsuccessful logon attempts, not “lock after exactly five.” You choose a reasonable threshold and lockout behavior for your environment and apply it consistently. Don’t confuse “we have a password policy” with this control either: this one is specifically about capping failed attempts, and it has to cover network logins, not just someone at the keyboard.
How this connects to other controls
This control doesn’t stand alone. A few close relationships:
- Identification & Authentication (3.5): this works hand in hand with how you verify who’s logging in, and it’s often configured in the same identity settings.
- Limit system access (3.1.1): locking out repeated failures is one more way you keep unauthorized users out.
- Audit & Accountability (3.3): failed-logon and lockout events are worth logging, so a burst of them can tip you off to an attack in progress.
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 unsuccessful logon attempts.
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.1 (limit system access), 3.5.1 and 3.5.2 (identification and authentication), and 3.3.1 (audit logging) within NIST SP 800-171 Rev 2.
