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
Section titled “Where to set it”Settings → Password policy. A single form.
Minimum length
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “Consecutive identical characters”Default: max 4. Catches "aaaa" / "1111" patterns. Optional; the breached-password check usually catches these via the dump.
Username similarity
Section titled “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)
Section titled “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
Section titled “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
Section titled “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.
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
Section titled “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.