What Zerostand connects to.
Every system in the current release, with what Zerostand can do to it. A dash means not available yet.
As at 14 October 2026. Listed systems are those tested with the current release; supported versions and support terms are set out in the documentation and your agreement. Names on this page identify the systems Zerostand connects to. Their use does not mean those vendors endorse Zerostand or have a partnership with us.
Servers reached without the password being shown
Linux over SSH certificates, Windows over RDP in the browser. Local accounts rotated; domain accounts are not in this release.
| System | Access | Rotation | Dynamic credentials | Recording |
|---|---|---|---|---|
| Linux | SSH with a short-lived certificate from the Zerostand CA | ✓ local accounts | — | ✓ replay and live view |
| Windows | RDP in the browser with a vaulted password | ✓ local accounts | — | ✓ replay |
| SFTP | File transfer over the same SSH certificate | — | — | — |
✓ available as at 14 October 2026 · — not available yet
Rotation on four engines, sessions on two
The proxy that records statements covers PostgreSQL fully and MySQL in part. The other engines get rotation, short-lived logins, or both today.
| System | Access | Rotation | Dynamic credentials | Recording |
|---|---|---|---|---|
| PostgreSQL | Proxied session, statements logged, SQL command filtering | ✓ | ✓ | ✓ |
| MySQL | Proxied session, partial coverage of the protocol | ✓ | ✓ | Partial |
| SQL Server | — | ✓ | ✓ | — |
| Oracle | — | ✓ | — | — |
| MongoDB | — | — | ✓ | — |
Discovery of accounts covers PostgreSQL, MySQL, SQL Server and Oracle. Dependency rotation is not in this release.
Tokens that expire, not a proxy
Zerostand mints short-lived service-account tokens for a cluster. It does not sit in front of the Kubernetes API.
| System | Access | Rotation | Dynamic credentials | Recording |
|---|---|---|---|---|
| Kubernetes | Dynamic service-account tokens; no API proxy | — | ✓ | — |
Consoles that only have a shared login
An isolated browser signs the user in with the vaulted credential and records the session. FortiGate is the web console we have tested so far.
| System | Access | Rotation | Dynamic credentials | Recording |
|---|---|---|---|---|
| Web applications | Isolated browser session with credential injection | — | ✓ HTTP applications | ✓ |
| FortiGate | Isolated browser session with credential injection; tested by Zerostand | — | — | ✓ |
Other web consoles are onboarded case by case. Discovery covers FortiGate.
People sign in where they already do
OIDC single sign-on and SCIM 2.0 provisioning. SAML is not in this release.
| System | How Zerostand uses it |
|---|---|
| Okta | OIDC single sign-on; SCIM 2.0 for users and groups |
| Microsoft Entra ID | OIDC single sign-on; SCIM 2.0 for users and groups |
| Auth0 | OIDC single sign-on |
| OIDC single sign-on | |
| MFA | TOTP and per-target step-up in Zerostand. Phishing-resistant methods come from your identity provider over OIDC. |
Services prove who they are
A workload attests with the identity its platform already gives it and receives a JWT credential that expires.
| System | How Zerostand uses it |
|---|---|
| Kubernetes | Service-account token attestation, scoped by namespace and account |
| AWS | IAM role identity attestation, including EC2 instance roles |
| Azure | Managed identity attestation |
| Google Cloud | Service-account identity attestation |
| OIDC issuer | Generic OIDC attestation, for example from CI; one issuer per deployment |
Credentials are short-lived JWTs, available as JWT-SVIDs. X.509-SVIDs and mTLS identities are not in this release.
A ticket checked before the grant
A request can require a ticket, and Zerostand checks it is open before the grant; you choose whether an unreachable ITSM blocks or is logged. Notifications go by email.
| System | How Zerostand uses it |
|---|---|
| ServiceNow | Live ticket check before an access request is granted |
| Jira | Live ticket check before an access request is granted |
| Approval and access notifications. Slack and Teams are not in this release. |
Every event where your analysts look
The hash-chained audit log forwards to your SIEM; operators get metrics and health endpoints.
| System | How Zerostand uses it |
|---|---|
| Webhook | Audit events forwarded as they are written (best effort; the local log stays the record of truth) |
| Syslog | Audit events forwarded as they are written over UDP or TCP (best effort; the local log stays the record of truth) |
| Prometheus | Metrics and health endpoints for the control plane and rotation |
The key that unlocks the vault
Secrets are envelope-encrypted once you configure a key-encryption key, from one of two places in this release.
| System | How Zerostand uses it |
|---|---|
| Passphrase | Key-encryption key derived from a passphrase held by your operators |
| HashiCorp Vault Transit | Key-encryption key held and used inside your HashiCorp Vault; Zerostand asks it to wrap and unwrap, and the key stays inside your Vault |
| Cloud KMS and HSM | On the roadmap; not in this release |
Unusual targets can be rotated through a drop-in handler run by the Zerostand Runner; it never holds vault keys.
Missing a system you run?
Tell us which. We will say plainly whether it is shipped, planned or not on the list.