Password Policy Best Practices

Reviewed by Fully Compliance editorial staff. Updated March 2026.

Modern password policy prioritizes length over complexity, event-triggered changes over mandatory rotation, and multi-factor authentication over password strength alone. NIST SP 800-63B now recommends against mandatory periodic rotation for regular users. Organizations that support password managers and require MFA achieve significantly better security outcomes than those enforcing traditional complex-password-plus-rotation requirements.

Traditional Password Policies Create Worse Security Outcomes

Password policy is where most organizations have requirements that actually reduce security instead of improving it. If your password policy was written more than three or four years ago, it is built on outdated assumptions about what makes passwords secure. The traditional approach sounds logical: require long passwords with mixed case, numbers, and symbols, require users to change them every 30 to 90 days, and prevent reuse of old passwords. These requirements sound strong, but they create measurably worse security outcomes.

When users cannot 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. A 2024 study by the Bitwarden Password Decisions Survey found that 62% of employees reuse passwords across work and personal accounts, a behavior directly driven by overly complex password requirements that make unique passwords impractical to remember.

Modern password policy is based on research about how passwords are actually compromised. Most password attacks do not 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 does not. Multi-factor authentication defeats stolen passwords even if they are guessed correctly. Mandatory frequent rotation does not.

Length Defeats Attacks That Complexity Cannot

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 is "only" letters and numbers.

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 are not trying to guess your password; they are trying passwords they know someone is using. Length still matters enormously because passwords that are very long are less likely to appear in 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 are required by regulation to include complexity requirements, include basic ones (at least one number, at least one letter) rather than maximalist requirements. Focus most of your effort on length.

Event-Triggered Rotation Replaces Calendar-Based Rotation

Mandatory password rotation, requiring users to change passwords every 30, 60, or 90 days, does not work. Studies show mandatory rotation is associated with weaker password behavior. Users either cannot remember new passwords and write them down, or they change passwords in predictable ways. The security benefit of rotation does not outweigh the security harm of worse password choices.

NIST SP 800-63B, 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 is evidence of compromise, when there is suspicious account activity, when there is a security incident, or when the user suspects their password might be known. This event-triggered approach gets the security benefit of password changes without the downsides of mandatory rotation. Microsoft's own research found that mandatory periodic rotation led to a 46% increase in help desk calls for password resets with no measurable reduction in compromise rates.

Privileged accounts are different. Administrative accounts and database administrator accounts have higher impact if compromised. For privileged accounts, more frequent rotation is reasonable: quarterly or semi-annual rotation is common. Service account passwords should be rotated on a regular schedule because service accounts cannot respond to event-based triggers the way human accounts can.

The practical shift is dramatic. Instead of reminding users every 60 days to change their password, you send password change reminders when there is actual reason. Unusual login locations trigger a password change request. Account lockouts trigger investigation. A suspected breach triggers a password change. Regular users might go a year without a password change because nothing triggered one. That is fine and reflects better security practice than forced rotation.

Account Lockout Stops Brute Force Without Blocking Legitimate Users

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, and after the timeout period, the account unlocks.

The policy should specify the threshold and 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 does not create too much disruption if a legitimate user gets locked out. The policy should also specify what resets the lockout. Most systems reset after the timeout period expires or after a successful login. Some allow help desk staff to manually unlock accounts.

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 does not have the second factor. If your accounts are protected by MFA, brute force protection on the password is secondary defense.

Password Reuse Prevention Works Best with Event-Triggered Changes

Password reuse prevention stops users from recycling the same password. If a password is compromised in a data breach and the user reused that password, preventing reuse in your current environment limits the damage. Preventing reuse of the last 5-10 passwords is reasonable for regular user accounts. Preventing reuse of every password ever used is excessive and makes password changes unnecessarily difficult.

Reuse prevention is more important for privileged accounts where the cost of compromise is higher. 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 best when combined with event-triggered changes rather than mandatory rotation.

Multi-Factor Authentication Is the Control That Actually 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 do not grant access when MFA is enabled. According to Microsoft's 2024 Digital Defense Report, MFA blocks 99.2% of automated account compromise attacks.

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? SMS is weaker than app-based authenticators or hardware keys, but it is 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.

Fallback for MFA is important. Users will lose phones. They will forget security keys. They will 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 is highly effective against the most common attacks: credential theft, password spraying, and phishing.

Password Managers Improve Security, Not Weaken It

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, which is the largest source of account compromise. They enable stronger passwords because password managers can generate 20-character random passwords. They reduce phishing success because password managers only fill in passwords on the correct domain, not on phishing sites.

Some policies explicitly ban password managers, citing concerns about storing passwords in a third-party service. This concern misses the point. Password managers with strong encryption are exponentially more secure than the alternative when password managers are banned: people reusing passwords across sites because they cannot remember unique ones. Modern password policy should encourage password managers. Many organizations provide an organizational password manager for sensitive accounts. Single sign-on systems, where one login grants access to many systems, are even better because they eliminate the need for individual passwords entirely.

Recovery Procedures Balance Usability with Security

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

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 are doing and users know what to expect. The policy should also address emergency procedures for lockouts outside business hours or when help desk is unavailable. Backup codes, security question fallbacks, and documented override procedures keep the system functional without being so permissive that they create easy unauthorized access.

Measure Whether the Policy Is Working

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? These metrics give visibility into whether policy is being followed and whether it is effective.

Declining password strength metrics might indicate users are struggling with policy requirements. Increasing lockouts might indicate brute force attacks or policy that is too strict. Increasing password reset requests might indicate recovery procedures are too cumbersome. If the majority of users 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 is both realistic and effective.

Modern password policy is fundamentally different from policies written five or more years ago. If your policy is older than that, it is 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.

Frequently Asked Questions About Password Policy

Should we still require special characters in passwords?
Basic composition requirements (at least one number and one letter) are reasonable and satisfy most compliance frameworks. Requiring multiple special characters, mixed case, and numbers drives users toward short, predictable passwords. NIST SP 800-63B recommends checking passwords against known-breached password lists rather than enforcing complex composition rules. Length is the more effective lever.

Is 90-day password rotation still required for compliance?
It depends on your framework. NIST no longer recommends mandatory rotation for regular users and instead recommends event-triggered changes. PCI DSS 4.0 still requires password changes at least every 90 days for accounts without MFA, but allows longer intervals when MFA is in place. HIPAA does not specify rotation frequency. Check your specific regulatory requirements, but the industry trend is strongly toward event-triggered rotation.

What MFA method should we require?
Authenticator apps (TOTP) and hardware security keys (FIDO2/WebAuthn) are the strongest options. SMS-based MFA is weaker because of SIM-swapping attacks but is still dramatically better than no MFA. For most organizations, requiring any form of MFA is more important than debating which form. Start with whatever your users will adopt, then migrate to stronger methods over time.

Should we ban password managers?
No. Banning password managers forces users to either reuse passwords or write them down, both of which create greater risk than any concern about the password manager itself. Enterprise password managers with strong encryption, zero-knowledge architecture, and audit logging are a security improvement for every organization. Provide an organizational password manager and require its use for work accounts.

How do we handle service account passwords?
Service accounts cannot respond to event-triggered password changes because they are not operated by humans. Rotate service account passwords on a regular schedule (quarterly is common). Use secrets management tools where possible to automate rotation. Service accounts should have the minimum privileges necessary and their access should be logged and reviewed regularly.