No permanent privileged accounts. Ever.
Zero Standing Privileges. For real.
The industry already gets ephemeral credentials. Cloud ZSP goes one step further: ephemeral identity and ephemeral authorization created on demand in AWS, Azure, GCP and AD, destroyed at expiry. No residue. No account to rotate. No blast radius post-mortem.
Not traditional PAM. We don’t vault passwords, we don’t record sessions, we don’t proxy traffic. We make the permanent privileged account disappear — and recreate it, scoped and network-conditioned, only when a human needs it.
WE run on InfraApp.
The problem
“Just-in-time access” doesn’t help if the account itself sits there between uses.
The privileged access industry has spent 15 years trying to fix a model that should not exist. Cloud ZSP doesn’t fix it — it replaces it.
Dormant accounts with live permissions
Any mature cloud has dozens or hundreds of IAM users, Service Principals and Service Accounts used a handful of times a year but existing 24/7. Each one is a spare key for the attacker.
Manual rotation nobody does right
AWS access keys, Azure client secrets, GCP SA keys. Rotated late, rotated badly, or not rotated. And the day of the incident you learn the key has been alive for 900 days.
Traditional PAM manages the mess — it doesn’t remove it
Vaults + check-out/check-in + forced rotation improves control, but the root cause is still there: the privileged account exists between uses. It only changes who guards the key.
PIM elevates onto what already exists
Azure AD PIM, IAM Identity Center. They elevate you into a pre-existing permanent role. The role’s attack surface — its Policy, its Trust — remains alive 24/7.
The premise
Ephemeral identity + ephemeral authorization. Both.
When someone on your team needs to touch production, Cloud ZSP creates on demand — inside your own AWS, Azure, GCP or AD account — a brand-new user with brand-new permissions, bound to the network origin they called from (VPN, office, specific CIDR), and short-lived.
When that TTL expires — or if the IP changes mid-session — Cloud ZSP destroys everything it created: the user, the permissions, the trust policy and the conditions. Nothing left behind in your IAM.
- The CSP itself enforces the network condition. Cloud ZSP doesn’t watch traffic: it asks AWS, Azure or GCP to reject any call that doesn’t come from the declared origin. The provider is the lock (aws:SourceIp, Azure Conditional Access, GCP IAM conditions).
- The identity is real in the CSP, not a middleman token. The dev works native (console, CLI, SDK). No captive portal, no proxy rewriting requests.
- Cloud ZSP is not in the traffic path. Zero added latency. If Cloud ZSP went down tomorrow, active sessions would keep working until their TTL expired.
- On expiry, the deletion is real and audited. We don’t mark “disabled”: we delete user, permissions, trust and conditions, and sign the deletion in the audit chain. Verifiable end-to-end.
How it works
Four layers, one single access model.
From frictionless daily work to critical-role dual approval, the mechanics stay the same: ephemeral identity, ephemeral authorization, context baked into policy.
- 01
Matrix role
Baseline access, zero friction.
Every user has a default matrix role per Workspace. When they enter the portal: no picker, no approval — Cloud ZSP creates the ephemeral identity + matrix role in the CSP. Covers low-risk daily work.
- 02
Role catalog with precomputed risk
Admin defines. Engine decides.
The admin builds a catalog. Each role carries a base risk combining permission scope + resource sensitivity. Low risk → direct grant. High risk → dual-approval workflow.
- 03
Test before publish
Zero production surprises.
When creating or importing a role, Cloud ZSP materializes it against the real CSP, verifies the permissions match expectations, deletes it, and only then marks it as verified. A role does not appear in the operator’s catalog until it has passed this test.
- 04
Declared network ABAC
Context is ephemeral too.
The user declares their network origin at request time (VPN, office, CIDR, or 0.0.0.0/0 with warning). Cloud ZSP translates that declaration into a real condition baked into the ephemeral identity. The CSP rejects if the IP doesn’t match — not passive detection, enforcement at the source.
Differentiators
Against the adjacent categories: what Cloud ZSP does that the others don’t.
This table compares what we offer against the tools that typically enter the conversation when the CISO says “privileged access to the cloud”.
| Capability | CyberArk / BeyondTrust | StrongDM / Teleport | Cloud ZSP |
|---|---|---|---|
| Eliminates permanent privileged accounts | ✕ | ✕ | Yes |
| Real identity in the CSP (not proxy) | — | ✕ | Yes |
| Ephemeral authorization, not just credential | ✕ | ✕ | Yes |
| Import native CSP roles | ✕ | Partial | Yes |
| Test role before publishing | ✕ | ✕ | Yes |
| Network ABAC embedded in the CSP identity | ✕ | Partial | Yes |
| Federated URL to CSP without exposing credentials | ✕ | Partial | Yes |
| Continuous authorization (revokes on context drift) | ✕ | ✕ | Yes |
Compliance
Designed from day one against the frameworks your regulator will audit.
Every request, every ABAC declaration, every approval, every credential issuance and every revocation is cryptographically signed and chained. Exportable as forensic evidence.
NIST
SP 800-207 Zero Trust Architecture — the conceptual north of ZSP. SP 800-53r5 AC-2 / AC-6 / AU-9 — account lifecycle, least privilege, tamper-evident audit.
NIS2
Art. 21(2)(d) — privilege separation, access control, enhanced auditability.
ENS
op.acc.5 — authentication mechanisms, privilege management, traceability.
ISO 27001:2022
A.5.15 Access control · A.5.18 Access rights · A.8.2 Privileged access · A.8.5 Secure authentication.
SOC 2
CC6 — Logical access controls, with exportable evidence for every request, approval, session and revocation.
Request access
Try Cloud ZSP against your own AWS or Azure account.
Zero-friction install — you set up a CryptoStore against your Vault or KMS, connect your cloud account with narrow permissions, and within minutes your first developer requests their first ephemeral access.