The password policy decides what passwords your tenant accepts. Applied at password creation (sign-up, admin-set, reset). Existing passwords aren't re-validated — they're grandfathered in until the user changes them.
Where to set it
Settings → Password policy. A single form.
Knobs
Minimum length
Default: 12. NIST 800-63B recommends ≥ 8 for the policy minimum but stronger products go higher. 12 is the right modern default — long enough to defeat brute-force, short enough that users can manage without a password manager.
Don't go below 8.
Character classes
The platform supports requiring N of:
Uppercase letter
Lowercase letter
Digit
Special character (
!@#$%^&*()_+-=[]{};':",.<>?/)
Default: at least one of each. Stricter rules don't meaningfully add security; users just append 1! and call it done.
NIST actually recommends NOT requiring character classes — they reduce password entropy by forcing predictable patterns. Modern thinking: length matters more than complexity. The platform offers character-class rules because some compliance regimes still require them; if you have a choice, prefer length over complexity.
Breached-password check
Toggle. When on, the platform checks the submitted password against a breached-password feed (Have I Been Pwned-style). Common passwords from public dumps are rejected with a friendly error.
We recommend ON. The check is local on the platform; no plaintext password leaves the platform. Catches "password123" and the long tail of leaked credentials your users might reuse.
Maximum length
Default: 256. Effectively unlimited. The argon2 hash handles very long passwords correctly.
Don't set this too low. Some compliance regimes mention "maximum length" as a knob; in practice, the right value is "as high as the platform allows".
Consecutive identical characters
Default: max 4. Catches "aaaa" / "1111" patterns. Optional; the breached-password check usually catches these via the dump.
Username similarity
Default: off. When on, the platform refuses passwords that are substring-equal to the user's email / username. ("anita2024" if the user is anita@cymmetri.com.)
Use case-by-case; can be friction for users who legitimately want a password derived from their initials.
Rotation interval (Don't use this)
NIST 800-63B specifically advises AGAINST routine password rotation. Forcing users to change every 90 days produces:
Predictable "PasswordSpring2026!" → "PasswordSummer2026!" patterns.
Sticky-notes on monitors.
More support tickets ("I forgot what variation I'm on now").
The platform offers the rotation knob because some compliance regimes still demand it (looking at you, PCI DSS pre-v4.0). Leave OFF unless your auditors specifically require it. If they do, set the longest interval the rule permits.
Existing passwords + policy changes
Tighter policy doesn't retroactively invalidate existing passwords. Users with shorter / weaker passwords keep them until they change.
To force re-pick under a new policy:
Update the policy.
Bulk-force-password-reset across affected users (Users → Actions → Bulk force password reset on next sign-in).
Or wait for natural rotation: each user resets eventually (forgot password, scheduled rotation if you're using it). Slower but no support deluge.
Per-user override
The platform doesn't have per-user password policy overrides. Policy is tenant-wide.
For exceptional cases (a specific user with a generated long machine-readable secret), bypass: provision the user with the secret directly through bulk-import with password_must_be_reset: false; the policy applies to subsequent user-set passwords, not the initial one if you supplied it.
Audit
Saving the policy records admin.policy_updated (with policy: password) and includes the diff. Visible later in audit.
Individual password validations against the policy are also audited:
user.password_set_succeeded— user picked a password that passes.user.password_set_failed_policy— user tried a password that fails; the specific rule that triggered is indata.failed_rule.
The latter is useful for "are users frustrated by our policy?" — high password_set_failed_policy rates suggest the policy is too tight.
Recommended starting policy
For a fresh tenant:
Minimum length: 12.
Character classes: at least one of each (lowercase, uppercase, digit, special).
Breached-password check: ON.
Max length: 256.
Consecutive identical chars: max 4.
Username similarity check: OFF (unless your compliance demands it).
Rotation: OFF.
This works for the vast majority of tenants. Tighten only if your compliance demands it or if you have evidence of actual problems with the default.