CMMC Level 2 Practice 3.1.8: Limit unsuccessful logon attempts

To meet cmmc level 2 practice 3.1.8: limit unsuccessful logon attempts requirement, you must configure your systems to detect repeated failed logons and automatically restrict further attempts (for example, by lockout, delay, or throttling), with consistent settings across the CUI environment and evidence that the control operates. This reduces password-guessing risk and is routinely tested during CMMC assessments. ¹

Key takeaways:

• Set an explicit failed-logon threshold and an automated response (lockout, delay, or rate limiting) across all interactive logon entry points.
• Prove coverage: endpoints, servers, remote access, cloud identity, privileged access, and any local accounts in the CUI boundary.
• Keep assessor-ready evidence: configuration baselines, exports/screenshots, exception approvals, and control health checks. ²

CMMC Level 2 Practice 3.1.8 maps to NIST SP 800-171 Rev. 2 control 3.1.8 and expects you to limit unsuccessful logon attempts in a way that is consistently enforced and demonstrable across the systems that store, process, or transmit CUI. ¹

Operators often treat this as a simple “account lockout policy” checkbox. In a CMMC assessment, that approach breaks down fast because assessors will follow the logon path: workstation sign-in, VPN/remote access, cloud SSO, admin consoles, and application-level authentication. If any of those entry points allow unlimited guessing (or your exception process is informal), you have a gap against the requirement. ²

This page gives requirement-level implementation guidance you can hand to IT and IAM teams today: what settings to choose, where to enforce them, how to handle service accounts and break-glass access safely, and what evidence you need to retain so the control is assessable and repeatable. ³

Regulatory text

Requirement (framework mapping): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.8 (Limit unsuccessful logon attempts).” ¹

What the operator must do: Implement technical controls that cap repeated failed authentication attempts for system access. The control must be defined, implemented, and operating across the CUI environment in scope for CMMC Level 2. ⁴

---

Plain-English interpretation

You need to stop attackers (and sometimes misconfigured scripts) from trying passwords indefinitely. After a defined number of failed logons, the system must automatically respond in a way that prevents rapid repeated guessing. Acceptable patterns typically include:

• Account lockout (temporary or admin reset required)
• Increasing delay / throttling after failures
• Rate limiting per account, source, or session
• MFA/step-up challenges after suspicious failures (where supported)

What matters for assessment is that you can show: (1) your standard is documented, (2) it is enforced at the right control points, and (3) exceptions are controlled. ¹

---

Who it applies to (entity and operational context)

Entities: Defense contractors and federal contractors handling CUI that are pursuing or maintaining CMMC Level 2. ⁵

Operational scope: Any system, identity provider, or access pathway that can authenticate a user into the CUI environment, including:

• Endpoint and server interactive logon (local + domain)
• Remote access (VPN, ZTNA, VDI, bastions)
• Cloud identity (SSO, federation, admin portals)
• Privileged access tooling and jump hosts
• Application logons that provide access to CUI (including web apps)
• Local accounts on network devices or appliances if in the CUI boundary

If you have multiple identity stacks (for example, on-prem directory plus cloud IdP), assessors will check that “limit attempts” is not only enforced in one place while bypass paths remain open. ²

---

What you actually need to do (step-by-step)

1) Define the control as an implementable standard (not a policy sentence)

Create a short “control card” your IAM/IT team can execute:

• Objective: Limit unsuccessful logon attempts to reduce brute-force risk.
• Owner: IAM lead (primary), IT operations (secondary), Security (oversight).
• Scope: All authentication entry points into the CUI boundary.
• Enforcement points: OS sign-in, IdP, VPN/remote access, privileged access systems, and in-scope applications.
• Exception rules: Break-glass accounts, service accounts, and operationally critical accounts must have compensating controls and approvals. ²

Daydream (or any GRC system you use) is a practical place to store the control card, assign owners, track exceptions, and attach evidence by system. The assessment problem is rarely “we didn’t set it,” it’s “we can’t prove it across scope.” ²

2) Inventory authentication entry points in the CUI boundary

Build a list of “ways in” and “where auth happens”:

• Identity stores (directory, cloud IdP)
• Remote access systems
• Privileged access path
• Critical apps with their own login pages
• Network devices and management planes

Treat this list as an auditable artifact. Update it when you add a new remote access method, app, or subsidiary domain. ²

3) Choose a failure-handling approach per entry point

Decide how you will “limit attempts” in each technology:

• Centralized (preferred): Enforce at the IdP/directory so applications inherit the control.
• Distributed: If an app has local auth, configure the app directly and document why central auth is not used.

Use one standard where possible. If you must vary by system, document the rationale and keep it consistent within each platform type. ³

4) Implement settings and ensure they cannot be bypassed

Common bypasses to close:

• Local accounts enabled on endpoints/servers while directory policy exists
• A VPN that authenticates locally instead of through the IdP
• Legacy apps with separate credential stores and no lockout/rate limiting
• Admin consoles reachable from the internet without throttling controls
• “Break-glass” accounts that are excluded but not monitored

Implementation is complete only after you confirm enforcement for:

• Normal users
• Privileged users
• Remote access users
• Administrative portals
• Any fallback authentication path (source IP allowlists are not a substitute for limiting attempts). ³

5) Build an exception process you can defend in an assessment

You will have exceptions. Make them controlled:

• Document the business reason (for example, an operational account that would cause downtime if locked)
• Add compensating controls (for example, restricted logon locations, stronger MFA, monitoring/alerting)
• Require security approval and time-bound review
• Store approvals and technical proof in one place

Daydream can help by turning each exception into a tracked item with an owner, expiry, and required evidence attachments. ²

6) Prove operation with recurring control health checks

A control that “was configured once” tends to drift. Establish a lightweight health check:

• Re-confirm settings in the identity platform(s)
• Sample a set of endpoints/servers for compliance with baseline
• Validate VPN/remote access alignment
• Confirm applications with local auth still have rate limiting/lockout enabled
• Review exception list and confirm compensating controls still exist ²

---

Required evidence and artifacts to retain

Keep evidence that answers: What is the standard? Where is it enforced? How do you know it works?

• Control card / standard: failure threshold and response approach; scope statement; owner; exceptions process
• System configuration evidence: exports, screenshots, configuration baselines, or policy objects showing the setting in the IdP/directory, endpoint management, VPN, and any in-scope apps
• Coverage map: a list of authentication entry points and how each is controlled
• Exception register: approved exceptions, compensating controls, reviewer/approver, and review cadence
• Operational proof: tickets/changes for initial rollout, periodic health-check results, and remediation records for drift

Store evidence in a location with controlled access and clear retrieval paths for assessors. ⁴

---

Common exam/audit questions and hangups

Assessors and customer diligence reviewers commonly press on these points:

• “Show me where unsuccessful logon limits are configured for your primary IdP and remote access.” ²
• “Does this apply to privileged accounts and admin portals?” ³
• “Which applications still authenticate locally, and what do you do there?” ²
• “How do you prevent bypass via local accounts?” ³
• “What exceptions exist, and who approved them?” ²
• “How do you know settings did not drift?” ²

Hangup to expect: “We have lockout in the domain, but our VPN uses a separate directory” (or similar split-brain auth). That is a scope coverage problem, not a policy problem. ²

---

Frequent implementation mistakes and how to avoid them

Mistake: Lockout without operational safeguards

If your response is aggressive lockout, users can self-inflict outages and help desks get swamped. Avoid this by pairing lockout with:

• Self-service unlock (where appropriate)
• Clear incident triage for suspected brute force
• Monitoring for repeated failures across many accounts ²

Mistake: Exempting “important” accounts informally

Break-glass and service accounts tend to be excluded without compensating controls. Treat exemptions as risk decisions with documented approvals and periodic review. ²

Mistake: Only covering one logon path

Many environments protect workstation sign-in but miss:

• Web admin consoles
• Remote access gateways
• Legacy apps with local password databases
  Maintain the coverage map and tie it to change management so new entry points cannot ship without controls. ¹

Mistake: No proof of operation

A screenshot from last year is weak evidence. Retain periodic validation outputs and remediation records so you can show sustained operation. ²

---

Enforcement context and risk implications

CMMC Level 2 is a contractual and program requirement for handling CUI in applicable DoD contracting contexts. If you cannot demonstrate this practice, you risk failing the assessment, delaying contract awards, or being required to remediate before certification. Program structure and assessment expectations are established under the CMMC Program. ⁵

From a security standpoint, unlimited authentication attempts raise the likelihood of credential guessing and account compromise, especially on internet-exposed or partner-accessible systems. Limiting attempts is a baseline control that reduces that attack path and improves detection signal quality. ³

---

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign an owner and publish the control card (standard + scope + exceptions workflow). ²
• Build the authentication entry-point inventory for the CUI boundary. ²
• Identify the highest-risk exposure points (remote access, admin portals, externally reachable apps) and confirm they enforce limited attempts. ³

Days 31–60 (Coverage completion)

• Implement or align settings across directory/IdP, endpoints/servers, VPN/remote access, and privileged access systems. ³
• Remediate bypass paths (local accounts, alternate directories, unmanaged authentication). ²
• Stand up the exception register with approvals and compensating controls for necessary exclusions. ²

Days 61–90 (Evidence hardening + sustainment)

• Run a formal control health check and document results, gaps, and closure evidence. ²
• Package assessor-ready evidence by control: standard, coverage map, configs, exceptions, and health-check outputs. ²
• Put the health check and exception review onto your GRC calendar so it repeats and produces consistent evidence. Daydream can track owners, due dates, and attachments per system. ²

Frequently Asked Questions

Do we have to use account lockout, or is throttling acceptable?

The requirement is to limit unsuccessful attempts; the mechanism can vary by platform. Pick a method that prevents rapid repeated guessing and document it per entry point so it is assessable. ³

Does this apply to privileged and break-glass accounts?

Yes, the control applies to accounts that can access the CUI environment, including privileged access paths. If you must exempt break-glass accounts, document the exception and compensating controls with formal approval. ¹

Our applications use SSO; do we still need app-level limits?

If the app fully delegates authentication to your IdP and has no local login, the IdP control may cover it. If any local authentication exists (including admin backdoors), configure limits there or remove the bypass. ²

How do we handle service accounts that can’t tolerate lockout?

Treat service accounts as exceptions with compensating controls such as restricted logon locations, stronger authentication where possible, and monitoring for abnormal failures. Keep the approval and technical configuration proof in your evidence set. ²

What evidence is strongest for a CMMC assessment?

A documented standard plus configuration exports or authoritative screenshots for each enforcement point, along with an inventory showing coverage and an exception register. Add proof of recurring verification to show the control stays in place. ²

Can we meet this requirement with an MFA-only approach?

MFA reduces credential risk, but the requirement specifically addresses limiting unsuccessful attempts. Keep attempt-limiting controls in place even if MFA is deployed, especially for exposed entry points. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. DoD CMMC Program Guidance

3. NIST SP 800-171 Rev. 2

4. DoD CMMC Program Guidance; 32 CFR Part 170

5. 32 CFR Part 170; DoD CMMC Program Guidance