Password policy: 8 controls for account onboarding

Setting the password policy can be complicated and confusing, and Microsoft provides recommendations to make your organization more secure against password attacks. Microsoft

Understanding human nature is critical because research shows that almost every rule you impose on your users results in a weakening of password quality. Microsoft

Length requirements, special character requirements, and password change requirements all result in normalization of passwords, which makes it easier for attackers to guess or crack passwords. Microsoft

Overly strict or confusing constraints can make it harder for people to create strong and memorable passwords. GOV.UK

When configuring your onboarding flow, balance security needs with user experience to avoid creating normalized passwords. Focus on the eight controls that address these specific risks without adding unnecessary complexity that weakens the overall security posture.

Prioritize password diversity as the primary goal of a secure system, as stated by Microsoft in its password policy recommendations Microsoft. Implement blocklist screening to prevent users from selecting commonly used passwords, a practice recommended by NIST SP 800-63B and cited by OWASP OWASP. Set password length caps based solely on system capabilities, according to NCSC guidance NCSC.

Hide passwords by default until the user chooses to show them using the show button, following GOV.UK design system standards GOV.UK. Avoid revealing whether a username or password was incorrect during login failures, as advised by GOV.UK GOV.UK. Apply a time delay after each account lockout, with permanent account lockout after a maximum of 2-3, following the OWASP recommendations OWASP.

The table below lists the eight security controls with their specific publisher sources. Every row in the table quotes the guidance from the publisher named for that control.

Review your onboarding configuration against these eight rows to identify gaps.

Set your minimum password length based on the practical benefits of longer strings rather than complex character rules. OWASP explains that longer passphrases are effective because they raise the number of guesses an attacker's dictionary or wordlist has to cover, not because of a precise entropy value. This guidance aligns with NIST SP 800-63B, which notes that "estimating entropy for user-chosen passwords is challenging" and recommends length and blocklist checks over composition or entropy math. When configuring your onboarding form, prioritize allowing users to create long, memorable passphrases. According to OWASP, this approach focuses on the total number of potential guesses rather than arbitrary character class requirements.

Implement blocklist screening to prevent users from selecting passwords that are commonly used or already known to attackers. OWASP recommends screening passwords against blocklists as a core security control, citing NIST SP 800-63B – Passwords for this practice. Your system should check new passwords against a list of compromised credentials and common words before accepting them. If a user attempts to use a password found on the blocklist, reject it and prompt them to choose a different one. According to OWASP, this screening helps prevent the selection of weak or breached passwords.

Determine your maximum password length based on your system's capabilities rather than arbitrary limits. NCSC advises that password length should only be capped by the capabilities of your system. This means you should not impose a low maximum length if your database and authentication services can handle longer strings. Check your backend storage and processing limits to see how long a password your infrastructure can securely store and verify. According to NCSC, the cap should reflect technical limits, not convenience.

Update your onboarding form to hide passwords by default and add a link to the password policy page.

When an account reaches its lockout threshold, the system should pause further attempts for a set duration. OWASP specifies the amount of time to delay after each account lockout, followed by permanent account lockout once that maximum of 2-3 is reached. Implement this tiered approach in your onboarding flow to balance security with user recovery options.

For login failures, avoid providing specific feedback about which credential was incorrect. GOV.UK advises that if the user enters their account details incorrectly, do not reveal whether they got the username or password wrong. A generic error message prevents attackers from using trial-and-error methods to isolate valid usernames.

In the password input field, mask the text by default. GOV.UK directs designers to hide passwords by default until the user chooses to show it using the ‘show’ button. This protects credentials from shoulder surfing or screen recording while allowing users to verify their input when needed.

NIST provides context for setting attempt limits in authenticator scenarios. NIST explains that the limit of 100 was chosen to balance the likelihood of a correct guess, such as 100 attempts against a six-digit decimal OTP authenticator output, with the potential need for account recovery when the limit is exceeded. While this specific number applies to OTP authenticators, the rationale supports defining clear thresholds for password attempts in your onboarding forms.

Configure your error states to align with these standards. Use a single, non-specific error message for all failed login attempts. Implement a delay mechanism that escalates from temporary pauses to permanent lockouts after a defined number of failures. Ensure your password fields are obscured by default with an explicit toggle for visibility. These settings create a consistent security posture that protects user data without creating unnecessary friction during the initial account setup phase.

The fourth control addresses what happens after a user changes their secret. GOV.UK states that you must always email the user when a password reset has happened, in case it was triggered by someone else trying to get into their account GOV.UK. This alert serves as a safety net for the account holder. If a user did not initiate the reset, the notification signals a potential unauthorized access attempt. Your onboarding flow should include this automated message immediately after the reset action completes. Do not rely on the user to notice the change themselves. The email should be clear and direct, informing them of the action taken on their account.

The seventh control shifts the focus from password complexity to variety across users. Microsoft notes that the primary goal of a more secure password system is password diversity Microsoft. This perspective suggests that having many different passwords across users is more critical than forcing every single password to meet strict character rules. When you design your onboarding policy, consider how to encourage unique secrets rather than just long or complex ones. Diversity reduces the risk that one breached password compromises multiple accounts. Your system should treat each user's password as a distinct entity. Avoid policies that inadvertently encourage users to reuse similar patterns.

Use this blank worksheet to audit your current onboarding password settings against the standards cited in this guide. Compare each of the eight controls with your current onboarding password settings and note where the setting does not match the guidance from the named publisher for that control in your onboarding flow.

Fill each row with your current implementation details. Your setting matches that control only when it follows the publisher's stated guidance for the control you are checking during this onboarding audit. Write down exceptions and later changes for the control so you can see what still differs from the cited guidance in your onboarding flow. This audit helps you identify gaps between your current onboarding flow and the eight official controls discussed in this article.

• Onboarding tools: compare 4 customer project plans
• Health score setup: 8 rules for weights and validity
• NPS survey configuration: 5 checks before launch

Should I force users to change passwords regularly?

Some services force users to change their passwords regularly, for example every month, according to GOV.UK. However, Microsoft warns that this practice can lead to password normalization, where users create predictable variations. You should evaluate whether regular forced changes are necessary for your specific risk profile.

What is the recommended delay after an account lockout?

OWASP recommends an amount of time to delay after each account lockout, and then a permanent account lockout only after a maximum of 2-3, according to OWASP. This delay helps mitigate brute-force attacks by slowing down automated guessing. Implement this timing in your authentication logic to protect user accounts.

Do I need to reveal which field was wrong on login failure?

If the user enters their account details incorrectly, do not reveal whether they got the username or password wrong, according to GOV.UK. This prevents attackers from enumerating valid usernames by testing different password combinations. Use a generic error message that indicates the login failed without specifying which field was incorrect.

Why are longer passphrases preferred over complex ones?

Longer passphrases are effective because they raise the number of guesses an attacker's dictionary or wordlist has to cover, according to OWASP. NIST notes that estimating entropy for user-chosen passwords is challenging, and the same NIST guidance recommends length and blocklist checks over composition or entropy math. Focus on length rather than forcing complex character combinations.

Should passwords be hidden by default in the input field?

Hide passwords by default until the user chooses to show it using the ‘show’ button, according to GOV.UK. This protects users from shoulder surfing and other physical observation attacks. Ensure your UI includes a clear toggle for users to reveal their password if needed.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.