AC.L2-3.1.8 Unsuccessful logon attempts: evidence and audit

What AC.L2-3.1.8 requires for failed logons

A Level 2 self-assessment, or a future certification assessment, needs two things for AC.L2-3.1.8: a defined rule that limits consecutive failed logon attempts, and proof that the system actually enforces it. Limiting unsuccessful logon attempts means the system stops allowing guesses after a set number of failures, usually by locking the account for a period or until an administrator unlocks it. The requirement addresses brute-force and password-guessing attacks, where an attacker tries many passwords against a known username until one works. The organization sets the threshold and the lockout behavior based on its own risk profile, so the decision you need to document is the number of permitted failures, the lockout duration or unlock method, and who owns exceptions. The fewer attempts permitted, the stronger the control, but a threshold that is too low can lock out legitimate users and create help desk load, so the choice should be reasoned and written down.

The hard part is consistency. When identity sits in one directory, one policy covers the environment. When applications, file shares, VPN gateways, Linux hosts and cloud consoles each keep their own sign-in logic, a single lockout rule can be enforced in some places and silently absent in others. Assessors test the mechanisms that enforce the policy, so a rule that exists only in a document will not satisfy the objectives. Inventory every system that accepts a password, confirm which ones delegate authentication to a central identity provider, and record the lockout settings for the rest. Centralized options such as authentik, which can act as an identity provider for applications over OAuth2, OpenID Connect, SAML, LDAP and RADIUS, or FreeIPA for Linux and UNIX sign-in, can reduce that gap, but you should confirm each product's lockout behavior in your own configuration.

AC.L2-3.1.8 is worth 1 point under 32 CFR 170.24. Because it is not on the exclusion list in 32 CFR 170.21, it can sit on a plan of action and milestones for Conditional Level 2 status if the overall score is at least 88 of 110, with closeout due within 180 days. Treat that as a fallback, not a plan, because an unenforced lockout rule is usually simple to fix and easy for an assessor to find. Confirm the current status of the CMMC phase schedule and the assessment requirements with your contracting officer and the DoW CIO guidance before you plan around any POA&M path.

Which systems and accounts fall under the lockout rule

Before setting a lockout threshold, the organization has to decide which logon paths count as in scope for AC.L2-3.1.8. Each path it includes adds a defined mechanism that must be configured, documented and shown to work, so the scoping decisions below drive how many lockout policies exist and what evidence each one needs.

In-scope systems that accept logons

Every system inside the CUI assessment boundary that accepts a password or other logon, such as servers, workstations, databases and line-of-business applications, falls under 3.1.8. Inventory each one and record whether it enforces lockout natively or depends on a central service. A system with local accounts that bypasses the central policy needs its own defined setting, and assessors will test it separately. Ask which systems have local administrator logons that were never migrated.

Directory and identity providers

A central directory or identity provider often carries most of the lockout logic for the systems that sign in through it. Once applications delegate sign-in to it, one lockout policy can cover many applications, but that policy must be defined in writing and its settings preserved as evidence. Confirm whether lockout is enforced in the provider, in each application, or both, because a gap in either layer leaves a path unprotected.

Remote access gateways

VPN concentrators, remote desktop gateways and zero-trust access proxies accept logons from outside the network and are common targets for password guessing. Each gateway is a separate logon path, so it needs its own threshold or a documented reliance on the identity provider's lockout. Check that the gateway counts failures from the same account across repeated sessions, and that its lockout events reach the audit records.

Cloud tenants holding CUI

A cloud tenant that stores or processes CUI is in scope even when the organization does not run the underlying servers. The tenant's built-in lockout behavior is set by the provider, so the organization must identify which settings it can configure, record them, and show that they apply to every user type. Confirm how the provider reports lockout events and whether the organization can export them to its own log store.

Service and administrator accounts

Privileged and service accounts often sit outside normal lockout rules because a lockout can stop a business process or an administrator at a critical moment. Decide explicitly which of these accounts are exempt, document the compensating control for each exemption, and monitor failed logons against them. An undocumented exemption for an administrator account is one of the findings most likely to draw assessor questions.

Third-party and external logon paths

Vendor support portals, managed service provider consoles and partner single sign-on can accept logons to systems inside the boundary. Each external path that authenticates to an in-scope system must either follow the organization's lockout policy or be covered by a documented agreement that shows the external party enforces an equivalent one. Ask each provider how it locks accounts and for written confirmation of its unlock process.

How an assessor tests the lockout control

This table maps the two NIST SP 800-171A objectives for 3.1.8 to what an assessor does, the evidence requested and the findings that usually cause a requirement to fail. Read it as a checklist for proving both that the organization defined its lockout rule and that the rule runs on every system in scope.

Assessment step	What the assessor checks	Evidence requested	Common finding
Objective 1: define the means	Whether the organization has defined how it limits unsuccessful logon attempts, including the threshold and the lockout duration or unlock method	Written logon policy or standard stating the attempt threshold, lockout behavior and unlock rule, tied to the organization's risk profile	No numeric threshold is stated, or the policy says only that lockout exists
Objective 1: approval and scope	Whether the defined means covers every system and account type in the assessment boundary, including privileged and service accounts	System security plan entries and an inventory of systems that enforce logon limits	Policy approved, but some applications or admin consoles are not mentioned
Objective 2: implement the means	Whether the defined threshold and unlock behavior are configured and enforced on each in-scope system	Configuration exports or screenshots from directory, identity provider and endpoint settings showing the active values	Lockout set on the directory but not on the identity provider, VPN or local administrator accounts
Objective 2: test enforcement	Whether the assessor can trigger a lockout and see the expected result in logs	Test records showing failed attempts, the lockout event and the unlock, plus audit records of those events	No logs of lockout events, or logs exist but nobody can show the unlock path
Unlock procedure	Whether locked accounts unlock by an administrator or automatically after the set period, as documented	Help desk runbook or unlock procedure with approval steps and the record of recent unlocks	Unlock is done informally by phone with no documented verification of identity
Final form of evidence	Whether evidence is final and current rather than drafted or out of date	Dated, approved policy and configuration captures taken during the assessment window	Draft policy or configuration screenshots that predate a recent system change

Steps to define and enforce the lockout rule

This sequence turns the lockout requirement into a documented, tested setting on every system that accepts logons. Each step produces a record an assessor can check against the two assessment objectives for AC.L2-3.1.8.

Inventory every logon point
The compliance lead and system owners list each place a user or process can sign in within the CUI assessment boundary, including operating systems, directories, databases, web applications, VPN and remote access gateways, and administrative consoles. Each entry records the platform, who owns it, and whether it authenticates locally or delegates to a central identity provider. The inventory is complete when every account store that can accept a logon appears once, and an owner has signed off on it. Gaps found here usually explain later audit findings, so treat this list as the scope for everything that follows.
Set the threshold and lockout duration
The risk owner, usually the CISO or system owner with input from the compliance lead, chooses how many consecutive failed attempts trigger a lockout and how long the lockout lasts. The CMMC Assessment Guide leaves these values to the organization's risk profile and notes that fewer permitted attempts give stronger protection, so the rationale should be written down alongside the numbers. Record the chosen values in the system security plan or the access control standard, with the approver and date. This step is done when one approved value exists for each class of system, and no system is left on a vendor default that nobody reviewed.
Choose administrator or automatic unlock
Decide how a locked account returns to service. The assessment guidance allows either an administrator to unlock the account or an automatic unlock after a set interval. Administrator unlock gives the help desk a verification step before reactivation, while automatic unlock reduces support load but relies on the timer being configured correctly. Many organizations use one method for user accounts and a stricter method for privileged accounts, and that choice should be written into the same standard. The step closes when the unlock method for each account class is documented and the help desk procedure matches it.
Configure each system or the central identity provider
The platform engineering team applies the approved threshold and unlock settings in each system's native configuration, or once in a central identity provider where applications delegate sign-in. For example, a directory service or an identity provider such as authentik can enforce lockout for every application that uses it, while standalone applications need their own settings. Configuration changes go through the normal change control process so the before and after states are recorded. The step is complete when exported configuration files or screenshots show the approved values on every system in the inventory.
Log lockout and unlock events
Confirm that each lockout, unlock and failed logon attempt writes an audit record to a central log store with a reliable time stamp and the account identifier. Lockout events are the evidence that the mechanism actually fired, so a configuration that never logs anything will be hard to defend. Check that the audit logs are retained and protected under the organization's audit policy. The step closes when a sample lockout in each system appears in the central log with the expected fields.
Test lockout behavior on each system
The compliance lead or an independent tester triggers failed logons against a test account on each system in the inventory and confirms that the account locks at the approved threshold, stays locked for the approved duration or until an administrator unlocks it, and then recovers as designed. Tests should be run in a non-production environment or against a dedicated test account so real users are not affected. Save the test date, the account used, the attempts made, the observed result, and the tester's name. A failed test is not a finding to hide: record it, fix the configuration, and retest.
Document outputs and map them to the objectives
Assemble the outputs into one evidence package: the approved standard, the system security plan entry, the logon point inventory, configuration exports, log samples, and test records. Map each item to the two assessment objectives in NIST SP 800-171A, which cover defining the means of limiting unsuccessful logon attempts and implementing that defined means. The package is ready when an assessor could follow the trail from the approved rule to the enforced setting to the logged proof without asking the system owner for explanation. Keep the package in final form, since drafts do not count toward a MET result.

How to choose a threshold your assessor will accept

The CMMC Assessment Guide for Level 2 does not give a number. It leaves the lockout threshold to the organization's risk profile and notes that fewer permitted attempts give higher security. That means the assessor will not check whether your number matches a published value. They will check whether you chose a value deliberately, wrote down why, and configured the system to enforce it. Start by stating the threshold and the lockout behavior in the system security plan, including the number of consecutive failures that triggers a lock, whether the lock is released by an administrator or automatically after a set time, and which systems the rule covers. Then record the reasoning in terms of the risk you are managing, such as how exposed your remote access and external authentication points are to password guessing. An assessor reading a threshold with no stated rationale is more likely to question it than one with a short, clear argument tied to your environment.

Privileged and service accounts often need different handling, but only when you can justify it. A stricter threshold for administrator accounts is a common position, because a compromised privileged account carries more risk. Service accounts are harder: a strict lockout can stop automated processes and create outages, so some organizations instead remove interactive logon from service accounts, restrict where they can authenticate, and alert on repeated failures. Whatever you choose, document each exception, the account types it covers, and the compensating control that keeps the requirement met for those accounts. Confirm with your assessor how they expect exceptions to be recorded before you rely on them, since an undocumented exception is treated the same as no control.

Every threshold has a help desk cost. A low number with a short lock period will generate more tickets from users who mistype passwords or from accounts locked by stale credentials on mobile devices and scheduled tasks. A high number reduces that load but gives an attacker more guesses before the lock engages. Measure the current lockout volume in your identity provider or directory logs for a representative period before you commit to a value, and agree with the help desk on the unlock procedure, including how identity is verified before an administrator releases an account. Ask your identity platform team to confirm exactly which settings the product exposes for lockout and unlock, because the features differ across directory and identity products, and the evidence you collect should come from the same configuration you describe in the plan.

Evidence that passes for account lockout

Assessors test AC.L2-3.1.8 in two steps: whether the organization defined how it limits failed logons, and whether that definition is implemented on every system that handles CUI. The five artifacts below connect those steps, so each one should trace back to the same lockout standard and be dated and final before the assessment begins.

Written lockout standard

This is the document that defines the means of limiting unsuccessful logon attempts, including the threshold, the lockout duration or unlock method, and which systems it covers. The CMMC Assessment Guide leaves the threshold to the organization's risk profile, so the standard should record the reasoning behind the chosen number. Confirm that it is approved, versioned, and assigned an owner. A draft policy does not count as final evidence.

Configuration exports from each logon system

Export the lockout settings from every system that authenticates users to CUI, including the identity provider, directory service, operating systems, VPN and remote access gateways, and cloud admin consoles. Each export should show the threshold, the reset window and the unlock behavior. Compare the exports against the written standard, because a single system with a looser setting is the most common gap an assessor finds.

Lockout and unlock audit records

Retain logs that show failed logons, lockout events, and unlock actions, with time stamps and the account or device identifier. These records prove the mechanism runs in production, not only in configuration. Confirm that logs from each authenticating system reach your central log store and that retention meets your audit policy. Gaps in the record for a period usually prompt questions about whether the control was active.

Unlock procedure records

Where locked accounts unlock through an administrator, keep tickets or approvals showing who unlocked the account, when, and why. Where accounts unlock automatically after a set time, keep the configuration that sets that time and sample logs showing it working. Assessors look for unlock activity that matches the standard. Unexplained administrative unlocks can suggest the threshold is being bypassed.

System security plan entries

The system security plan should describe the lockout standard, name each system it applies to, and point to the configuration exports and log sources that show it working. Update the plan whenever a system is added, a threshold changes, or a new authentication path such as a federated application is introduced. A plan that describes controls the environment no longer matches is a finding in its own right.

Enforcing lockout with self-hosted identity tools

Applications that delegate sign-in to authentik send their login decisions to the identity provider, so the lockout behavior is set once for every connected application instead of separately inside each one. authentik supports applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, which means legacy applications can be placed behind it as well as modern ones. Lockout is a setting your team must confirm in your own deployment, because the supplied product facts do not describe its lockout features.

Central enforcement: Confirm which login flow and policy governs each application, and that no application keeps a local password store that bypasses it.
Protocol coverage: List every application using each provider type, including any LDAP or RADIUS clients that authenticate directly.
Threshold and unlock settings: Record the failed-attempt limit your risk profile sets, the lockout duration or administrator unlock method, and where those values are stored.
Change control: Keep the configuration under version control or change records so assessors can see when the threshold changed and who approved it.
Test results: Retain test logins showing the account locks after the threshold and unlocks by the method you documented.

For each application, check that the lockout you documented is the lockout users actually encounter during a test sign-in.

What meeting AC.L2-3.1.8 costs in effort and tooling

This table breaks down the effort behind AC.L2-3.1.8 by cost component, showing who does the work, whether it is one-time or recurring, and what makes it grow. Use it to scope a quote, because the largest recurring items are evidence upkeep and identity platform administration rather than the lockout setting itself. No dollar figures are shown because none were supplied for this topic.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Lockout policy writing	Internal security or compliance lead, optionally an outside consultant	One-time, reviewed yearly	Number of system types and whether one standard threshold covers them all
Identity configuration engineering	Internal platform team or implementation partner	One-time per system, plus changes	Number of logon systems and identity sources such as directories, SSO and local accounts
Testing across systems	Internal IT or implementation partner	One-time, repeated after changes	Count of applications, operating systems and cloud tenants that enforce their own lockout
Log retention for failed logons	Internal operations team, storage cost paid to the provider or hardware owner	Recurring	Log volume, retention period set by the organization, and whether logs ship to a central store
Evidence upkeep	Internal compliance owner, sometimes supported by a partner	Recurring	How often settings change, how many systems need fresh screenshots or exports, and version control discipline
Assessor sampling support	Internal staff who pull evidence during the assessment	Recurring at each assessment	Number of systems the assessor selects and how quickly evidence can be produced in final form
Licensing for identity and monitoring tools	Software vendor, unless the organization runs open-source tools	Recurring where commercial licenses apply	Open-source identity providers and monitoring agents can remove license spend, but labor and hosting remain
Hosting and maintenance of self-hosted tools	Internal team or retained support provider	Recurring	Patch cadence, high-availability design and the number of tenants or sites to operate

Who owns the lockout control, the partner and the assessor

Your organization owns the control. Only you can decide how many consecutive failed logon attempts the system permits before it limits access, because the CMMC Assessment Guide leaves that threshold to the organization's risk profile. A lower number gives stronger protection but raises the chance of legitimate users being locked out, so the decision belongs to the people who understand your user base and threat model. Your team also writes the decision into the system security plan and keeps it current when the system changes.

Threshold decision: Record the chosen number of attempts, the reasoning behind it and who approved it.
Unlock method: Decide whether locked accounts unlock through an administrator, automatically after a set time, or both, and document the rule.
System security plan: Describe how the lockout is enforced, which systems it covers and who maintains the setting.
Exception handling: Define how service accounts, break-glass accounts and remote users are treated.
Ongoing review: Assign an owner to revisit the threshold after incidents, identity changes or scope changes.

Before any assessment, confirm that the threshold, unlock method and owner appear in one consistent set of documents.

Where lockout controls usually fail assessment

Most failed assessments for AC.L2-3.1.8 do not involve a missing lockout feature. They involve a lockout that applies to some logon paths but not others, or a lockout that cannot be explained or proven. The cards below cover the gaps assessors find most often, each with a closing action the organization can take before the assessment.

No written lockout threshold

The requirement leaves the number of permitted failed attempts to the organization's risk profile, so the organization must choose a value and write it down. Assessors look for a defined threshold, the lockout duration or unlock method, and the reasoning behind them. A setting that exists only in a configuration file, with no policy that names it, leaves the assessor with nothing to test against. Close it by approving a written standard that states the threshold, the lockout period and who may unlock accounts.

Lockout enforced only on the directory

Many environments lock accounts in the central directory while legacy applications, network appliances, VPN concentrators or local console logons accept unlimited password guesses. An assessor testing one of these paths can find the requirement unmet even when the main sign-in works correctly. Each system that accepts a password is a logon path that needs its own check. Close it by listing every logon path in the system security plan and testing a deliberate run of failed attempts against each one.

Undocumented administrator unlocks

When locked accounts are unlocked by hand, the unlock process often lives in an administrator's memory or in chat messages. Assessors ask who may unlock accounts, how requests are verified and whether the unlock is recorded. If the automatic unlock timer is also set differently across systems, the actual behavior cannot be explained. Close it by writing the unlock procedure, requiring a ticket for each manual unlock and confirming the automatic unlock period matches the written standard.

Missing lockout logs

Lockout behavior is only provable if the system records failed attempts and lockout events. Assessors commonly request configuration settings and audit records as evidence for this requirement. Logs that roll over quickly, or that are sent to no central location, make it impossible to show that the control worked during the assessment period. Close it by confirming that failed logons and lockouts reach a central log store and that retention covers the period the assessor will review.

Cloud and remote portals outside identity

Remote access gateways, cloud consoles, hosted email and vendor portals sometimes keep their own local accounts with their own retry rules. These portals sit outside the identity provider, so a lockout policy applied to the core directory does not reach them. Assessors test the mechanisms that enforce the policy, which includes these front doors. Close it by inventorying every portal that accepts a username and password, then routing each one through the identity provider or confirming its native lockout settings match the standard.

Questions buyers ask about the lockout requirement

Can a self-hosted setup meet AC.L2-3.1.8 without buying a license?

Often yes, because the requirement is about the behavior of your logon mechanisms, not about a particular product. Lockout can be configured in open-source identity providers and directories, and in the operating systems and applications you already run. The costs that remain are mainly labor for design, configuration, testing and documentation, plus the infrastructure you host the tools on. Before you rely on a no-license approach, confirm that each platform in your boundary can enforce a threshold and an unlock method, and that the settings can be shown in configuration evidence. Where an application cannot enforce lockout itself, it should delegate sign-in to a central provider that can. Ask any partner to list which components are open source, which carry commercial licenses, and what each one needs to run.

How long does it take to put account lockout in place?

The duration depends on drivers rather than a fixed figure. The main ones are how many systems sit inside your CUI boundary, how many of them have their own logon paths, whether they already share a central identity source, and how much of the lockout behavior must be tested on each platform. Teams that already use a single directory for sign-in usually have less to change. Teams with local accounts on servers, network devices or legacy applications need more time to inventory and configure each one. Time also depends on how quickly the organization can agree on a threshold and an unlock method, since that decision is owned internally. Ask for a written schedule tied to a defined scope so that each drive can be checked against the work.

What must our team provide before an engagement starts?

Your team owns the decisions and the records, so the list is mostly internal. You need a current inventory of systems that handle CUI and the logon paths into each one, including local accounts, remote access and applications. You also need a documented lockout policy that states the threshold you chose based on your risk profile, the unlock method (administrator or automatic after a set time), and who approves exceptions. Finally, you need administrator access to the identity providers, directories and endpoints in scope, and a named owner who can approve configuration changes. Without these inputs, any partner will be guessing at your risk tolerance and your boundary.

Can a partner handle AC.L2-3.1.8 alone?

A partner can design, configure and document the lockout mechanisms, test them, and prepare the evidence. A partner cannot own the control, and cannot decide your threshold or accept the risk on your behalf. Only an independent assessor can judge whether the requirement is met, and the Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your environment and prepares systems and evidence for assessment, but it does not issue reports or certificates. Your internal staff still need to operate the controls after the work is done.

How does a POA&M apply to this 1-point requirement?

AC.L2-3.1.8 is worth 1 point under the scoring in 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21(a)(2)(iii). That means it can be placed on a plan of action and milestones if your score is at least 88 of 110, which is the threshold the rule sets for Conditional Level 2 status. The POA&M must close within 180 days. Because the item is small in points, it is often treated as a quick fix, but you still need a documented plan, an owner and proof of closeout. Keep in mind that the Department of War suspended CMMC Phase II on 13 July 2026, so confirm with your contracting officer how current rules apply to your contracts before you rely on any POA&M timing.

What evidence will an assessor check for lockout settings?

Assessors look for both a defined means and an implemented means. Expect to show a written policy with the threshold and unlock method, configuration settings from each system in scope, and audit records that show failed attempts and lockouts occurring as designed. The assessment objectives in NIST SP 800-171A also point to procedures and testing of the enforcing mechanisms, so an assessor may attempt failed logons in a controlled test. Evidence should be final and dated, not a draft. Include the identity provider configuration, directory policy, and the settings on any local accounts that remain, and document how each was verified.

Which open-source tools help show lockout evidence?

Several tools can support different parts of the evidence. authentik acts as an identity provider for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications can delegate sign-in to it and inherit one set of rules. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, which gives a central place to manage those accounts. Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom checks, so you can confirm that lockout settings are present on each host. Fleet policies ask yes or no questions of devices as osquery queries, and its policies page shows which devices pass or fail each policy. Confirm that each tool supports the specific lockout setting your platform uses before you rely on it.

How DeployOpen prepares lockout controls and evidence

DeployOpen's part in AC.L2-3.1.8 is to prepare the systems and evidence, while the organization owns the lockout policy and the independent assessor makes the determination. The work starts with a written, fixed-scope agreement that names each system that authenticates users with CUI access, including the identity provider, directory, endpoints and any application that handles its own logons. Scope matters here because an application that keeps a separate password store can defeat a lockout rule set elsewhere, so the agreement should list every login path and state which ones delegate to the central identity service.

Inside the client's own cloud accounts, data centers or air-gapped network, DeployOpen configures the self-hosted tooling that enforces the threshold and the unlock behavior. Depending on the environment, that may include authentik as the identity provider for applications over OAuth2, OpenID Connect, SAML, LDAP or proxy providers, FreeIPA for Linux and UNIX sign-on, and Wazuh Security Configuration Assessment or Fleet policies to check that endpoints still carry the expected settings. The threshold, lockout duration and unlock method (administrator or timed) come from the organization's risk decision. DeployOpen will confirm each product's exact lockout options against current documentation during configuration rather than assume them.

The evidence package is then assembled for the assessor: the written lockout decision, configuration exports, test records showing an account locks after the defined number of failures, unlock records, and audit entries. DeployOpen does not issue audit reports, attestations or certifications. Only an independent assessor can determine whether 3.1.8 is met, and the organization must hold the final evidence. Quotes follow from the written scope, so ask for the list of systems, login paths and evidence items to be stated in the agreement before work begins.

AC.L2-3.1.8 Unsuccessful logon attempts