A written password policy is a specific, auditable document — not just a set of technical controls configured in an identity platform. Auditors, cyber insurers, and compliance assessors typically ask for the document itself, separate from evidence that the controls are actually enforced. This article walks through what a modern, NIST-aligned password policy should contain, section by section, so you can build or update your own.
In short
A written password policy needs 11 core sections — from minimum length through review cycle — and it must match what's actually technically enforced, since a mismatch between stated policy and configured reality is a common audit finding. Skip the blank page and use the Password Policy Generator to produce an editable draft pre-filled from a NIST, Microsoft, CIS, PCI DSS, or HIPAA preset.
Generate a starting draft automatically
Rather than building this document from scratch, the Password Policy Generator tool produces a complete, editable draft of every section below — pre-filled from a NIST, Microsoft, CIS Controls, PCI DSS, or HIPAA preset — that you can adjust and export directly.
Policy document vs. technical enforcement
A password policy document states the organization's requirements. Technical enforcement (Entra ID settings, breached-password screening, MFA configuration) is how those requirements are actually applied. Both need to exist, and they need to match — an audit finding commonly arises when the written policy says one thing and the configured system does something else.
Core sections a password policy document needs
1. Purpose and scope
State why the policy exists and what it covers — typically all systems, applications, and accounts used to conduct business, including cloud services, on-premises systems, and any personally owned devices used to access company resources. Explicitly note whether the policy covers service accounts and system credentials, which often need separate, stricter handling than human user accounts.
2. Minimum requirements for user-chosen passwords
- Minimum length (recommend at least 12 characters for user accounts; see NIST Password Guidelines for the reasoning behind a length-first approach)
- Maximum length supported (state that the organization's systems support at least 64 characters, per current guidance)
- No mandatory composition rules (explicitly state that composition is not required, to prevent individual system administrators from re-adding legacy rules independently)
- Passphrases explicitly permitted and encouraged (see Passphrase vs. Password)
Sample policy language
"All user-chosen passwords must be at least 12 characters in length. Systems must support passwords of at least 64 characters. No specific mix of uppercase, lowercase, numeric, or special characters is required. Passphrases composed of multiple random words are permitted and encouraged as an alternative to a single complex password."
3. Prohibited passwords
State that passwords will be screened against known-breached password lists and rejected if found, and prohibit passwords containing the organization's name, the user's own name or username, or other easily guessable personal or organizational information.
4. Rotation policy
State that passwords are not required to be changed on a fixed calendar schedule, except where a specific regulatory or contractual requirement mandates it (name the specific requirement if one applies to your organization — see HIPAA Password Guidance and PCI DSS Password Guidance), and that passwords must be changed immediately upon any suspicion or evidence of compromise.
5. Multi-factor authentication requirement
State that MFA is required for all accounts without exception, list any approved MFA methods, and explicitly prohibit SMS-based MFA as the sole method where a stronger option (authenticator app, hardware key) is available, since SMS is more vulnerable to interception and SIM-swapping attacks.
6. Password manager requirement
State that a company-provisioned password manager is required for storing and generating credentials, and that storing passwords in browsers outside the managed tool, plaintext documents, spreadsheets, or physical notes is prohibited. See the Password Manager Guide for deployment guidance.
7. Credential sharing and shared accounts
State that individual accounts must not be shared between users, and that any legitimately shared credential (a shared service login, a vendor portal account) must be stored and accessed through the approved password manager's sharing feature, never sent via email, chat, or verbally.
8. Account lockout and rate limiting
State the lockout threshold (commonly 5–10 failed attempts) and lockout duration or unlock process, balancing protection against guessing attacks with avoiding unnecessary denial-of-service against legitimate users. The unlock process should follow the same verified sequence as any password reset:
9. Administrator and privileged account requirements
State any additional requirements for accounts with elevated privileges — commonly a higher minimum length, mandatory hardware-key MFA rather than app-based MFA, and separate administrative accounts distinct from an individual's standard user account.
10. Enforcement and exceptions
State how the policy is technically enforced (referencing the specific platform, e.g., Entra ID Conditional Access), who owns policy exceptions, and the process for requesting and documenting an exception.
11. Review cycle
State how often the policy document itself is reviewed and by whom — annually at minimum, or triggered by a significant guidance change (such as an update to NIST SP 800-63B) or a security incident.
Framework-specific requirements may add sections
Organizations in scope for HIPAA, PCI DSS, SOC 2, or CMMC may need additional sections addressing framework-specific requirements — see the compliance-specific articles in this cluster. A generic policy template is a starting point, not a substitute for confirming alignment with every framework that applies to your organization.
Common mistakes when writing a password policy
- Copying a template without updating it to match actual technical configuration. A policy that states requirements not actually enforced in the identity platform is a direct audit finding.
- Leaving legacy language from a pre-2017 policy in place — composition-rule mandates and forced rotation clauses are the two most common leftovers from outdated templates.
- Not defining a review cycle, leaving the policy to go stale as guidance and the organization's systems both change.
- Treating the document as separate from MFA and password manager requirements, rather than as one integrated statement of the organization's full credential-security posture.
FAQ
Do we need a separate policy for service accounts? Many organizations address service accounts within the same policy document but with distinct requirements — typically longer, fully random credentials stored in a secrets manager rather than memorized, since no person needs to recall them.
How often should the policy be reviewed? At least annually, and additionally whenever a relevant guidance document (like NIST SP 800-63B) is revised, a new compliance obligation applies to the organization, or a security incident reveals a gap in the current policy.
Is a downloadable template enough, or do we need a security assessment too? A template gives you the structure and language; whether the specific requirements are right for your organization, and whether your systems are actually configured to enforce them, is a separate question a security assessment can answer. See Security Assessment Services.
Related reading
- NIST Password Guidelines
- Password Manager Guide
- HIPAA Password Guidance
- PCI DSS Password Guidance
- Password Policy Generator — generate a complete, editable policy document
- Password Generator
- Download: Password Audit Checklist
- Download: Password Best Practices Guide