Modern PAM
Give people grants that expire and workloads credentials that expire, not admin accounts that stand between uses. What you cannot remove yet stays vaulted and rotated.
A vault keeps admin accounts safe, but standing
Shared accounts, checked out
In a storage-first approach, shared admin accounts sit in a vault and people check them out to work.
Access between uses
The account keeps its rights between checkouts, and its password stays valid until the next rotation.
One tool per problem
Sessions, secrets and machine identities often sit in separate tools, each with its own policy and log.
22%of breaches began with credential abuse, the leading initial attack vector. Source: Verizon 2025 Data Breach Investigations Report.
From stored privilege to access that expires
| Storage-first approach | Expiry-first approach (Zerostand) | |
|---|---|---|
| Admin access | A stored admin account, checked out and checked in. | A grant that expires, at most 30 days. |
| Linux servers | A key placed on each server, valid until it is rotated or removed. | An SSH certificate in the person's name, valid for five minutes by default. |
| Services | A secret shipped to each service and kept in its configuration. | Platform attestation: the service proves what it is and receives a credential that expires. |
| Evidence | Evidence gathered from each component's own logs and reports. | Reports, recertification evidence and a hash-chained audit log you can verify. |
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 17 October 2026.
Six capabilities, one console
Zero standing privilege
Grants to servers, databases and applications that expire on their own.
Learn more →Credential vault
The accounts you cannot remove yet, rotated on a schedule, verified and reconciled.
Learn more →Session management
Sessions brokered through Zerostand; SSH, RDP and web sessions recorded by default.
Learn more →Workload identity
Services attest with their platform identity and get credentials that expire.
Learn more →Discovery and reviews
Find accounts outside any safe; recertify who holds access.
Learn more →Approvals
Requests go to the safe's approvers or an Admin, never back to the requester.
Learn more →Four weeks on your own systems
Connect
Containers deployed on your infrastructure, single sign-on connected, one server and one database onboarded.
Remove standing access
First access requests and approvals, short-lived credentials issued, one shared account rotated.
Prove control
Sessions recorded and replayed, a break-glass drill run, the pilot accounts recertified.
Evidence
Audit trail, recertification evidence and recordings exported. Results reviewed against your criteria.
Questions buyers ask
Do we have to remove our current tool first?
No. Zerostand manages the accounts you onboard, so you can start with one safe. Once Zerostand rotates an account, the password another tool holds no longer works, so manage each account in one place.
How do we bring existing accounts in?
Discovery finds accounts on your servers and databases that sit outside any safe. You onboard them into a safe in bulk. On Windows, Linux, PostgreSQL, MySQL, SQL Server and Oracle hosts, Zerostand can then set a new password on each through a privileged reconcile account on the same host. Vaulted accounts are assigned to a safe from the safe's page.
Does it run in our environment?
Yes. Zerostand is self-hosted: it runs as containers on infrastructure you control, on-premises or in your cloud, and we operate no hosted version. Secrets are stored and used there and are never sent to us.
Does anything stay standing?
Yes. Safe members keep their access until removed, and your recertification campaigns can review that membership. Accounts that must keep a password stay in the vault, rotated on the schedule you set and verified.
Do services still need a secret?
Not with platform attestation: a service proves what it is with an identity from Kubernetes, AWS, Azure, Google Cloud or an OIDC issuer. A pre-shared secret is also supported for workloads without one.
How long is a proof of value?
Four weeks, against success criteria we agree with you in writing before week one.
See it on your own systems
Four weeks on your own servers and a database.