​

Password Policy

The Password Policy panel controls the rules users must follow when they create or change a local NeuralTrust password. It applies to any account that still signs in with a password — members who authenticate via SSO are unaffected by this policy (their IdP’s password rules apply instead). Open it from Team settings → Password Policy. A badge at the top tells you whether you’re Using default policy or Using custom policy. Clicking Apply Recommended snaps every setting to NeuralTrust’s recommended values; Save Changes persists whatever you have on screen.

​

Settings

​

Minimum length

The fewest characters allowed in a new password.

• Recommended: 8+ for standard security, 12+ for sensitive data.
• The field is a numeric input; any value ≥ 1 is accepted, but the platform will warn on anything below 8.
• Changing this does not invalidate existing passwords — it only applies to new passwords and password changes from the moment you save. If you want to force a rotation, you’ll need to reset affected users from the Users panel.

​

Character types

Toggle any combination of these requirements: Character-class rules improve resistance to brute force but don’t by themselves prevent weak passwords like Password1!. Combine them with the additional-security blocks below.

​

Additional security

These two toggles do more for real-world security than any length or character-class rule on its own — a 10-character password that matches the user’s email local-part is still guessable in seconds.

​

Preview

The right-hand Preview (try it out) box simulates the user-facing validator exactly as a signing-up user will see it. Type a sample password and the requirement list lights up green / red in real time. Use it as a sanity check before saving; users land on this same UX when creating their password.

​

Applying the recommended policy

Apply Recommended sets:

• Minimum length: 12
• Require uppercase / lowercase / number: on
• Require special character: off (you may toggle on for regulated environments)
• Block common passwords: on
• Block personal info in password: on

It does not immediately save — it populates the form, review and click Save Changes to persist.

​

What happens to existing passwords

Changes to the policy are prospective:

• Next password set or change — fully validated against the new policy.
• Active sessions — unaffected.
• Existing stored passwords — not re-validated. If an existing password no longer satisfies the new policy, the user keeps it until the next time they change it.

To force every user onto the new policy, combine a policy change with one of:

1. Enforcing SSO (most secure) — turn on SSO-only in SSO Configuration. Local passwords stop being used.
2. Bulk password reset — reset affected users from Users; they’ll create a new password that must satisfy the policy.

​

Interaction with SSO

Users who sign in through SSO never hit this policy — it only guards the local password store. When SSO is enforced, the password policy becomes dormant and serves only as a safety net for break-glass users who authenticate with a password during an IdP outage. See Break-glass access.

​

Audit

Every change to the policy is recorded in Audit Logs with:

• team.settings.updated — the event itself.
• The actor — which Owner / Admin made the change.
• Before / after values of each toggle and the minimum length.

​

Related

• SSO — remove local passwords from the equation entirely.
• Break-glass access — the emergency accounts that still use passwords.
• Users — reset a specific user’s password to force them onto the new policy.
• Audit Logs — review policy changes.