This is one of the more technically straightforward practices in the Access Control family. Most organizations already have some form of account lockout configured. The problem is consistency: the cloud identity provider has a lockout policy, but the VPN doesn’t. Or the lockout threshold is set but the lockout duration is missing from the SSP. The assessor is checking that the policy is defined, configured, and consistent across everything in your CUI boundary. Account lockout works in conjunction with IA.L2-3.5.3 (multi-factor authentication) and AU.L2-3.3.1 (audit logging of logon attempts) to create layered authentication security.
What the assessor is actually evaluating
The assessor wants to see three things: a defined lockout threshold, consistent enforcement across your environment, and alignment between your SSP and your actual configuration.
Defined threshold. You’ve decided how many failed attempts trigger a lockout and how long the lockout lasts. The specific numbers matter less than having them defined. Three attempts with a 15-minute lockout is fine. Five attempts with a 30-minute lockout is fine. “We lock accounts after too many failures” with no specifics is not fine.
Consistent enforcement. The lockout policy applies everywhere a user can authenticate within your CUI boundary. That means your cloud identity provider, your VPN, any on-premises systems, your email gateway, and anything else with a login prompt. The assessor will ask about each one. If your identity provider locks out after 5 attempts but your VPN allows unlimited attempts, that’s a gap.
SSP alignment. What your SSP says matches what’s actually configured. If your SSP says “5 failed attempts, 30-minute lockout” and the assessor pulls up your configuration and sees “10 failed attempts, no lockout duration,” that’s a discrepancy that creates doubt. Always verify your SSP matches reality before the assessment.
What a realistic SSP definition looks like
[Organization Name] limits unsuccessful logon attempts to protect against brute-force and credential-guessing attacks. Account lockout policies are configured across all authentication points within the CUI boundary.
Cloud identity accounts are locked after [number] consecutive unsuccessful logon attempts within a [time window] period. Locked accounts are automatically unlocked after [duration] or can be manually unlocked by an administrator. VPN authentication follows the same threshold through integration with [identity provider].
On-premises systems and local accounts, where applicable, enforce the same lockout threshold via Group Policy. Failed logon attempts are logged and forwarded to [SIEM/log aggregator] for monitoring. Repeated lockout events trigger alerts for review by [IT Director / MSSP / security team].
Notice the specifics:
Concrete numbers with brackets. Fill in your actual values. The assessor will compare these to your configuration, so they must match. Don’t round or approximate.
Every authentication point is covered. Cloud identity, VPN, on-premises systems. The assessor will mentally walk through everywhere a person can log in and check that lockout applies to each one.
Monitoring is included. Failed logon attempts are blocked and logged for review. This connects to the audit practices (AU.L2-3.3.1) and demonstrates that you’re implementing defense in depth—both prevention and detection.
How to present your evidence
- Cloud identity provider lockout policy configuration screenshot
- VPN authentication lockout settings
- Group Policy or endpoint management lockout configuration (if on-premises systems exist)
- SSP section showing the defined threshold and duration
- Alert configuration for repeated lockout events (if implemented)
This is a “show the configuration” practice. The assessor will ask you to pull up the settings, and you’ll show them. Have each authentication point’s lockout configuration ready as a screenshot or be prepared to navigate to it live.
Start with your primary identity provider. Pull up the lockout policy. Show the threshold, the lockout duration, and the reset window. Then move to your VPN. If it authenticates against the same identity provider, show how that integration works. If it has its own lockout policy, show that configuration separately.
If you have on-premises systems with local accounts (like a file server or a legacy application), show the Group Policy or local security policy that enforces lockout on those systems.
The key is completeness. The assessor is looking for gaps. Don’t show only one authentication point and assume they’ll accept it for everything.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Inconsistent thresholds. Cloud identity locks out after 5 attempts, but the VPN allows 20. Or the lockout policy exists for user accounts but not for admin accounts. Every authentication point in the CUI boundary needs coverage.
SSP doesn't match configuration. The SSP says "3 attempts, 15-minute lockout" but the actual setting is 10 attempts with no lockout duration. This is an easy mistake to make if the SSP was written months ago and someone changed the settings since. Verify before the assessment.
No lockout duration defined. Accounts lock out after failed attempts, but there's no automatic unlock period. Accounts stay locked until an admin manually unlocks them. This isn't necessarily a finding on its own, but if your SSP says "automatically unlocked after 30 minutes" and the reality is "manual unlock only," that's a discrepancy.
Lockout policy doesn't cover service accounts. Service accounts can be brute-forced without any lockout mechanism. If service accounts authenticate interactively or are exposed to network authentication, they need protection too.
A clearly defined lockout threshold and duration. Configuration screenshots that match the SSP. Coverage across every authentication point in the CUI boundary. Bonus points for monitoring and alerting on lockout events. This practice is one of the faster ones to clear if everything is consistent and documented.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
Your MSP likely configured the lockout policies in the first place. The assessor will want to know that those settings are intentional and documented, chosen deliberately rather than leaving defaults.
The MSP should be prepared to show the configuration for every authentication point they manage. If they manage your identity provider, VPN, and endpoint security, they should be ready to pull up the lockout settings for each one and confirm they match the SSP.
If the MSSP handles monitoring, they should be able to show the alerting rules for failed logon attempts and account lockouts. The assessor may ask the MSSP: “How would you know if someone was trying to brute-force an account in this environment?” The answer should be specific: “We have an alert that triggers on X failed attempts within Y minutes, here’s the rule, and here’s an example.”
Consistency is everything here. The assessor will mentally walk through every place someone can log in and check that your lockout policy covers all of them. If your SSP says one thing and your configuration says another, pull that apart in pre-assessment prep. Have screenshots of every auth point's lockout settings. This practice is quick to close if you're aligned, but obvious if you're not.
Before the assessment, ask your MSP to verify that the lockout settings across your environment match what your SSP says. It takes 10 minutes to check and can prevent a discrepancy finding that creates unnecessary doubt. The best MSSPs I've worked alongside include this in their pre-assessment checklist as a standard step.
This page covers AC.L2-3.1.8 from NIST SP 800-171 Rev 2 (3.1.8). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.