A password policy should make accounts harder to compromise without making secure behavior unnecessarily difficult. The best policies are clear, practical, and aligned with how people actually work. They encourage long, unique passwords, support password managers, require multi-factor authentication where appropriate, and remove outdated rules that push users toward predictable behavior.
This article explains the do's and don'ts of a modern password policy, what to avoid, best practices to follow, and a copy-paste template you can adapt for your organization.
What is a password policy?
A password policy is a set of rules that defines how passwords are created, stored, used, shared, changed, and protected. It applies to employees, contractors, administrators, service accounts, and sometimes customers, depending on the systems in scope.
A good password policy should answer practical questions:
- How long should passwords be?
- Are passphrases allowed?
- Can users paste passwords from a password manager?
- When must a password be changed?
- Is multi-factor authentication required?
- How are shared credentials handled?
- What happens if a password is suspected to be compromised?
The goal is not to create the most complicated rule set. The goal is to reduce real risk.
The do's of a modern password policy
Do require sufficient length
Length is one of the strongest defenses against guessing and brute-force attacks. A single organization-wide minimum is often easier for people to understand and for IT teams to enforce than separate rules for standard users, administrators, and special cases. A practical default is to require at least 16 characters for all human-user accounts. Longer is better when users rely on password managers or randomly generated passphrases.
Do allow long passwords and passphrases
Users should be able to create passwords that are much longer than the minimum. Avoid low maximum limits such as 16 or 20 characters. A maximum length of at least 64 characters is a reasonable baseline, and many systems can safely support more.
Passphrases should be allowed if they are long and not based on common quotes, song lyrics, company names, or predictable phrases. For example, a passphrase made from several random words is usually better than a short password with forced substitutions.
Do require uniqueness
Every account should have a unique password. Reusing passwords is one of the main reasons a breach on one service turns into account takeover on another. A password manager makes unique passwords practical because users do not need to memorize every credential.
Do support password managers
Your policy should explicitly permit and encourage approved password managers. Users should be allowed to paste passwords into login forms, use autofill, and generate random passwords. Blocking paste may feel protective, but it often discourages strong password manager usage.
Do check passwords against known compromised passwords
Passwords should be rejected if they appear in known breach lists, commonly used password lists, or organization-specific deny lists. This is more useful than forcing users to include one uppercase letter, one number, and one symbol.
Do require MFA wherever technically possible
Multi-factor authentication should be enabled wherever technically possible, especially for administrators, remote access, cloud services, email, password managers, finance systems, and other high-value systems. MFA does not replace strong passwords, but it reduces the impact of stolen credentials.
Prefer phishing-resistant MFA such as passkeys, hardware security keys, or platform authenticators. App-based authenticators are usually better than SMS. SMS-based MFA must not be used if any other MFA method is technically possible because phone numbers can be intercepted, SIM-swapped, ported, or abused through account recovery processes.
This is not theoretical. In 2018, Reddit disclosed that attackers intercepted SMS-based two-factor authentication and accessed internal systems: https://www.reddit.com/r/announcements/comments/93qnm5/wehadasecurityincidenthereswhatyouneed_to/. In 2021, Coinbase reported that attackers stole cryptocurrency from at least 6,000 customers after abusing credentials and a weakness in Coinbase's SMS account recovery process: https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/.
Do change passwords after compromise
Passwords should be changed when there is evidence or reasonable suspicion of compromise. Examples include phishing, malware on a user's device, credential exposure in a breach, suspicious login activity, or accidental disclosure.
Do protect shared credentials properly
Shared passwords should be avoided where individual accounts are possible. If shared credentials are unavoidable, they should be stored in an approved password manager, access should be limited to authorized users, and sharing should be logged where possible.
Do secure password reset processes
Password reset is often the weakest point in account security. Reset workflows should verify identity, expire reset links quickly, use single-use tokens, and notify users when their password is changed.
The don'ts of a modern password policy
Don't force frequent password changes without a reason
Mandatory password changes every 30, 60, or 90 days often lead to weaker passwords. Users tend to make small, predictable changes such as adding a number or changing a season. NIST's Digital Identity Guidelines dropped routine periodic password changes and instead require a password change when there is evidence of compromise. See section 3.1.1.2: https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver. Require password changes after suspected compromise, role changes, account recovery, or when a password no longer meets policy.
Don't rely on complexity rules alone
Rules like "must include uppercase, lowercase, number, and symbol" do not guarantee strength. Password1! satisfies many complexity rules but is still weak. Prioritize length, uniqueness, randomness, and breach screening.
Don't block copy and paste
Blocking paste makes password managers harder to use. It can push users toward shorter passwords that are easier to type. Allow paste and autofill unless there is a specific, documented security reason not to.
Don't allow password hints
Password hints often reveal too much. If a user can remember the answer from the hint, an attacker may be able to guess it too. Use secure reset processes instead.
Don't store passwords in plain text
Systems must never store passwords in plain text or reversible encryption. Passwords should be hashed with a modern, slow, salted password hashing algorithm such as Argon2id, bcrypt, scrypt, or PBKDF2, depending on system capabilities and regulatory requirements.
Fast general-purpose hash algorithms such as MD5, SHA-1, SHA-256, or SHA-512 are not appropriate password hashing algorithms on their own. They are designed to be fast, which makes offline brute-force attacks easier after a database leak. For more background, see our article about the evolution of password hashing.
Don't share passwords over chat or email
Passwords should not be sent through email, chat, tickets, documents, or screenshots. Use a password manager with secure sharing and access controls.
Don't use personal information or predictable patterns
Passwords must not contain names, birthdays, company names, keyboard patterns, repeated characters, or common substitutions such as @ for a and 0 for o. Attackers test these patterns early.
Best practices for organizations
Set clear minimum requirements
Use requirements that are easy to understand:
- One minimum length requirement, for example 16 characters for all human-user accounts
- Allow at least 64 characters
- Allow spaces and common symbols
- Permit passphrases and password managers
- Reject compromised and commonly used passwords
Treat privileged accounts differently
Administrator accounts, service accounts, and production access deserve stricter controls. Require stronger passwords, MFA, limited access, monitoring, and immediate rotation when access changes.
Use role-based access and least privilege
Strong passwords cannot compensate for excessive permissions. Users should only have access to the systems and secrets they need for their role.
Monitor for suspicious activity
Detect unusual login patterns, impossible travel, repeated failed attempts, login attempts from new countries, and access outside normal working patterns. Password policy should be supported by monitoring and incident response.
Train users on realistic threats
Training should focus on password reuse, phishing, fake login pages, MFA fatigue, secure sharing, and how to report suspected compromise. Avoid blaming users. Make secure behavior easy.
Keep the policy short enough to follow
A password policy should be understandable. If the policy is too long, too vague, or too strict, people will work around it. The best policy is one that can actually be enforced and followed.
Copy-paste password policy template
Use the following template as a starting point. Adjust the bracketed sections to match your organization, systems, risk level, and legal requirements.
Password Policy
Version: [1.0]
Owner: [Security / IT Department]
Effective date: [YYYY-MM-DD]
Review cycle: [Every 12 months]
1. Purpose
This policy defines the requirements for creating, using, storing, sharing, and changing passwords for [Organization Name]. The purpose is to reduce the risk of unauthorized access, credential theft, account takeover, and data loss.
2. Scope
This policy applies to all employees, contractors, temporary staff, service providers, and any other users who access [Organization Name] systems, applications, networks, cloud services, or data.
This policy applies to standard user accounts, privileged accounts, service accounts, shared accounts, and any system where passwords are used for authentication.
3. Password creation requirements
All passwords must meet the following requirements:
- Human-user accounts must use passwords of at least 16 characters.
- Passwords must be unique and must not be reused across work or personal accounts.
- Passwords must not contain names, usernames, company names, birthdays, keyboard patterns, repeated characters, or other easily guessed information.
- Passwords must not be based on common phrases, quotes, song lyrics, or predictable substitutions.
- Passwords must not appear in known breached password lists or common password lists.
- Passwords may include spaces, symbols, numbers, uppercase letters, and lowercase letters.
- Passphrases are allowed if they are long, unique, and not based on predictable or public phrases.
4. Password managers
[Organization Name] requires or strongly encourages the use of an approved password manager for creating, storing, and sharing passwords.
Users may use password generator, autofill, and copy-paste functionality from the approved password manager. Users must not store passwords in browsers, spreadsheets, documents, notes apps, email, chat messages, screenshots, or unapproved tools.
5. Multi-factor authentication
Multi-factor authentication must be enabled wherever technically possible, including but not limited to:
- Email accounts
- Remote access systems
- Password manager accounts
- Cloud services
- Administrative accounts
- Finance, HR, and other high-risk systems
- Any system classified as [confidential / critical]
Where available, users must use phishing-resistant MFA such as passkeys, hardware security keys, or platform authenticators. Authenticator apps are preferred over SMS. SMS-based MFA is forbidden if any other MFA method is technically possible and may be used only when no stronger MFA option is technically available.
6. Password changes
Passwords must be changed immediately when:
- A password is known or suspected to be compromised.
- A user entered a password into a suspected phishing site.
- A password was shared with an unauthorized person.
- Malware or unauthorized access is detected on a user's device.
- A password appears in a known data breach.
- A privileged user's role or employment status changes.
- IT or Security instructs the user to change the password.
Routine password expiration is not required unless mandated by law, regulation, contract, or system limitation. Passwords must not be changed by making small predictable modifications to the previous password.
7. Password sharing
Passwords must not be shared through email, chat, tickets, documents, screenshots, phone calls, or verbal communication.
Shared credentials are only allowed when individual accounts are not technically possible or when explicitly approved by [Security / IT]. Approved shared credentials must be stored and shared through the approved password manager with access limited to authorized users.
8. Privileged accounts
Privileged accounts must use unique passwords that are not used for any standard user account. Privileged accounts must use MFA wherever technically possible and must be reviewed regularly.
Privileged passwords must be rotated when an administrator leaves the organization, changes role, no longer requires access, or when compromise is suspected.
9. Service accounts and application secrets
Service account passwords, API keys, tokens, and application secrets must be stored in an approved secrets management system or approved password manager.
Service account credentials must not be embedded in source code, configuration files, images, documentation, or scripts unless protected by an approved secrets management process.
10. Password reset and account recovery
Password reset processes must verify the user's identity before access is restored. Reset links and temporary passwords must be single-use, expire quickly, and be transmitted through approved channels.
Users must be notified when their password is changed or reset. Temporary passwords must be changed at first login.
11. Technical controls
Systems that store or process passwords must:
- Never store passwords in plain text.
- Hash passwords using an approved modern salted password hashing algorithm: PBKDF2, scrypt, bcrypt, or Argon2.
- Not use MD5, SHA-1, SHA-256, SHA-512, or other fast general-purpose hash algorithms as password hashing algorithms on their own.
- Protect authentication endpoints with rate limiting or equivalent controls.
- Reject commonly used, weak, and known compromised passwords.
- Allow users to paste passwords from password managers.
- Support reasonable password length, including at least 64 characters where technically possible.
- Log security-relevant authentication events.
12. Reporting suspected compromise
Users must report suspected password compromise, phishing, unusual login prompts, MFA prompts they did not initiate, or accidental password disclosure to [Security / IT contact] immediately.
13. Exceptions
Exceptions to this policy must be documented, risk-assessed, time-limited, and approved by [Security / IT leadership]. Compensating controls must be applied where possible.
14. Enforcement
Failure to follow this policy may result in access removal, mandatory security training, disciplinary action, or other measures consistent with [Organization Name] policies and applicable law.
15. Review
This policy must be reviewed at least annually or after significant changes to systems, threats, legal requirements, or business operations.
Final thoughts
A strong password policy is not about making passwords painful. It is about removing weak habits, supporting password managers, using MFA, and responding quickly when credentials are exposed. Keep the policy practical, enforceable, and focused on real-world attacks such as phishing, credential stuffing, password reuse, and compromised accounts.
