# User Policies: Registration and Passwords

> System-wide rules for who can sign up and how: public registration, admin approval, email verification, default role, user caps, and password requirements.

Source: https://totalshiftleft.ai/help-center/product-documentation/user-policies

## Overview

**User Policies** controls how people get accounts and what those accounts must satisfy. These are system-wide settings and require Administrator access.

Nav path: **Settings → Licensing & Users → User Policies**. See [Administration settings](/help-center/product-documentation/administration-settings) for the wider map.

## Registration

Three settings decide how someone becomes a user, and they combine:

| Setting | Effect |
|---------|--------|
| **Allow public user registration** | Anyone who can reach the sign-up page can create an account. |
| **Require admin approval for new user accounts** | New accounts stay pending until an administrator approves them. |
| **Require email verification for new users** | The account isn't usable until the address is verified. |

The combination that matters most is the first two. **Allow public user registration** on, with **Require admin approval** off, means anyone who reaches your instance gets in unreviewed. That may be fine for an internal network and is rarely fine otherwise.

The common safe configurations:

- **Invite-only** — public registration off. Users arrive only via invitation. The right default for most teams.
- **Open with a gate** — public registration on, admin approval on. Useful when you want self-service without losing control of who gets in.
- **Open** — public registration on, approval off. Only sensible where the network already restricts who can reach the product.

Leave **Require email verification** on in all of them. It costs a user one click and it stops accounts being created against addresses that don't exist or aren't theirs.

## Default Role Settings

**Default User Role** is the role a new user receives when nothing more specific applies.

Set this to the lowest-privilege role that lets someone do useful work. It's the role every account that arrives through a path nobody thought about will land on, so it should be the one you'd be comfortable handing to a stranger. Elevate individuals afterwards.

See [Role permissions](/help-center/product-documentation/role-permissions) for what each role can do.

## Max Users Per Project

**Max Users Per Project** caps how many users a single project may have. Use it to keep project membership deliberate rather than accumulating everyone who ever needed a look.

Note this is separate from your licence's user entitlement — see [License management](/help-center/product-documentation/license-management).

## Password requirements

The password policy applies to every account:

| Setting | Notes |
|---------|-------|
| **Minimum Length** | The floor on password length. |
| **Maximum Age (days)** | How long a password may be used before it must change. |
| **Require at least one lowercase letter (a-z)** | Character-class requirement. |
| **Require at least one uppercase letter (A-Z)** | Character-class requirement. |
| **Require at least one number (0-9)** | Character-class requirement. |
| **Require at least one special character (!@#$%^&\*)** | Character-class requirement. |

A note on how these interact in practice: **Minimum Length** does far more for real security than the four character-class rules combined. Length is what defeats brute force; composition rules mostly push people toward predictable substitutions and writing passwords down. If you want one lever, raise the length.

**Maximum Age** deserves thought rather than reflex. Forced rotation on a short cycle tends to produce weaker passwords with a counter on the end. Modern guidance favours rotating on evidence of compromise rather than on a timer. Set it if your compliance regime requires it; otherwise a long or unset age with a strong length is usually the stronger position.

On Enterprise, SSO takes most of this off your plate — authentication moves to your identity provider and its policy governs. See [Single sign-on](/help-center/product-documentation/single-sign-on).

## Resetting

**Reset User Policies** returns these settings to defaults. It affects who can register and what passwords are accepted from that point on, so treat it as a deliberate act rather than a way to clear a form.

## Troubleshooting

- **New users can't sign in after registering** — **Require admin approval** or **Require email verification** is on and the step hasn't completed. Check pending accounts in [User management](/help-center/product-documentation/user-management).
- **Nobody can register at all** — **Allow public user registration** is off. That's an invite-only configuration; invite them instead.
- **A user can't be added to a project** — you may be at **Max Users Per Project**, or at your licence's user limit. They're different limits with a similar symptom.
- **Password changes are rejected** — the new password fails a policy rule. The rules are cumulative; all enabled ones must pass.
- **Settings are read-only** — you're not an Administrator.

## Related articles

- [User management](/help-center/product-documentation/user-management)
- [Role permissions](/help-center/product-documentation/role-permissions)
- [Administration settings](/help-center/product-documentation/administration-settings)
- [Single sign-on](/help-center/product-documentation/single-sign-on)
- [License management](/help-center/product-documentation/license-management)