Skip to main content

Recommended Maximum Failed Sign-In Attempts for Large Learner Groups

  • September 21, 2026
  • 1 reply
  • 32 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.

1 reply

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.

 

Terms & ConditionsAccessibility statement