Session & access control
Control how long member sessions live, how many devices can be trusted, how vault unlock sessions behave, and whether members may attach files across your organization.
Session policies bound how long access lasts once a member has signed in or unlocked their vaults. PulsVault uses a two-gate model: gate 1 is the account session (JWT-backed login), gate 2 is the vault session (created at unlock). Organization policies constrain both, and the server enforces them regardless of client settings.
Account session limits#
Configure under Organization → Security policies → Sessions:
| Setting | What it does | Default |
|---|---|---|
| Enforce session timeout | Whether the band below binds at all | On |
| Shortest allowed | Shortest inactivity window a member may pick | None set |
| Longest allowed | Longest inactivity window a member may pick | None set |
| Concurrent sessions | Cap on live sessions per platform | The member's own limit |
When enforcement is on, a member's personal preference is clamped into that band server-side — picking a longer timeout in their own settings has no effect. A member who has expressed no preference gets the longest window you allow: the band constrains them, it does not choose for them.
Enforcement on with no shortest or longest set caps nothing — the platform's own window still governs. The page tells you which of those two states you are in; check it after saving rather than assuming the switch was enough.
Two limits worth knowing before you set a number:
- Nothing shorter than 15 minutes. A session's clock is refreshed a few minutes at a time, so a tighter window would sign members out between their own requests.
- The band can only shorten a session, never extend one. PulsVault's own sign-in window still applies on top.
Concurrent sessions are counted per platform — a phone and a laptop do not compete for the same slot. Signing in beyond the limit ends the member's oldest session on that platform rather than refusing the new one, so nobody is stranded on a new device.
Security alerts#
Require security alerts, on the same page, means members are always told when their vault is opened or a device is trusted, and cannot mute those notifications in their own preferences. With it off, each member chooses for themselves.
Vault unlock sessions#
Members unlock vaults with their Access Key and choose a session duration (5 minutes, 15 minutes, 1 hour, 24 hours, or never expire). When the vault session ends, decrypted key material is wiped from the client and the member must re-enter their Access Key; logging out or closing the tab wipes everything, so the next login requires the password again.
What a new member starts on — how long their vault session lasts, whether copied secrets are cleared from the clipboard and after how long — is up to you under Member defaults. Where you set nothing, PulsVault's own defaults apply. The vault session is counted from the moment of unlock, not from the last action.
Device trust#
Trusted devices let members skip repeated verification on hardware they own. The organization's control over this is deliberately narrow, under Organization → Security policies → Devices (the page is titled Device Policies):
| Setting | What it does | Default |
|---|---|---|
| Enforce a trust ceiling | Turns the maximum trust duration on. Off by default, so you can set a ceiling and review who it affects before it binds | Off |
| Maximum trust duration | The longest window a member may choose, 1–365 days. Clear it to have no ceiling | No ceiling |
An Effective posture card at the top says in a sentence what members experience, and once you have chosen a duration a summary beneath the picker says how many members it would affect.
Two related things are not on this page:
- Allow remembered devices is shown, read-only and marked Not settable yet, on Organization → Security policies → Authentication, because single sign-on is not available. See Password & authentication policies.
- How many devices a member may trust is a per-member setting, not an organization policy.
Trust runs on a sliding window: it moves forward every time a device is used, so the number caps how long a device may sit unused before it stops being trusted — it does not sign anyone out while they are working. A ceiling is a maximum, not a fixed value: a member may still choose something shorter, and one who never set a preference inherits the ceiling automatically.
Lowering the ceiling takes effect on each member's next use, within a day. There is no migration, and the change itself never revokes a device.
Members manage their own devices in Devices and review active sessions in Active sessions.
An account or vault session proves authorization only. Encryption keys are derived and held on the member's device — revoking a session cuts off API access immediately, and the server never had the keys to begin with.
Where sign-in is allowed from#
Country and address-range restrictions live on Network & security, together with automatic IP blocking and abuse thresholds.
Access control#
Organization → Security policies → Access control holds two switches.
Keep shared credentials in organization vaults makes each member's personal vault read-only, immediately, on vaults they already have. Nothing is deleted: members can still open it and empty it, but not add to it. It reaches only their personal vault in this organization — vaults they own elsewhere are untouched, because you hold no key to them.
Allow file attachments decides whether members may attach files to vault items. Turned off, new uploads are refused — attachment bytes pass through our servers, so this one can be enforced. Files already attached stay readable: withdrawing access to what a member has stored would be a deletion, and a policy change is not a deletion.
Your vault contents are encrypted on your members' devices. An export is assembled on the member's own device from data they can already read, and the clipboard never leaves their browser — so neither can be blocked, and PulsVault does not offer a switch that would suggest otherwise. Exports are still recorded in your audit log.
Related#
- Password & authentication policies — 2FA enforcement and password rules
- Audit logs — session events are recorded in the authentication stream