How Keeper Privileged Cloud Delivers Zero Standing Privilege

Keeper Privileged Cloud delivers Zero Standing Privilege (ZSP) by extending KeeperPAM®’s Just-In-Time (JIT) access framework to cloud identity platforms. A user gets elevated permissions only after a request is approved; those permissions last for a set time window, and Keeper removes them automatically once the window ends. No permanent privilege is left in place.

This blog covers the importance of zero standing privilege, how the Keeper Privileged Cloud workflow works and which platforms Keeper Privileged Cloud supports.

Why zero standing privilege matters

Every permanent admin privilege increases your attack surface, whether or not it’s being used. Permissions accumulate through privilege creep, old admin access stays active long after anyone needs it and each unused privilege widens the blast radius when credentials are stolen. The more standing access an organization holds, the more permissions an attacker inherits the moment they gain access.

Zero standing privilege takes that exposure away. No identity holds permanent privileged access. An account is elevated only during an approved, time-limited window; once the window ends, the access is gone, so nothing sits idle for an attacker to find or abuse.

JIT access is what makes ZSP practical. JIT grants permissions when someone needs them and revokes them afterward, instead of assigning them permanently. The two aren’t interchangeable: JIT controls when access is granted, while ZSP means there’s no standing privilege remaining once a user’s task is complete.

How Keeper Privileged Cloud enforces zero standing privilege

Keeper Privileged Cloud enforces zero standing privilege with a request-and-approval workflow: a user requests access to a specific resource, an approver signs off, Keeper elevates the user for a set time window and it removes that access automatically when the window ends.

Keeper Privileged Cloud is part of KeeperPAM, Keeper’s identity security platform, and applies the same JIT framework to your cloud Identity Providers (IdPs). It works with three record types: PAM Cloud Resource, PAM Machine and PAM Database. Each record requires two configurations before anyone can request access: JIT settings, which define how access is granted, and Workflow settings, which define the approval requirements, time limit, reason and ticket number.

A few prerequisites need to be in place first: a configured Keeper Secrets Manager application, a deployed KeeperPAM Gateway, Workflow-based access enabled and a PAM Configuration for a supported IdP. The Gateway is a lightweight service you run on your own network using Docker on Linux or Windows, providing outbound access to your target infrastructure.

Once that’s set up, the workflow runs like this:

If a request is denied, the record reverts to “Request Access,” and the user can resubmit.

Elevation happens at the group or role level, either at the IdP or directly on the resource. Keeper Privileged Cloud covers the IdPs most organizations already use: AWS IAM, Microsoft Entra ID, Google Cloud Platform, Okta and Active Directory, along with any application that federates through them. Keeper handles those identities directly on the resource or through a federated provider.

After access is approved, there are two ways to get to the resource. One is Keeper’s Remote Browser Isolation, launched from the Keeper Vault. The other is a standard login through the AWS portal, Command-Line Interface (CLI) or Terraform.

What Keeper Privileged Cloud gives security teams

With that workflow running through Keeper Privileged Cloud, security teams have less privileged access to defend and a clear audit trail for granted access.

A smaller attack surface

There’s no dormant privilege for an attacker to find between tasks. Because every elevation is temporary, the privileged attack surface only exists while access is in use.

Access that is approval-based, time-bound and auditable

Every elevation is requested, approved and recorded. That gives security teams a log of who requested access, who approved it and when it expired. This audit trail supports access control evidence requirements under frameworks like SOC 2, CMMC and NIST 800-53, in addition to routine internal reviews.

Consistent enforcement from one platform

The same workflow runs across every cloud and federated IdP you connect, so you aren’t managing a separate set of controls for AWS, Entra ID and Okta.

Eliminate standing privilege with Keeper

With Keeper Privileged Cloud, privileged access exists only after someone requests it, has it approved and uses it within a set window. Once the window closes, there’s nothing left to secure or steal.

To see how Keeper Privileged Cloud works against your cloud and identity setup, request a KeeperPAM demo.