Built around expiry, not storage.
A vault keeps secrets safe. Zerostand makes most of them unnecessary, and keeps the rest rotating.
Storing privilege vs. expiring it
Privileged access management began with storing credentials safely. Zerostand starts from the other end: issue access that expires, and store only what cannot be removed yet. The table compares the two design approaches, not specific products.
| Storage-first approach | Expiry-first approach (Zerostand) | |
|---|---|---|
| Default | A stored credential is checked out and checked in. | A credential is issued with an expiry; only what cannot be removed is stored. |
| Machines | Workload access is commonly handled by a secrets-management component. | Workload identity uses the same policy and audit as people. |
| Consoles | Capabilities may span more than one console or module. | One console for people, workloads and accounts. |
| Policy | Policy is commonly configured in the administration interface. | Policy as code, tested end to end before you rely on it. |
| Sessions | Recording is commonly delivered by a session-management component. | Brokered sessions recorded by default; coverage per system on Supported systems. |
| Deployment | Deployment models vary: SaaS, appliances, software, agents. | Containers on your infrastructure; targets reached over SSH, WinRM, RDP and native database protocols. |
| Key custody | Options vary by vendor and deployment, including HSMs and vendor-managed keys. | Envelope encryption under a key-encryption key you configure: a passphrase or your HashiCorp Vault Transit; cloud KMS and HSM on the roadmap. |
This table contrasts two design approaches. It does not describe any particular vendor's product. Many products combine both approaches and change over time, so check current documentation for any product you evaluate. Information as at 14 October 2026.
The production bar
The unglamorous requirements that stop a security product going live ship in the product: switch on the PostgreSQL store, high availability and a key-encryption key at install.
TLS by default
Zerostand's own endpoints use TLS by default. Connections to targets can require a verified certificate; internal hops can sit behind your TLS proxy.
Highly available
Active and standby nodes on PostgreSQL with leader election. If the active node fails, the standby takes over.
Keys you hold
Envelope encryption; the key-encryption key stays in your custody once you configure a passphrase or HashiCorp Vault Transit. Signing keys rotate with a grace window.
Sealed break-glass export
A sealed offline export of the break-glass accounts, encrypted to offline keys your security team holds.
Everything audited
Grants, approvals, rotations, sessions, administrative changes: who and when, and the reason wherever one is given.
Credentials in the vault
Credentials for your servers and databases live only in the encrypted vault. The few secrets Zerostand needs to start can come from mounted secret files.
Observable
Metrics, health endpoints and a rotation-health view operators actually use.
Provisioned, not hand-made
SCIM for people and groups; trust rules for fleets of workloads.
Architecture
A control plane that decides and issues, enforcement points that verify on their own, and targets reached over the protocols they already speak.
- Attestation
- Policy as code
- Approvals
- Lease issuance
- Safes and rotation
- Session broker
- Recording
- Audit
See it on your own targets
Thirty minutes. One server and one database you choose.