Free policy generator
Password and authentication policy generator
Answer a few quick questions about your stack, and your custom password and authentication policy updates live on the page. When you finish, export it as a Word document, Markdown, or PDF. Everything runs inside your browser. There is no signup, no email gate, and nothing sent to our servers.
A starting template, not legal advice. Read it against how your company actually works, change anything that isn't true, and have counsel review obligations specific to your industry and jurisdiction. Nothing you enter leaves this page.
What auditors look for in authentication policies
Most generic templates still demand arbitrary complexity rules and forced 90-day rotations. That advice is years out of date. Modern guidance like NIST SP 800-63B discourages periodic rotation because it leads to predictable, weaker passwords. What auditors actually verify is whether your policy matches your identity provider settings. If your policy says passwords expire every 90 days but your Google Workspace or Okta tenant does not enforce it, that is an audit finding. State what you actually enforce, require MFA, and save rotation for suspected compromise.
Once you download your policy, align your tools immediately. Turn on mandatory multi-factor authentication across your primary identity provider, code repositories, and cloud consoles. Pick a standard password manager for your team, then configure your single sign-on system to enforce minimum password lengths of at least 12 characters. If you build software, verify that your backend hashing uses modern algorithms like Argon2id or bcrypt. Auditors will ask for screenshots of these settings. Make sure they match.
Questions
Does SOC 2 require 90-day password expiration?
No. SOC 2 does not mandate 90-day password changes. Auditors evaluate your controls against criteria like CC6.1, which focuses on logical access security. Following NIST SP 800-63B by requiring strong multi-factor authentication, screening for compromised credentials, and enforcing length over rotation satisfies SOC 2. If you select PCI DSS, note that Requirement 8.3.9 still expects 90-day changes on accounts where a password is the only factor, which MFA removes; the generator adds that clause for you.
What password length should we enforce?
NIST SP 800-63B sets a floor of 15 characters when a password is the only factor and 8 when it is paired with MFA. Most teams settle on 12 to 16 characters. We recommend at least 12 characters for standard staff accounts and 16 characters for administrators. Longer passphrases are significantly harder to crack than short passwords packed with arbitrary symbols, especially when paired with a password manager.
Can we use SMS for multi-factor authentication?
You can, but you should phase it out. SMS is vulnerable to SIM swapping and interception. NIST SP 800-63B restricts SMS authentication, and security-conscious auditors will challenge it. Use authenticator apps generating time-based one-time codes as a baseline. For staff with administrative access to production infrastructure, require phishing-resistant hardware security keys or passkeys.
Is a downloaded policy template enough to pass an audit?
No template passes an audit by itself. A policy defines your standard, but an auditor verifies whether you follow it. During a SOC 2 or ISO 27001 audit, you must provide evidence. That means exporting configuration screens showing mandatory MFA in your identity provider and demonstrating password lockout thresholds. Edit the document so it mirrors your actual technical setup.
How often should our password and authentication policy be reviewed?
Review your authentication policy at least once a year. Frameworks like ISO 27001 and SOC 2 expect documented annual sign-offs by the designated policy owner. You should also revisit it whenever your tech stack changes, such as adopting passkeys or replacing your identity provider. Always update the revision history table to record who approved the changes and when.
More templates: Access control policy generator · Incident response policy generator · Vulnerability management policy generator · Data retention policy generator
Checked once. Now have it watched.
Your policy defines how your team handles credentials, but external visibility proves your perimeter holds. Attack Surface Scan runs scheduled passive scans to detect exposed administrative ports, missing TLS certificates that leave credentials unencrypted, and lookalike domains designed for phishing. It gives you verified audit evidence without complex setup.
7-day trial of the full product, no card required. Scanning needs domain ownership verified by DNS: Attack Surface Scan never scans anything you haven't proved you control.