What are zero standing privileges?

Zero standing privileges (ZSP) is a security model in which no user, service, or machine identity holds permanent access to production systems. Credentials are provisioned at the moment a specific task is approved and expire automatically when that task is done, leaving nothing behind for an attacker to find.

What does “standing” privilege mean?

Standing privilege is access that exists continuously, whether or not anyone is actively using it. An IAM user with a permanent access key and AdministratorAccess attached is the clearest example. The credentials sit in a config file, a CI secret, or a developer’s local environment at all times. On any given Tuesday afternoon when no one is running a deployment, those credentials are still fully valid. That gap between “used” and “valid” is where breaches live.

Just-in-time access is the operational opposite. Credentials are minted when a request is approved and carry a short expiration, often measured in minutes or hours. When the window closes, the credentials stop working without any manual revocation step.

Why are so many cloud identities over-permissioned in practice?

Industry research consistently finds that the overwhelming majority of cloud permissions are never used. Unit 42 and similar security research groups report that more than 99 percent of granted permissions go unused in a given period. The reason is straightforward: granting broad access once is easy, and revoking it or scoping it down requires time and organizational will that rarely materializes. Teams provision access for a task, the task finishes, and the access stays. Over months this accumulates into an environment where almost every identity can do far more than its actual job requires.

ZSP addresses this structurally rather than through periodic cleanup. When access is never permanent to begin with, there is nothing to accumulate.

How does ZSP differ from least privilege?

Least privilege and ZSP are related but measure different things. Least privilege is about scope: an identity should only be able to do what it actually needs to do, affecting only the resources relevant to its role. ZSP is about duration: an identity should only have access when it actively needs it, not before and not after.

You can achieve least privilege without ZSP. A developer could hold a tightly scoped IAM role that only allows read access to one S3 bucket, but if that role is attached permanently, it still represents a standing privilege. ZSP pushes further: even a perfectly scoped credential should not exist until the moment it is needed. In practice, ZSP implies least privilege, because issuing time-limited credentials for a specific task naturally forces you to think about exactly what that task requires.

Can a small team realistically reach ZSP?

Yes, with the right tooling. The practical obstacle is not organizational complexity or compliance overhead; it is friction. If requesting access requires opening a ticket, waiting for approval, and then copying credentials from a web console, engineers will work around it. They will store long-lived keys locally, share credentials over Slack, or ask for permanent access “just in case.” The workflow defeats the policy.

When the request-to-credential flow takes under a minute and integrates with tools engineers already use, adoption follows. ZSP is not a size-of-company problem. A five-person startup with automated just-in-time provisioning can reach it faster than a large enterprise running on manual processes.

A common misconception: ZSP does not mean zero access

ZSP is sometimes misread as a policy of denying access. It means the opposite of that. Engineers still get access to what they need; they just get it when they need it rather than holding it continuously. The goal is to eliminate the gap between “credential exists” and “credential is in use,” not to block work.

Think of it like a physical key that only works during your shift and deactivates when you leave, rather than a master key that lives on your keychain forever. The door still opens. The key just does not exist when it serves no purpose.

Korvalis is built around this model, automating the provisioning and expiry of credentials so that ZSP becomes the default state rather than an aspirational policy.