Platform
Company vault
- Items
- 64 items
- Members
- 9 members
AES-256-GCM
Business plan · 3 to 500 seats
Run your team’s access like a system, not a spreadsheet.
Company-owned vaults, role-based access, policy controls and an audit trail you can verify — with secrets for your pipelines under the same roof.
Cancel anytime.
pulsvault.com/console/vaults
Vaults
New vaultFinance
Company vault
- Items
- 27 items
- Members
- 4 members
ChaCha20-Poly1305
Support
Company vault
- Items
- 41 items
- Members
- 12 members
AES-256-GCM
Personal
PrimaryPrivate vault
- Items
- 18 items
- Members
- 1 member
AES-256-GCM
- Team size
- 3 to 500 seats
- Price
- Storage
- Free trial
What changes for your organization
Passwords shared in chat and keys sitting in somebody’s head are an access-control problem. These are the three things Business is built to fix.
Onboard on your terms
Invite people by email or in bulk, restrict joining to domains you have verified, and put them in teams that already hold the right access.
Offboard with a clean closeout
Removing a member closes their account in your organization and ends their access. Vaults they could open are flagged for key rotation, which an administrator completes on their own device.
Produce evidence when asked
A hash-chained audit log with integrity verification and signed receipts gives auditors something they can check, not just something they can read.
People and access
Decide who joins, what they can reach and how that is reviewed — from the first invitation to the day someone leaves.
Invitations and bulk provisioning
Add people individually or in bulk, review what any one member can reach, suspend someone temporarily, or remove them.
Verified company domains
Prove you own a domain with a DNS record, then choose whether you can invite verified domains only, a list of addresses, or anyone.
Teams
Group people into teams and grant a team the vaults it needs. Because the server never holds vault keys, a grant is finished by a member who does.
Custom roles, safely delegated
Build roles from the permissions that exist. Granting a permission needs a permission of its own, so delegation cannot quietly escalate.
- Custom roles
Access Report
See who can reach what, by member or by resource, with the route each grant takes. Read-only.
A Home that fits the job
The organization Home opens on the view your permissions earn — Owner, Administration, Billing, Audit, DevOps, your teams, or your own work. A section you cannot read shows a dash, never a zero.
Members see their own standing
Every member has a page for the organization they belong to: their role, the permissions they hold and where each comes from, their teams, and the history of changes to their membership.
Seats you control
See who holds each seat, buy seats before you invite, and remove seats nobody uses.
Vaults the company owns
Shared credentials should outlive the person who created them. Company vaults, custodians and sharing rules keep that true without handing everyone the keys.
Company-owned vaults
Credentials belong to the organization rather than to whoever created them, so a departure does not take a vault with it. Named custodians hold the keys.
Custodians as a revocable grant
Choose who may hold a key to company vaults. Revoking the grant stops them receiving keys to new vaults; it does not take back a key to a vault that already exists.
Rules for sharing
Set organization-wide rules for external sharing, re-sharing, secure links and share expiry.
Approval queue for shares
Require administrator sign-off on new shares. Pending invitations wait in a queue to be approved or rejected.
Backups, restored as new vaults
Company vaults are backed up every night. Administrators can take an extra backup before a big change and restore as a new vault, never over the live one.
- Backups kept on Business
Policies that apply to everyone
Set the baseline once. Sign-in rules, sessions, encryption and network limits apply across the organization, and the Security Center shows whether they hold.
Password and sign-in rules
Enforce password complexity, multi-factor authentication and login rules for everyone, with a grace period for people already in.
Sessions and devices
Control how long sessions live, how many devices can be trusted and how vault unlock sessions behave.
Encryption policy
Choose which algorithms the organization’s vaults may use and set the default for new vaults.
Network policy
Restrict where members may sign in from, by country or IP range, on top of automatic IP blocking that protects every sign-in.
Rollout defaults
Start people with the right configuration already in place: member defaults, a setup checklist, and CLI and pipeline commands with your own values filled in.
DevOps secrets
Secrets for people and machines
The machine plane runs beside your vaults under the same roles and audit trail. It is its own boundary: secrets are encrypted at rest and decrypted by PulsVault’s servers when an authorised key reads them, which is what lets a pipeline use them.
Terminal
# Names only, nothing runs
pulsvault run -n prod/product/web --dry-run
# Run a deploy with those secrets
pulsvault run -n prod/product/web -- ./deploy.shMachine identities
Service accounts and API keys for your CI/CD runners, so pipelines never borrow a person’s credentials. They are not billed as seats.
Namespaces and environments
Secrets live in namespaces per project and environment, with seeded defaults and environments of your own.
Keys scoped to a path
Limit a machine key to the paths and actions it needs, with wildcards and a clear evaluation order.
CLI, GitHub Actions and GitLab CI
Load secrets into a pipeline and gate a deploy on whether those credentials still work.
History and restore
Every change keeps a version. Preview a restore before it applies, and see who deleted what.
- Versions kept on Business
Credential validation
Know the credential still works, not just that it is stored
A secret store tells you what you saved. Validation checks, on a schedule, that each stored credential still authenticates, and tells you the moment one stops. It reaches services that are open to the public internet.
pulsvault validate … && ./deploy.sh acts on them. Scheduled checks on the credentials you store
Built-in probes authenticate against AWS, GitHub, PostgreSQL, MySQL and MariaDB, Redis and any HTTP API that takes a bearer token, basic auth or a custom call, and record whether the credential still works.
- Fastest re-check on Business
- Run history kept on Business
Re-checked when you rotate
Writing a secret checks its path straight away, so a rotation is known to work, or known to be broken, before the next scheduled run.
Test before you save
Validate now runs the configuration on screen, saved or not, and the Test Lab runs any probe once against values you type, which are never stored.
Build a check once
Save a working check as a template and apply it to every path that holds that kind of credential. Rotating the secret never touches the template.
History you can read
Every run is recorded with its result, duration and reason. See uptime, latency and a breakdown of failure reasons, filter by result, trigger or date, and export the records as CSV.
Alerts that stay believable
A failure becomes an alert only once it is certain, then escalates and reminds on a schedule. Acknowledge or snooze it, route it to Slack, a webhook or email, and use Send test to prove delivery before you need it.
A gate for your deploy
pulsvault validate returns an exit code that names the outcome, so a pipeline can stop on a failed credential and retry on a check that could not complete. validation-status with --max-age asks without probing again.
Safe by design
Probes only authenticate, and every built-in probe is read-only. Secret values never appear in validation history. Private-network addresses are refused with a message on the field when you save.
Security Calendar
Every date that can hurt you, on one timeline
Keys expire, access lapses, devices stop being trusted and deadlines pass quietly. The Security Calendar gathers them, counts what is due and reminds you before it is.
One timeline for dates that can hurt you
API keys and recorded expiry dates, role and share expiry, DevOps access policies, trusted devices, password and two-factor deadlines, renewals, validation problems and scheduled deletions, all in one place.
Deadlines, counted honestly
The strip counts what is overdue and what falls in the next 7, 30 and 90 days, with how many are critical or a warning. A credential that is failing right now is an ongoing issue, never counted as overdue.
The organization’s dates, too
Members who can see the Security Center get a Mine / Organization switch: expiring roles, machine keys and DevOps policies, pending invitations, and who must enrol in two-factor by when. Facts about many members are grouped into one line.
Reminders before it lapses
API keys are announced 30, 14 and 3 days ahead and on the day, DevOps access policies 14 and 3 days ahead, and a deleted project 3 days before it is purged.
Your own events and tasks alongside
Add your own events, including repeating ones, and see your task deadlines on the same timeline.
Export to your calendar app
Download what you are looking at as an .ics file. By default it carries only kinds and dates, so it is safe to import anywhere; adding titles and names is a separate choice.
Security you can measure
Measure it, show it, and let people see their own
Administrators get a posture they can trust and members get the same transparency back. Nobody can read a credential to produce it: the figures are counts, computed on each person’s own device.
A score that cannot hide a bad credential
The organization score comes from total credential counts, not an average of member scores, so one breached production password cannot be averaged away. “No data yet” is shown as no data, never as zero.
Which way it is moving
A 30-day line and a change figure show whether the score is rising or falling, with a link to the full trend.
Counts, never contents
Administrators see how many credentials are weak, reused, old or breached, and who has no second factor. Those counts are computed on each member’s own device; the name or content of a credential is never visible to anyone.
Members see the same report
Account → Security & compliance shows each member the identical row their administrators see, not a summary of it. The audit trail is a separate record, and the same page explains what it holds.
My security
Every person gets their own dashboard: a score out of 100, a ranked list of recommendations that shows how many points each one is worth, and an on-device scan for breached, weak, reused and stale passwords.
A weekly report, if you want it
Turn on the weekly security report and everyone who can read the posture page gets the score, its movement and the people counts on Monday morning, plus how many credentials are failing validation and how many machine keys expire within 30 days. A quiet week sends nothing.
Projects and tasks, next to the secrets
Turn a vault into a project, delegate the work and keep the credential where it lives. Tasks are raised by people and approved by people — nothing is created behind your back.
Example tickets, shown for illustration.
Projects with ticket keys
A project holds vaults, task workflows, DevOps secrets and its own members, and a short key like ENG numbers every task inside it.
Delegation that names its target
A task points at the credential or namespace it concerns and the action requested, instead of carrying the secret in its description.
Review before it applies
Route a change through approval, with assignees and watchers on a status board.
Audit and compliance
Evidence your auditors can check
The audit trail is designed to support evidence for frameworks such as SOC 2, ISO 27001 and GDPR Article 30. It records security-relevant actions, and changes to it are detectable.
A hash-chained audit log
Security-relevant actions are recorded in a chain, so altering or removing an entry is detectable.
Business plan Integrity verification
Verify the chain on demand and keep the history of every check.
Business plan Signed receipts
Download signed receipts showing what the chain looked like at a point in time, so the proof is yours to keep.
Business plan SIEM streaming
Forward audit events to your own monitoring over a webhook, signed with HMAC-SHA256 when you configure a secret.
Business plan Long audit history
Business keeps audit history far longer than Team, so it can cover a compliance window.
- Audit history
A separate trail for sharing
Share, link and invitation events are recorded on their own chain, so sharing can be reviewed without wading through everything else.
Reports centre
Scheduled reports, a trace explorer and analytics for the organization. Exports are themselves recorded in the audit trail.
Where Business sits
Each plan keeps everything in the one before it.
| Capability | Team | Business | Enterprise |
|---|---|---|---|
| Seats | |||
| Audit history | |||
| Integrity verification | |||
| SIEM streaming | |||
| Company vault backups kept | |||
| Custom roles | |||
| Organization backup archive to your own storage | |||
| White-label branding |