Workload identity
A service proves what it is with the identity its platform already gives it. With platform attestation, no secret is shipped to it first.
Machine secrets outlive the code that uses them
Secrets shipped to every machine
Passwords sit in config files and environment variables, and every copy is one more place to leak.
API keys that never expire
A key created for one integration stays valid until someone remembers to revoke it.
One key, many callers
When services share a key, the log cannot say which one made the call.
64%of valid secrets found in public repositories in 2022 were still active four years later. Source: GitGuardian, The State of Secrets Sprawl 2026.
Identity from the platform, credentials that expire
Proof from the platform
Platform proof is checked against the platform's published keys, or replayed to AWS STS.
Credentials that expire
Each identity credential lasts five minutes by default; you set that lifetime for the deployment.
Trust rules enrol a fleet
A rule enrols machines whose attested identity matches a pattern, such as AWS roles named payments-*.
Policy decides the reach
Signing in reaches nothing on its own. Each request through a Zerostand enforcement point is checked against policy, and the decision is audited.
Database logins that end
A machine allowed by policy gets its own database login, dropped when its lease ends.
Signing keys you rotate
Rotate the token-signing key from the console; the old key stays published for 24 hours by default.
From proof to expiry
Prove
The service sends proof from its platform.
Enrol
Zerostand checks the proof, and that the machine is registered or matches a trust rule.
Issue
It returns a signed, short-lived credential.
Reach
Zerostand's enforcement point verifies the credential against the published keys and checks policy before it answers.
The platforms your services already run on
- Kubernetes
- AWS
- Azure
- Google Cloud
- OIDC issuer
- PostgreSQL
- MySQL
- SQL Server
- MongoDB
Identity on the first five (one Kubernetes cluster, one Azure tenant and one OIDC issuer per deployment); short-lived logins on the four databases.
Questions buyers ask
Do we have to ship a secret to the workload?
Not when it has a Kubernetes service account, an AWS IAM role, an Azure managed identity or a Google Cloud identity token, or holds a token from your OIDC issuer; you switch each method on by configuring it. For systems with no platform identity, a pre-shared secret is available; with platform attestation, no secret is shipped first. Trust rules never admit a machine that uses a shared secret.
How long do credentials live?
An identity credential lasts five minutes by default, set for the deployment; a database login's lifetime is set separately. Disabling a machine stops new credentials; one already issued runs until it expires.
Is it SPIFFE compatible?
Zerostand issues JWT-SVIDs, signed with ES256 and naming the machine's SPIFFE ID, verifiable from the published keys. X.509-SVIDs and the SPIFFE Workload API are not available.
Which languages have a client?
Go. The Go client sends the proof, caches the credential and gets a new one on the first call within 10 seconds of expiry; helper packages produce the AWS, Azure and Google Cloud proofs. Other languages call the HTTP API, one POST for a credential.
Can a workload get a database login?
Yes: a read-only login on PostgreSQL, MySQL, SQL Server or MongoDB. A failed drop is retried. If the resource server restarts before the lease ends, the login is not dropped: a PostgreSQL login still stops working at its expiry time; MySQL, SQL Server and MongoDB logins remain until removed. Kubernetes service-account tokens and HTTP application accounts are issued the same way. Oracle is not offered.
Is a machine's access recorded like a session?
No. A machine calls with its credential and opens no session to record. Each credential issued and each policy decision is audited.
See it on your own systems
Four weeks on your own servers and a database.