Password Policy Template 2026: A Structured Framework for Authentication, Complexity, and Lifecycle Management

A password policy is not a memo that "employees should use strong passwords" — it is a technical governance document that determines what complexity passwords must meet, when they must be rotated, how they are stored, and what happens when they are compromised. The problem with most password policies is that complexity rules are written vaguely ("use strong passwords" — how long? what character classes?) and rotation requirements are either absent or counterproductive (forced 30-day rotation leads to weaker passwords like Password1!). The biggest trap when using AI to write a password policy is asking it to "write a standard password policy template" — different systems have different risk profiles (your database admin password vs. the office printer login), and what's useful is mapping your actual system inventory, sensitivity levels, and threat model.

I. The Six-Element Structure of a Password Policy

An enforceable password policy contains six elements: Password Complexity (length, character classes, banned patterns), Authentication Tiering (which systems require passwords only vs. MFA vs. hardware keys), Lifecycle Management (creation, rotation, reset, revocation), Storage and Transmission (hashing algorithms, salt, encryption in transit), Breach Response (what happens when credentials are compromised), and Training and Enforcement (user education, technical enforcement, exceptions). The six elements are sequential: without complexity standards passwords are weak, without tiering all systems get the same protection (too much for low-risk, too little for high-risk), without lifecycle management stale passwords accumulate, without proper storage hashes can be cracked, without breach response compromise goes undetected, without training users find workarounds.

"I need to write a password policy for [company type/industry/system count]. Here are the system inventory and sensitivity levels: [paste]. Please organize by six elements: 1.Password Complexity (①minimum length: standard accounts 12 characters, privileged accounts 16 characters ②character classes: must include at least 3 of 4 (uppercase/lowercase/digits/special characters) ③banned patterns: no dictionary words, no personal info (name/birthdate/phone), no sequential (123456/abcdef), no repeated (aaaaaa), no common patterns (Welcome1/Qwerty123) ④password history: last 12 passwords cannot be reused ⑤maximum length: encourage passphrases up to 128 characters) 2.Authentication Tiering (①Tier 1 (low-risk systems — internal wiki/office printer): password only, 12+ characters ②Tier 2 (business systems — email/CRM/OA): password + MFA ③Tier 3 (high-risk systems — financial/database/cloud admin/production): password + MFA + IP restriction or VPN ④Tier 4 (critical systems — root/Domain Admin/production DBA): password + hardware security key (FIDO2/YubiKey) + privileged access management (PAM) ⑤break-glass: emergency access requires dual authorization + full audit) 3.Lifecycle Management (①creation: generated through approved password manager (1Password/Bitwarden/KeePass), not self-created ②rotation: standard accounts — no forced rotation unless compromise suspected (NIST SP 800-63B recommendation); privileged accounts — rotate every 90 days or after each use (check-out/check-in via PAM) ③reset: user-initiated reset via verified channel (not email-only — require MFA verification); admin-initiated reset requires ticket + authorization ④revocation: upon role change/departure/compromise — immediate revocation across all systems ⑤service accounts: no human password — use managed identities/certificates where possible; if password required, rotate every 30 days + stored in PAM vault) 4.Storage and Transmission (①hashing: bcrypt (cost factor ≥12) or Argon2id — never MD5/SHA1/unsalted SHA256 ②salt: unique random salt per password (≥16 bytes) ③transmission: TLS 1.2+ for all authentication traffic ④storage: passwords never stored in plaintext/never logged/never displayed after entry ⑤password manager: company-approved password manager with AES-256 encryption + MFA + audit log) 5.Breach Response (①detection: subscribe to breach notification services (HaveIBeenPwned API) — check employee credentials against known breaches ②response: if credentials found in breach — force password reset + assess whether account was accessed + review access logs ③internal breach: if password database compromised — all users force reset + rotate all privileged credentials + forensic investigation + breach notification per regulations ④reporting: internal breach reported to security team within 1 hour + executive notification within 24 hours + regulatory notification per applicable law) 6.Training and Enforcement (①training: annual password security training — why strong passwords matter/how to use password manager/how MFA works/phishing awareness ②enforcement: technical enforcement via Active Directory/SSO policy — users cannot set non-compliant passwords ③exceptions: exception request requires security team approval + risk assessment + compensating controls + time-limited (≤90 days) ④auditing: quarterly audit of password compliance — privileged accounts checked every month). Complexity standards must be quantified."

II. Password Complexity Standards: Beyond "Strong Passwords"

Password complexity is the foundation — vague "use strong passwords" is unenforceable. Modern standards (NIST SP 800-63B 2020 revision) shift from forced complexity to length and breach-checking, but most enterprises still need a hybrid approach. Four dimensions: Length (minimum 12 characters for standard accounts, 16 for privileged — length is the strongest predictor of password strength; a 16-character passphrase like "correct-horse-battery-staple" is stronger than an 8-character complex password like "Xq#9!mZ2"), Character Composition (at least 3 of 4 classes: uppercase/lowercase/digits/special — but don't over-constrain or users pick predictable patterns like "Password1!"), Banned Patterns (no dictionary words from common password lists — top 100,000 leaked passwords should be checked against; no personal information — name/birthdate/phone/employee ID; no sequential or repeated characters — 123456/aaa; no common substitutions — P@ssw0rd), Password History (last 12 passwords cannot be reused — prevents cycling between two passwords). Passphrases should be encouraged over complex short passwords — a 20-character passphrase with spaces is easier to remember and harder to crack than a 12-character random string.

"Here are the system inventory and user base: [paste]. Please detail complexity standards by dimension: 1.Length (①standard accounts: minimum 12 characters, encourage passphrases up to 128 characters ②privileged accounts (admin/root/DBA): minimum 16 characters ③service accounts: minimum 20 characters + generated by password manager ④passphrase example: 'purple-elephant-dancing-742' — 29 characters, easy to remember, computationally expensive to crack) 2.Character Composition (①standard accounts: at least 3 of 4 character classes (uppercase/lowercase/digits/special) ②privileged accounts: all 4 character classes required ③special characters allowed: !@#$%^&*()-_=+[]{}|;:,.<>?/~ ④Unicode: allow but don't require Unicode characters — ensure compatibility across systems) 3.Banned Patterns (①dictionary words: check against top 100,000 leaked passwords (HaveIBeenPwned/rockyou list) ②personal info: reject passwords containing user's name/username/birthdate/phone/employee ID/company name ③sequential: reject abcdef/123456/987654 ④repeated: reject aaaaaa/111111 ⑤common substitutions: reject P@ssw0rd/W3lc0me/Pa$$word ⑥context-specific: reject passwords containing system name/project name/client name) 4.Password History (①standard accounts: last 12 passwords cannot be reused ②privileged accounts: last 24 passwords cannot be reused ③history stored as hash only (never plaintext) ④history check at password change time — reject if matches any historical password) 5.Breach Checking (①at creation/change: check proposed password against HaveIBeenPwned API (k-anonymity model — only first 5 chars of hash sent) ②if found in breach database: reject and require different password ③periodic check: monthly check all account password hashes against new breach data ④if match found: force reset + assess account access logs) 6.Password Manager (①approved tools: 1Password Business/Bitwarden Teams/KeePass (self-hosted with sync) ②enforcement: encourage all employees to use password manager for all work credentials ③master password: must meet privileged account complexity (16+ characters) + MFA on the password manager itself ④sharing: use password manager sharing feature (not email/chat) — shared vaults with access control ⑤audit: password manager audit logs monitored for suspicious activity (mass export/unusual access times)). Generate complexity matrix: account type|min length|character classes|banned patterns|history|breach check|password manager."

III. Authentication Tiering: Four Tiers and MFA Enforcement

Not all systems need the same authentication strength — a risk-based tiering approach allocates security investment where it matters most. Four tiers: Tier 1 — Low-Risk Systems (internal wiki, office printer, non-sensitive internal tools): password only with 12+ character complexity; no MFA required; examples: company wiki, conference room booking, office printer. Tier 2 — Business Systems (email, CRM, OA, project management, document management): password + MFA mandatory; MFA methods: authenticator app (Google Authenticator/Microsoft Authenticator) preferred over SMS OTP (SIM swapping risk); examples: email, CRM, Slack, Google Workspace. Tier 3 — High-Risk Systems (financial systems, databases, cloud admin consoles, production environments): password + MFA + network restriction (VPN or IP allowlist); privileged access management (PAM) for checkout/checkout; session recording for all privileged sessions; examples: AWS Console, production database, financial software. Tier 4 — Critical Systems (root accounts, Domain Admin, production DBA, security tooling admin): password + hardware security key (FIDO2/WebAuthn — YubiKey/Titan Key) + PAM with dual authorization + full session recording; break-glass procedures for emergency access; examples: Active Directory Domain Admin, AWS root account, production database root.

"Here are the system inventory and risk classification: [paste]. Please detail by four tiers: 1.Tier 1 — Low-Risk (①systems: internal wiki/office printer/conference room booking/non-sensitive internal tools ②authentication: password only, 12+ characters ③MFA: not required ④network: no restriction ⑤session timeout: 60 minutes ⑥examples: Confluence wiki, HP printer web interface, meeting room booking system) 2.Tier 2 — Business Systems (①systems: email/CRM/OA/project management/document management/Slack ②authentication: password + MFA mandatory ③MFA methods: authenticator app preferred (Google Authenticator/Microsoft Authenticator/Authy) — SMS OTP allowed but flagged as lower security (SIM swapping risk) ④backup MFA: backup codes generated at enrollment (10 codes, single-use, stored securely) ⑤MFA enrollment: within 3 days of account creation — account locked if not enrolled ⑥session timeout: 30 minutes ⑦examples: Gmail/Outlook, Salesforce, Jira, Google Drive, Slack) 3.Tier 3 — High-Risk (①systems: financial software/database/cloud admin/production environment/CI-CD pipeline ②authentication: password (16+) + MFA + network restriction (VPN or IP allowlist) ③PAM: privileged access management — check-out/check-in model (user checks out credential from vault → uses it → credential auto-rotates on check-in) ④session recording: all privileged sessions recorded (terminal/SSH/RDP/web console) ⑤approval: access requires ticket + supervisor approval (not just available) ⑥session timeout: 15 minutes ⑦examples: AWS Console, Azure Portal, production MySQL/PostgreSQL, financial ERP, Jenkins) 4.Tier 4 — Critical (①systems: root accounts/Domain Admin/production DBA/security tooling admin/KMS admin ②authentication: password (20+) + hardware security key (FIDO2/WebAuthn — YubiKey/Titan Key/Feitian) ③PAM: dual authorization — two authorized persons must approve access ④session recording: full recording + real-time monitoring ⑤break-glass: emergency access via sealed credentials (physical envelope with password) — requires dual witness + immediate post-access audit ⑥session timeout: 10 minutes ⑦examples: AWS root account, Active Directory Domain Admin, PostgreSQL superuser, HashiCorp Vault root, Kubernetes cluster-admin) 5.MFA Enforcement (①enrollment: all employees must enroll MFA within 3 days of account creation ②methods: authenticator app (Tier 2) → hardware key (Tier 3-4) ③backup: backup codes + secondary method (if primary device lost) ④lost device: verify identity through HR-confirmed channel → reset MFA → re-enroll ⑤policy enforcement: SSO/Active Directory enforces MFA — non-compliant accounts auto-locked after grace period ⑥exceptions: exception requires security team approval + risk assessment + compensating control + time-limited ≤90 days). Generate tier matrix: tier|systems|password|MFA|network restriction|PAM|session timeout|examples."

IV. Common Mistakes Checklist

• Complexity written as "use strong passwords": unenforceable. Fix: quantified standards (12+ chars, 3/4 classes, banned patterns, history of 12)
• Forced 30-day rotation for all accounts: NIST recommends against forced rotation — leads to weaker passwords. Fix: no forced rotation unless compromise suspected; privileged accounts rotate every 90 days or per-use
• All systems same authentication strength: over-secures low-risk, under-secures high-risk. Fix: four-tier authentication (password only → password+MFA → password+MFA+network → password+hardware key+PAM)
• Passwords stored with weak hashing: MD5/SHA1 crackable in seconds. Fix: bcrypt (cost ≥12) or Argon2id with unique salt
• SMS as only MFA: SIM swapping attacks bypass SMS. Fix: authenticator app preferred; hardware key for Tier 3-4
• No breach checking: compromised passwords continue to be used. Fix: check against HaveIBeenPwned API at creation and periodically
• Service accounts use human passwords: shared, never rotated, untraceable. Fix: managed identities/certificates where possible; PAM vault with 30-day rotation

V. Complete Example

Company: 200-person SaaS company password policy (excerpts complexity + tiering + lifecycle).
Complexity: ①Length: standard 12+/privileged 16+/service 20+ ②Classes: standard 3/4, privileged 4/4 ③Banned: dictionary top 100K/personal info/sequential/repeated/common substitutions ④History: standard last 12/privileged last 24 ⑤Breach check: HaveIBeenPwned API at creation + monthly periodic check.
Tiers: ①Tier 1 (wiki/printer): password only, 12+ ②Tier 2 (email/CRM/Slack): password+MFA (authenticator app), 30min timeout ③Tier 3 (AWS/DB/financial): password(16+)+MFA+VPN+PAM checkout+session recording, 15min timeout ④Tier 4 (root/Domain Admin): password(20+)+hardware key+PAM dual auth+recording+break-glass, 10min timeout.
Lifecycle: ①Creation: via approved password manager (1Password Business) ②Rotation: standard — no forced rotation (NIST); privileged — 90 days or per-use via PAM ③Reset: via MFA-verified channel; admin reset requires ticket ④Revocation: role change/departure/compromise — immediate across all systems ⑤Service accounts: managed identities preferred; password in PAM vault, rotate 30 days.
Storage: bcrypt (cost 12) + unique salt (16 bytes) + TLS 1.2+ transmission + never logged/displayed + password manager AES-256 + MFA.
Breach: HaveIBeenPwned subscription → match found → force reset + assess logs → internal breach → all reset + forensic + regulatory notification.

This article focuses on password policy writing. When building a complete access control framework, also see AI Information Security Policy Writing Guide (security governance and risk management), AI Acceptable Use Policy Writing Guide (acceptable system usage and enforcement), and AI Data Protection Policy Writing Guide (data encryption and privacy protection).

Frequently Asked Questions

Q1: NIST says we should stop forcing password rotation — should we really stop?

For standard user accounts — yes, stop forced rotation unless there's evidence of compromise. NIST SP 800-63B (2020 revision) recommends against forced periodic rotation because: ①users respond to forced rotation by making minimal changes (Password1! → Password2!) which doesn't improve security ②frequent rotation leads to weaker passwords overall (users pick easy-to-remember patterns) ③users write down passwords more frequently when forced to change them often ④compromised passwords are usually used quickly — rotating every 90 days doesn't help if the password was stolen on day 1. When to keep rotation: ①privileged accounts — rotate every 90 days or per-use via PAM (privileged accounts have higher risk and PAM automates rotation so no user burden) ②service accounts — rotate every 30 days (service accounts are shared and untraceable — rotation limits exposure window) ③after suspected compromise — immediate rotation regardless of last change ④regulatory requirements — some regulations (PCI DSS Requirement 8) still require 90-day rotation — if applicable, comply with the regulation while advocating for update. What to do instead of forced rotation: ①enforce strong complexity (12+ characters, breach-checked) ②enforce MFA ③monitor for breach database matches (HaveIBeenPwned) ④monitor for anomalous login patterns. If you must rotate (regulatory or contractual), every 90 days is sufficient — 30-day rotation is excessive and counterproductive.

Q2: Our employees keep forgetting passwords and calling IT for resets — how do we reduce the burden?

Deploy a password manager and implement self-service password reset. Password manager: ①provide company-approved password manager (1Password Business/Bitwarden Teams) to all employees ②users only need to remember one master password (16+ characters) — the password manager remembers everything else ③auto-fill eliminates typing errors ④password manager generates strong random passwords — users don't need to invent them ⑤reduces reset requests by 70-80% (users no longer forget because they don't need to remember). Self-service password reset (SSPR): ①implement SSPR through SSO/Active Directory — users reset their own password after MFA verification (not email-only — require authenticator app or hardware key) ②registration: users register during onboarding — provide alternate authentication factors (authenticator app + backup codes + security questions as last resort) ③reset process: user goes to SSPR portal → verifies identity via MFA → sets new password → password syncs to all integrated systems ④audit: all SSPR resets logged (user/IP/time/result) — security team reviews weekly ⑤rate limiting: max 3 self-service resets per day — more triggers IT contact (prevents abuse). Additional measures: ①passphrases — encourage 16+ character passphrases ("purple-elephant-dancing-742") which are easier to remember than complex short passwords ②training — teach employees how to use password manager effectively ③onboarding — set up password manager and SSPR enrollment during first-day IT setup ④BYOD — password manager works on mobile so users have passwords on all devices. With password manager + SSPR, password reset requests should drop to near-zero for routine cases.

Q3: We use SMS for MFA but heard about SIM swapping — what should we do?

Migrate from SMS to authenticator app, and for high-risk accounts use hardware security keys. SIM swapping risk: attackers convince the carrier to port the victim's phone number to a new SIM — then receive the victim's SMS OTP and bypass MFA. Mitigation: ①Tier 2 (business systems): migrate from SMS to authenticator app (Google Authenticator/Microsoft Authenticator/Authy) — authenticator app generates TOTP codes locally on the device, not sent via SMS, so SIM swapping doesn't affect it ②encourage employees to set a SIM PIN with their carrier (prevents unauthorized SIM port-out) ③Tier 3-4 (high-risk/critical): use hardware security keys (FIDO2/WebAuthn — YubiKey/Titan Key) — hardware keys are phishing-resistant (the key verifies the domain, so phishing sites can't capture credentials) and not vulnerable to SIM swapping or man-in-the-middle attacks ④backup MFA: when migrating, ensure users have backup methods (backup codes + secondary device) so they don't get locked out during migration ⑤migration plan: Phase 1 — enroll all users in authenticator app (alongside SMS for transition) → Phase 2 — after 30 days, set authenticator app as primary and SMS as fallback → Phase 3 — after 60 days, disable SMS MFA entirely (except for edge cases like international travel where authenticator app may be unavailable) ⑥exceptions: if SMS must remain (e.g., users without smartphones) — enforce SIM PIN + limit SMS MFA to Tier 1 systems only ⑦phishing-resistant MFA: for Tier 3-4, prefer FIDO2/WebAuthn (phishing-resistant) over TOTP authenticator app (phishing-vulnerable — user can be tricked into entering TOTP code on a phishing site). The migration from SMS to authenticator app is low-cost (free apps) and high-impact — prioritize it immediately.

Author: UseAIWriter Editorial | Updated: 2026-10-29 | Written by UseAIWriter Editorial. Please cite the source when reposting.