Password & authentication policies
Enforce password complexity, multi-factor authentication, and login rules across your organization to raise everyone's baseline security.
Policies let admins set a security baseline every member must meet. They're enforced by the client and server and apply to all users in scope.
Password policy#
Configure under Organization → Security policies → Password (the page is titled Password Policies). Select Save Policy at the top to apply your changes.
Effective Posture — the card at the top — shows what is in force right now: whether enforcement is ON or OFF, the Min Length, the Complexity grade and the History count (or Disabled). It reads from the saved policy, so it is the quick way to confirm what members are held to.
The master switch#
Enforce Password Policies is the master switch. It requires members to follow these rules for both their account login password and passwords made with the password generator. While it is off, every rule below it is disabled — you cannot edit the values, and none is applied. Turn it on first, then set the rules.
The rules#
| Section | Setting | What it does |
|---|---|---|
| Generator Constraints | Minimum Length, Maximum Length | Reject passwords below or above a length |
| Require Uppercase Letters, Require Lowercase Letters, Require Numbers, Require Special Characters | Require each character class individually | |
| Complexity & History | Required Complexity Level | A single grade that stands for a length and a set of classes — see below |
| Password History Count | Prevent reusing the last N passwords. Set 0 to switch the check off | |
| What New Members Start On | Default Password Length, Default Complexity | The length and strength a member's password generator opens with. A starting point, not a floor — they can change it, but never below the rules above |
Member defaults can overwrite a member's generator settings with these starting values for everyone at once.
What a complexity grade means#
Choosing a grade is shorthand for setting a minimum length and a set of character classes. It is not a separate rule competing with the rows above it: the grade is expanded, and whichever of the two is stricter applies. Setting a grade never loosens a rule you set explicitly, and a rule you left off never cancels one the grade asks for.
| Grade | Expands to |
|---|---|
| Simple | 8 characters, lowercase |
| Medium | 10 characters, lowercase and numbers |
| Moderate | 12 characters, upper, lower and numbers |
| Strong | 16 characters, all four character classes |
| Very strong | 20 characters, all four character classes |
A combination nothing can satisfy is refused when you save it — asking for Very strong under a maximum length of 12 would leave every member unable to change their password at all.
Where these rules bite#
The same rules apply in two places, so a member is never held to two different standards:
- Their master password, checked on the server when they change it or recover their account.
- Their password generator, where the minimum length and the required character classes are applied and the controls are locked. See Password generator.
Members can read the rules that bind them on their own organization page, and the change-password form lists them before they start typing.
Master-password rules affect how members secure their account. Item passwords are never sent to the server in plaintext, so they cannot be checked against these rules — they are reported instead, via Password health and the organization's Security posture.
A tightened policy does not reach a password that already exists. The server cannot re-derive one, so a new rule binds at the member's next password change or recovery. Security posture counts members whose password predates the current policy so you can see how far a change has reached.
Password expiry is set on the authentication policy below rather than here, because unlike the rules above it is a prompt rather than a rule the server can enforce.
Authentication policy#
Configure under Organization → Security policies → Authentication (the page is titled Authentication Policies). A card at the top, Effective posture, states in a sentence what your members actually experience, and while a two-factor deadline is running it shows the date members must enrol by.
| Setting | What it does |
|---|---|
| Require two-factor for everyone | Every member needs a second factor to sign in |
| Require two-factor for administrators | Anyone who can change organization settings needs one, even when members do not |
| Master password expiry | How often members are prompted to change their master password |
Turning on two-factor without locking anyone out#
Administrators are required immediately. Members who were already in the organization get seven days. An admin who cannot enrol has a support path; a member who cannot work does not. Anyone who joins after you switch the policy on gets no window: the requirement is part of the seat they accepted, so they set up an authenticator at their first sign-in.
During those seven days existing members can still sign in without a second factor, and the page shows you the date they must enrol by. Members see that same date themselves, in a banner across the top of the app — they do not need access to this page to know when their deadline is. After it, a member without a second factor is sent to set up an authenticator app before they can continue — they are diverted, never locked out.
Switching the policy off and on again starts a fresh seven days rather than resuming a window that has already expired.
Once the policy covers a member, they cannot turn two-factor off. The Turn off control disappears from their Two-Factor Auth page and the server refuses the request. This applies from the moment you switch the policy on, including during the seven days — the window is time to enrol, not a chance to remove a second factor someone already has. With only Require two-factor for administrators on, this binds administrators alone; everyone else can still turn theirs off.
Master password expiry is a prompt, not a gate#
PulsVault records when a member's master password expires and prompts them to change it: they see a banner across the top of the app with a link to the change-password screen, for as long as it is outstanding. It cannot change the password for them, and it does not sign them out if they ignore the prompt.
That is a consequence of the design rather than a gap: the master password re-wraps the keys that decrypt the vault, and only the member's own device holds them. A server that could force the change would be a server that could read the vault.
Not yet available#
Single sign-on is not available. Two settings that belong with it are shown on the page, explained, with a note reading Not settable yet, and cannot be switched:
- Allow remembered devices — single sign-on will use a trusted device to release a member's vault keys, so switching this off would sign SSO members out of their own vaults. It unlocks with SSO.
- Require single sign-on — SAML/OIDC is on the roadmap for Enterprise. Until it exists, requiring it would leave your members with no way to sign in.
Session policy#
Session limits have their own page: Session & access control.
Roll out policies safely#
- Announce upcoming changes so members can prepare — the seven-day window is short if nobody expects it.
- Turn on the administrator requirement first and confirm your admins can still sign in.
- Turn on the organization-wide requirement; the page shows the date members must enrol by.
- Check in before the deadline. A member who has not enrolled is diverted to set up an app, which is fine — but it should not be a surprise.