Password Policy Best Practices

This article is educational content about password policy best practices and is not professional compliance advice or legal counsel.

Password policy is where most organizations have requirements that actually reduce security instead of improving it. You're probably enforcing something that research says doesn't work. If your password policy was written more than three or four years ago, it's built on outdated assumptions about what makes passwords secure. The good news is that modern password policy is actually simpler to implement and more effective than the traditional approach of mandatory complex passwords and frequent rotation. The bad news is that it requires letting go of policies that sounded strong but actually made things worse.

The traditional approach sounds logical: require long passwords with mixed case, numbers, and symbols. Require users to change them every 30 to 90 days. Prevent reuse of old passwords. These requirements sound strong, but they create awful security outcomes. When users can't remember 12-character passwords with four character types, they write them down. When mandatory rotation forces them to change passwords every 60 days, they cycle through predictable variations. When policies ban password managers (because of concerns about storing passwords in a third-party service), people reuse weak passwords across accounts. The result is security theater instead of actual security.

Modern password policy is based on research about how passwords are actually compromised. Most password attacks don't try to brute force passwords. They use breached password lists (checking if your password was exposed in someone else's data breach), dictionary attacks (trying common passwords), or social engineering. Length defeats these attacks. Complexity doesn't. Multi-factor authentication defeats stolen passwords even if they're guessed correctly. Mandatory frequent rotation doesn't.

Why Length Matters More Than Complexity

The fundamental insight is mathematical. A brute force attack tries every possible combination. An 8-character password with 4 character types has about 7 trillion possible combinations. A 16-character password with just letters and numbers has about 50 quadrillion combinations. The 16-character simple password is exponentially stronger even though it's "only" letters and numbers.

But brute force attacks are rare now. Most attacks use breached password lists or dictionary attacks. Your password gets compromised in a data breach at some other company. Attackers try it against thousands of other services. They're not trying to guess your password—they're trying passwords they know someone is using. Length still matters enormously for this because passwords that are very long are less likely to be in the breached password lists, and dictionary attacks take longer when passwords are long.

The practical result is that a 16-character password like "mountain blue seventeen coffee" is stronger than an 8-character password like "Kx9$mP2L" even though the second one has mixed case and special characters. The long password is harder to attack, easier for users to remember, less likely to appear in breached password lists, and more practical for password managers.

Some compliance frameworks still require complexity because they were written before this research was well understood. If you're required by regulation to include complexity requirements, include basic ones (at least one number, at least one letter) rather than maximalist requirements. But focus most of your effort on length.

The Rotation Debate: Change When It Matters, Not on a Calendar

Mandatory password rotation—requiring users to change passwords every 30, 60, or 90 days—seems logical. You're limiting the window a compromised password can be used. The problem is that it doesn't work. Studies show mandatory rotation is associated with weaker password behavior. Users either can't remember new passwords and write them down, or they change passwords in predictable ways (adding a number, rotating through variations). The security benefit of rotation doesn't outweigh the security harm of worse password choices.

The National Institute of Standards and Technology, which sets U.S. federal cybersecurity standards, now recommends against mandatory expiration for regular users. Their guidance is that passwords should be changed when there's evidence of compromise, when there's suspicious account activity, when there's a security incident, or when the user suspects their password might be known. This event-triggered approach gets compliance without the downsides of mandatory rotation.

Privileged accounts are different. An administrative account or database administrator account has higher impact if compromised. For privileged accounts, more frequent rotation is reasonable—quarterly or semi-annual rotation is common. A service account password should be rotated if possible, or at least on a regular schedule because service accounts can't be rotated in response to events the way human accounts can.

The practical shift is dramatic. Instead of reminding users every 60 days to change their password, send password change reminders when there's actual reason. Unusual login locations trigger a password change request. Account lockouts trigger a password change request. A suspected breach triggers a password change request. Regular users might go a year without a password change because nothing triggered one. That's fine.

Account Lockout and Brute Force Protection

Account lockout prevents brute force attacks. After someone fails to log in a certain number of times (typically 5-10 attempts), the account locks for a period (15-30 minutes). This prevents someone from endlessly trying passwords. The lockout is automatic and transparent—after the timeout period, the account unlocks.

The policy should specify the threshold and the lockout duration. A threshold of 5-10 failed attempts is reasonable. Too low (3 failed attempts) and legitimate users get locked out frequently. Too high (20+ attempts) and the protection is weak. Lockout duration of 15-30 minutes is reasonable. Long enough to deter brute force, short enough that it doesn't create too much disruption if a legitimate user gets locked out.

The policy should also specify what resets the lockout. Most systems reset the lockout after the timeout period expires, or after a successful login. Some allow help desk staff to manually unlock accounts if a user is locked out outside business hours.

Lockout protection becomes less important when multi-factor authentication is in place. MFA blocks brute force attacks even with the right password because the attacker doesn't have the second factor. If your account is protected by MFA, brute force protection on the password is secondary.

Reuse Prevention and Password History

Password reuse prevention stops you from using the same password multiple times. If your password is compromised in a data breach somewhere and you reused that password, preventing reuse in your current environment limits the damage. If an attacker tries that password against your current systems and account lockout stops them, the attack fails.

Reuse prevention is more important for privileged accounts where the cost of compromise is higher. For regular user accounts, preventing reuse of the last 5-10 passwords is reasonable. Preventing reuse of every password ever used is excessive and makes password changes unnecessarily difficult.

Reuse prevention also motivates the move away from mandatory password changes. If you require users to change passwords every 90 days and prevent password reuse, users either run out of passwords or create predictable patterns. Preventing reuse works when combined with event-triggered changes rather than mandatory changes.

Multi-Factor Authentication: The Control That Really Reduces Risk

Multi-factor authentication is the control that makes passwords less critical. MFA requires something you know (password) plus something you have (phone, hardware key) or something you are (biometric). Stolen passwords alone don't grant access when MFA is enabled.

Your password policy should address MFA requirements. Is MFA required for all users or just privileged users? What counts as a second factor (authenticator app, security key, SMS, push notification)? What happens if someone loses their phone or device?

The practical reality is that SMS is weaker than app-based authenticators or hardware keys (security keys), but it's far better than passwords alone. A policy that requires SMS-based MFA for all users is significantly more secure than a policy with no MFA and perfect password requirements. That said, app-based authenticators or hardware keys are stronger and worth promoting if your organization can support them.

Fallback for MFA is important. Users will lose phones. They'll forget security keys. They'll be traveling without access to their usual device. The policy should define emergency access procedures. Backup codes (printed and stored safely) that can be used instead of a second factor are common. Help desk override for emergency access should be documented and restricted.

Most organizations now require MFA for administrative accounts (because their compromise is high-impact) and encourage or require it for all users. For cloud systems, MFA is becoming standard because it's highly effective against the most common attacks (credential theft, password spraying, phishing).

Password Managers: Tools That Improve Real Security

Password managers are programs or services that generate and store strong unique passwords for every account. Instead of remembering 50 passwords, you remember one strong master password or use biometric unlock. The password manager generates unique, strong passwords for each account and fills them in automatically.

Password managers dramatically improve practical security. They eliminate password reuse—the largest source of account compromise. They enable stronger passwords—password managers can generate 20-character random passwords that humans can't remember. They reduce phishing success—password managers only fill in passwords on the correct domain, not on phishing sites.

Yet some policies explicitly ban password managers, citing concerns about storing passwords in a third-party service. The reasoning is that if the password manager service is compromised, all passwords are exposed. This concern misses the forest for the trees. Password managers with strong encryption are exponentially more secure than the current reality when password managers are banned: people reusing passwords across sites because they can't remember unique ones.

Modern password policy should encourage password managers. Many organizations provide an organizational password manager (sometimes called a secrets vault) for sensitive accounts. Others require employees to use a password manager if they manage more than a few accounts. Single sign-on systems, where one login grants access to many systems, are even better than password managers because they eliminate the need for individual passwords entirely.

The shift in thinking is important. Banning password managers in an attempt to improve security is like banning cars to improve road safety. The alternative (walking or horses) is worse. Supporting password managers is supporting better security.

Recovery and Reset Procedures for Legitimate Access

Users forget passwords. They need reset procedures that are reasonably quick for usability but still secure for safety. The policy should specify what counts as adequate identity verification for a password reset. Options include security questions, email verification, phone verification, manager authorization, or physical identification for in-person resets.

The balance is between usability and security. A process that requires coming in person with ID and security questions is very secure but impractical. A process that only requires clicking "forgot password" and confirming via email is convenient but less secure if someone gains access to the email account.

Most organizations find middle ground: email verification plus security questions, or phone verification plus security questions, or manager authorization after identity verification. The policy should specify the process clearly so help desk staff understand what they're doing and users know what to expect.

The policy should also address emergency procedures. What happens if someone is locked out outside business hours or if help desk is unavailable? Some organizations allow help desk staff to bypass normal verification procedures in true emergencies and then verify identity later. Others allow security questions to be answered in a backup way. The policy should allow the system to function without being so permissive that it creates easy unauthorized access.

Measuring and Monitoring Actual Compliance

Your password policy should be measured. What percentage of users have compliant passwords? How many users are using password managers? How many accounts are getting locked due to failed login attempts? What's the average time from password change request to actual change?

These metrics don't need to be excessive, but they give visibility into whether policy is being followed and whether it's effective. Declining password strength metrics might indicate users are struggling with policy requirements. Increasing lockouts might indicate brute force attacks or policy that's too strict. Increasing password reset requests might indicate that recovery procedures are too cumbersome.

Metrics also help with policy refinement. If 80% of users are compliant with password policy but 90% are using password managers despite policy discouraging them, that tells you something about what works in your organization. Use that information to refine policy toward what's both realistic and effective.

Building Modern Password Policy

You now understand modern password policy best practices: emphasize length over complexity, use event-triggered changes instead of mandatory rotation, implement account lockout to prevent brute force, require or strongly encourage multi-factor authentication, support and encourage password managers, define clear recovery procedures, and measure what's actually happening.

Modern password policy is fundamentally different from policies written five or more years ago. If your policy is older than that, it's almost certainly built on assumptions that research has since disproven. The policies that sound strong often create worse security. The policies that are simpler and less demanding often create better security. The organizations that trust users with reasonable password policies and support them with tools like password managers and multi-factor authentication end up with better actual security than organizations with maximalist requirements that drive people to bad workarounds.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about password policy best practices as of its publication date. Policies should be tailored to your organization's specific environment and regulatory requirements — consult a qualified compliance professional for guidance on policy development.