The password policy decides what counts as an acceptable password. It applies when someone signs up, resets a password, changes it, or an administrator sets one. Existing passwords keep working until they are changed, so tightening the policy never locks anyone out.
Password policy page

Users & auth → Password policy: Strength, then Reuse and expiry.

In Studio

Users & auth → Security → Password policy. Three cards.

Strength

Reuse and expiry

Guessable passwords

What your app sees

A password that fails the policy is a ValidationError on the password field, with a message that says which rule failed:
Show the rules before the person types: read them from your own configuration and list them under the field (“At least 12 characters”). Don’t duplicate the checks as a replacement for the server’s.
  • Length over complexity. 12 or more characters beats forcing symbols. Leave Must contain off.
  • Turn on the breach check. It is the single most effective rule against reused passwords.
  • Don’t expire passwords unless a regulation says you must. Forced rotation makes people pick weaker passwords.
  • Turn on personal-information refusal.
  • Allow paste in your form so password managers work.

Expired passwords

With Passwords expire after set, a person whose password is too old can’t sign in until they reset it. Their sign-in fails with an authentication error; send them to “Forgot password” (recovery).

Account recovery

Reset links.

Two-step verification

Protect accounts beyond passwords.