Network & security
Restrict where your members may sign in from, and how PulsVault's automatic IP blocking protects every sign-in.
Organization → Security policies → Network access is where you decide which countries and address ranges your members may sign in from. Underneath it, PulsVault runs an always-on IP blocking system that shields every sign-in from brute-force and credential-stuffing attacks — you do not configure that one; it is described at the end of this page so you know what already protects you.
Where members may sign in from#
Configure under Organization → Security policies → Network access. Two allowlists, both empty by default, which means "anywhere".
| Setting | What it does |
|---|---|
| Permitted countries | Sign-in is refused from outside these countries |
| Permitted address ranges | Sign-in is refused from outside these CIDR ranges |
When both are set a member must satisfy both — the right country and a permitted range. Setting only one constrains only that one.
Both lists match the address a request appears to come from, which a VPN or a proxy changes in a minute. They are evidence that access from elsewhere is refused — useful to an auditor — not a barrier that stops someone determined. Say that internally too: a team that believes otherwise will make worse decisions elsewhere.
Changes are staged, then saved together#
Adding or removing a country or range changes a draft, not the policy. New entries are marked Not saved, the summary at the top shows what the policy would do next to what it does today, and a bar at the bottom offers Discard or Save policy. One save is one change to what is enforced and one entry in the audit log — so listing three office ranges never holds everyone to the first one while you type the other two.
Your connection#
The Your connection card shows the address and country PulsVault sees for you right now, and whether the saved policy admits it. Add my country and Add this address put your own connection into the draft in one click.
A save that would refuse your own connection is rejected with the reason, and your draft is kept so you can fix it. The policy applies to you like anyone else, and saving one that excludes you would take away the only session able to correct it. To set up an office-only policy, add the office's range while you are connected from the office.
Behaviours worth knowing#
- Members outside the policy are refused at their next sign-in or session refresh. A session refreshes within the hour on the web and within 24 hours in the mobile app, so a tightened policy reaches every web session within about an hour and every mobile session within a day. Nobody is cut off mid-request, and nobody outside the policy keeps working past their next refresh.
- An address we cannot place is treated as outside the list. The alternative would make the control depend on our location lookup staying up.
- Emptying a list widens access. With both empty, members may sign in from anywhere — the page warns you before you save a draft that has that effect.
- These lists govern people signing in, not machine keys. An access key used by the CLI or a CI pipeline has its own optional address allowlist — see API keys.
Automatic IP blocking#
This runs for every organization and needs nothing from you. Every failed sign-in is recorded with its source address; when one address fails too often in a short window, it is blocked automatically.
| Parameter | Value |
|---|---|
| Failure threshold | 5 failed attempts |
| Counting window | 30-minute sliding window |
| Block duration | 60 minutes, then auto-expires |
| Response while blocked | 403 Forbidden on every request |
The sliding window means real users who mistype a password a few times recover naturally — only sustained failure patterns trigger a block, and blocks always expire on their own. A member who is blocked can simply wait for the block to lift; PulsVault support can lift it early.
Do not confuse this with the lists above. Those decide who may sign in; this decides which addresses are temporarily refused for behaving like an attack.
Data residency#
The Require data residency switch is visible and cannot be set. Storage is configured per environment rather than per organization, so nothing can honour it yet — and a switch that told you your data had moved when it had not would be a false claim in the one place a false claim does most damage. It unlocks when region-aware storage ships.
Data retention#
| Data | Kept for |
|---|---|
| Failed attempt records | 30 days |
| Blocked IP records | Until expiry + 7 days |
Expired records are purged by a nightly cleanup job.
Related#
- Abuse protection — the security-reviewer view of this system
- Session & access control — session and device limits
- Password & authentication policies — the other half of login hardening