Strong Password Policy and Password Manager Guide

Create a strong password policy by prioritizing length and uniqueness, blocking compromised passwords, allowing password managers and autofill, removing arbitrary complexity and expiration rules, and requiring MFA for important accounts. Deploy the policy with a managed password vault, secure recovery procedures, and tests that confirm the written rules work in every covered system.

Quick Take

These requirements follow current NIST authenticator guidance. They are a security baseline rather than proof that a particular policy satisfies every law, contract, or industry framework.

Prerequisites and Ownership

Identify the accounts in scope

Inventory the systems that accept passwords before writing the rules. Include workforce accounts, customer accounts, administrator access, cloud services, remote-access tools, shared credentials, and legacy applications. Record which systems use single-factor authentication, MFA, or single sign-on.

Keep machine credentials in a separate category. API keys, database secrets, certificates, service-account tokens, and CI/CD credentials require secrets-management controls rather than an ordinary employee password vault. A dedicated article on business secrets management should cover those systems.

Assign responsibility

Name a policy owner, identity-platform administrator, security reviewer, help-desk recovery owner, and departmental access approver. A policy without named owners tends to fail at exceptions, recovery, and offboarding rather than during ordinary password creation.

Document technical constraints

Record each system’s minimum and maximum length, supported characters, MFA options, password-history rules, breached-password screening, paste and autofill behavior, recovery process, and session controls. Legacy systems that cannot meet the baseline should enter a documented exception process with compensating controls and a retirement or remediation date.

Step-by-Step: Create the Password Policy

1. Define which accounts the policy covers

   State whether the policy applies to employees, contractors, administrators, customers, service providers, and shared accounts. Classify higher-risk accounts such as email, identity-provider, financial, cloud-administrator, source-code, and password-vault accounts.

   Where possible, replace shared accounts with individually attributable accounts. If sharing is unavoidable, use a managed vault that records access and lets administrators revoke membership.

   Expected result: Every covered account type has an owner, risk classification, authentication method, and exception status.

2. Set length and input requirements

   Require at least 15 characters when a password is the only authentication factor. NIST permits passwords used only as part of an MFA process to be shorter, but they must contain at least 8 characters. Organizations may adopt a longer minimum when users can rely on a password generator.

   Permit passwords of at least 64 characters. Accept spaces and broad character sets, process the entire submitted password, and never silently truncate it. Systems that mishandle spaces or long generated values should be corrected or documented as exceptions.

   Advertisement

   Expected result: Users can create long passphrases or generated passwords without encountering unnecessary input restrictions.

3. Remove mandatory composition rules

   Do not require every password to contain a prescribed mixture of uppercase letters, lowercase letters, numbers, and symbols. Current NIST rules prohibit these composition requirements because users commonly satisfy them with predictable patterns.

   Symbols remain acceptable when a generator selects them or a service requires them. The policy should not imply that a short password becomes safe simply because one letter was replaced with a familiar symbol. NIST’s public password creation guidance prioritizes length and recommends long passphrases when a password must be created manually.

   Expected result: Users can choose long, usable passwords without following predictable formatting recipes.

4. Replace scheduled expiration with event-driven changes

   Do not force users to change passwords every 30, 60, or 90 days without evidence of risk. Require a change when a password is known or suspected to have been disclosed, appears in relevant breach data, was transmitted insecurely, or may remain known to someone whose access has ended.

   A password change must be accompanied by session revocation when an attacker could already be signed in. Changing the secret alone may not invalidate active browser sessions, application tokens, or remembered devices.

   Advertisement

   Expected result: Password changes respond to compromise and access changes rather than an arbitrary calendar.

5. Block weak and compromised passwords

   Compare new and changed passwords against a blocklist containing commonly used, expected, and compromised values. Include context-specific choices such as the organization’s name, service name, username, and predictable derivatives.

   Explain why a proposed password was rejected and ask the user to choose a genuinely different value. Do not reveal whether another person uses that password. Avoid enormous blocklists that create excessive false rejections without meaningfully improving protection against rate-limited online guessing.

   Expected result: Users cannot enroll values that attackers are likely to guess early or already possess from breach collections.

6. Add controls around the password

   Require MFA for email, identity-provider, financial, remote-access, cloud-administrator, source-code, and password-manager accounts. Prefer phishing-resistant methods such as passkeys or hardware-backed security keys where the service and user environment support them.

   Rate-limit or progressively delay failed attempts. Monitor suspicious logins, protect account recovery, avoid knowledge-based questions as a sole recovery method, and provide a way to revoke sessions after suspected compromise. The OWASP authentication guidance treats password controls, MFA, recovery, session handling, and login monitoring as connected parts of account security.

   Advertisement

   Expected result: A guessed or disclosed password is harder to convert into persistent account access.

7. Require password-manager-compatible login forms

   Allow users to paste and autofill credentials. Use standard password fields and avoid scripts or form designs that block managers. NIST requires verifiers to allow password managers and autofill and recommends permitting paste when autofill interfaces are unavailable.

   Do not interpret clipboard blocking as a security control. It can push users toward shorter passwords they can type manually or toward storing credentials in insecure notes.

   Expected result: Users can generate, store, and enter unique credentials without weakening them for convenience.

How to Choose a Password Manager

Select a manager by deployment fit, recovery design, security controls, and usability rather than by the length of its feature list. The NCSC buyers guide emphasizes that an unusable manager will leave insecure workarounds in place.

Evaluate the following capabilities before deployment:

• Protection of credentials and metadata at rest.
• Who controls or can recover the vault’s decryption key.
• MFA, passkey, and approved-device support.
• Recovery options and the people authorized to use them.
• Secure sharing without revealing passwords in email or chat.
• Role-based administration, audit records, and offboarding controls.
• Restrictions or alerts for bulk export.
• Supported browsers, operating systems, and mobile devices.
• Update delivery and the provider’s vulnerability-disclosure process.
• A practical method for leaving the service without permanent lock-in.

Browser and device managers can be appropriate when convenience and ecosystem integration matter most. A reputable standalone manager may fit mixed-device environments or teams requiring advanced sharing and administration. The NCSC’s updated password-manager guidance recommends evaluating reputation, device security, recovery, MFA, and platform needs instead of assuming one type fits everyone.

How to Deploy and Use the Password Manager

1. Protect the vault account

Create a long, unique primary passphrase that is never used elsewhere. Enable the strongest practical MFA and secure every registered device with updates, automatic locking, and a local PIN or biometric unlock.

Store recovery keys or emergency instructions separately from the vault. Avoid circular recovery in which the only way to access the email account is through the vault while the only way to recover the vault is through that email account.

2. Import credentials carefully

Some managers migrate credentials through a CSV file. That export may contain readable usernames and passwords. Create it only on a trusted device, import it immediately, verify that the records arrived, and delete the exported file from the original folder, recycle bin, cloud synchronization, and temporary storage.

Do not perform a vault migration over an unfamiliar hotspot. Review the precautions in this public Wi-Fi security guide before accessing sensitive accounts away from a trusted connection.

3. Replace reused passwords in risk order

1. Secure the password-manager account and its recovery channels.
2. Change email and identity-provider credentials.
3. Change banking, payment, payroll, and financial credentials.
4. Change administrator, cloud, source-code, and remote-access credentials.
5. Change shopping, social-media, subscription, and lower-impact accounts.

Do not change dozens of accounts without confirming that each new password was saved. Keep the old session open until the new credential has been tested in a separate private window or another approved device.

4. Configure generation and autofill

Generate a different random password for every compatible service. Match the site’s supported length and character rules while avoiding needless manual edits. If autofill does not appear, check the exact domain before searching the vault and copying the password.

Autofill may help resist phishing because a manager should associate credentials with the legitimate domain. It is not infallible. Users must still inspect unusual addresses, subdomains, redirects, and browser warnings.

5. Configure team sharing and offboarding

Store business credentials in organization-controlled collections rather than personal vaults. Grant access by role, assign an accountable owner, review membership, and remove access promptly when someone changes roles or leaves.

Revoking vault access prevents future retrieval, but it cannot make a password unknown to someone who already viewed or copied it. Rotate credentials when a departing user could retain them. Teams protecting software repositories should connect this process to the controls in the guide to preventing source-code theft.

Verify That the Policy Works

Test the deployed controls instead of assuming a written setting was applied consistently.

Record exceptions and failed tests with an owner and target correction date. Repeat the checks after identity-platform changes, password-manager migrations, or major policy revisions.

Failure Modes and Troubleshooting

Operational Limits and Edge Cases

• Concentrated value: A vault makes unique passwords practical, but a successful vault compromise can expose many accounts. Protect the primary account and registered devices accordingly.
• Compromised endpoints: Malware or someone using an unlocked computer may capture credentials after the vault decrypts them. A password manager does not replace device protection. Organizations can evaluate those controls separately in this endpoint protection guide.
• Recovery trade-off: Recovery improves availability but creates another path that an attacker may target. Document who can recover a vault and what evidence is required.
• Shared accounts: A vault improves sharing, but individual accounts remain preferable because they provide attribution and cleaner revocation.
• Offline access: Emergency recovery material needs physical protection, named custodians, and periodic verification.
• Phishing: Passwords themselves are not phishing-resistant. Adopt passkeys where appropriate and evaluate the differences in a future passkeys versus passwords guide.

Key Takeaways

Frequently Asked Questions