Skip to main content

Recommended Maximum Failed Sign-In Attempts for Large Learner Groups

  • September 21, 2026
  • 2 replies
  • 42 views
ldlmcoitrg
Influencer I
Forum|alt.badge.img

We currently have the Maximum number of consecutive failed sign-in attempts set to five. We recently learned that when this threshold is reached, Docebo blocks the originating public IP address for 10 minutes, not just the individual user account.

We expect some clients to have between 500 and 1,000 learners, or even more potentially accessing the platform through the same corporate network. During a coordinated launch, several learners could enter incorrect passwords within a short period and unintentionally trigger a lockout affecting everyone on that network.

For organizations supporting large learner populations, what maximum number of failed attempts have you configured? Have you experienced shared public-IP lockouts, and would you recommend a threshold such as 50 or 100?

It would also be helpful to confirm whether a successful login resets the failed-attempt counter for the public IP and whether failed attempts across different usernames are aggregated.

2 replies

Docebian

Thanks for raising this. The setting is applied to the public IP address, not to an individual user account, so learners sharing the same corporate network can be affected when the threshold is reached. The block lasts 10 minutes. See the Managing the password policy article.

There isn’t a universal recommended value such as 50 or 100. For larger learner groups, the value should be based on your expected login volume, the number of learners sharing each public IP, and your security requirements. Reviewing Audit Trail data during a typical launch can help establish an appropriate threshold, but the final decision is at your discretion.

As a practical approach, consider increasing the value rather than setting it to 0, then monitor failed-login activity and adjust as needed. Some larger organizations have used values such as 100 after reviewing their expected login flows, network configuration, and security requirements, but this should not be considered a universal recommendation. SSO is also worth considering for large coordinated launches, since password-policy settings apply to native platform-credential logins, while SSO authentication policies are managed by the identity provider.

 

ldlmcoitrg
Influencer I
Forum|alt.badge.img
  • ldlmcoitrg
  • Author
  • Influencer I
  • October 5, 2026

Thanks for raising this. The setting is applied to the public IP address, not to an individual user account, so learners sharing the same corporate network can be affected when the threshold is reached. The block lasts 10 minutes. See the Managing the password policy article.

There isn’t a universal recommended value such as 50 or 100. For larger learner groups, the value should be based on your expected login volume, the number of learners sharing each public IP, and your security requirements. Reviewing Audit Trail data during a typical launch can help establish an appropriate threshold, but the final decision is at your discretion.

As a practical approach, consider increasing the value rather than setting it to 0, then monitor failed-login activity and adjust as needed. Some larger organizations have used values such as 100 after reviewing their expected login flows, network configuration, and security requirements, but this should not be considered a universal recommendation. SSO is also worth considering for large coordinated launches, since password-policy settings apply to native platform-credential logins, while SSO authentication policies are managed by the identity provider.

 

Thanks for the additional context. Our use case is a bit different, as we use Docebo to support multiple external client organizations rather than as an internal LMS. Client populations can range from approximately 100 learners to 1,000+ learners, and many may be accessing the platform from the same corporate network.

Because the lockout is applied at the public IP level, our concern is that a relatively small number of failed login attempts could impact a much larger group of learners sharing that network.

We've submitted an idea requesting an option to apply lockouts at the individual user level rather than only at the public IP level. I'll add the link below for anyone interested in reviewing or voting for the enhancement.
 

We're also interested in hearing how other organizations with large learner populations have configured this setting and whether they've encountered similar challenges.

Terms & ConditionsAccessibility statement