Zero standing privilege
Give people access to servers, databases and applications as a grant with an expiry. When the window closes the access is gone; nobody has to remember to revoke it.
Standing access is the access attackers use
Admin rights that never end
Access granted for one project is still valid years later, ready for whoever steals the login.
Revoking depends on memory
Taking access away is a manual ticket that nobody files when the work is done.
Shared logins hide the person
When a team shares one account, the log names the account, not the person at the keyboard.
22%of breaches began with credential abuse, the leading initial attack vector. Source: Verizon 2025 Data Breach Investigations Report.
Access with an end, by default
Every grant expires
A grant carries an expiry, at most 30 days. Longer access belongs in safe membership, not a grant.
Policy on every connection
Each connection is checked against policy as it opens: who, to which system, as which account.
Certificates, not keys, for SSH
A Linux login uses a certificate in the person's name, valid for five minutes by default; no per-user key sits on the server.
A name on every session
A session on a vaulted password holds it for one person, and an SSH certificate names one person, so every session is tied to a name.
Passwords shown only with a reason
Revealing a password needs a stated reason and is audited. An account Zerostand can rotate is then rotated after a grace period you set (four hours by default).
Sessions with a time limit
Sessions end at a maximum length you set, and the end is audited.
From request to expiry
Request
Pick the safe, or one account in it, and say how long you need.
Decide
An approver for that safe decides. A request becomes a grant only when approved.
Connect
Open the session in the browser (Linux, Windows, PostgreSQL, web applications) or your own client (PostgreSQL, MySQL). Zerostand supplies the credential; you are not shown the password.
Expire
When the window ends the grant authorizes nothing; any session still open on it is cut within 30 seconds.
The systems your admins already use
- Linux over SSH
- Windows over RDP
- PostgreSQL
- MySQL
- SQL Server
- Oracle
- Kubernetes
- Web applications
A grant can cover any vaulted account; sessions are brokered for Linux, Windows, PostgreSQL, MySQL and web applications.
Questions buyers ask
How is zero standing privilege different from just-in-time access?
Just-in-time access grants privilege on request. Zero standing privilege goes further: nothing is held between uses. Every Zerostand grant expires on its own.
Do we need agents on our servers and databases?
No. Zerostand reaches targets over the protocols they already speak: SSH, WinRM, RDP and the native database protocols. Linux servers need one sshd setting to trust the Zerostand certificate authority.
Is anything still 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.
Who approves a request?
An approver for that safe, or an Admin; never the requester. A safe can require more than one approval, a chain of approvers, and a ticket reference with each request. Requests, approvals and refusals are audited.
What happens to an open session when the grant ends?
It is ended. Every 30 seconds Zerostand re-runs the check each open session passed at connect, so one whose grant has expired or been revoked is cut within that interval, and the cut is audited.
Which systems open a brokered session?
Linux, Windows, PostgreSQL and web applications open in the browser; PostgreSQL and MySQL in your own client, MySQL only there today. SQL Server and Oracle accounts are vaulted, rotated and revealed only with a reason, but have no brokered session. Kubernetes gets short-lived service-account tokens.
See it on your own systems
Four weeks on your own servers and a database.