How Keeper Helps Enforce Zero Standing Privilege

Privileged accounts are standing invitations for attackers, with credentials to steal and permissions to misuse. When administrative rights are persistently active, whether or not they’re being used, privileged accounts significantly expand the attack surface. Zero Standing Privilege (ZSP) shrinks that risk by ensuring no user holds permanent elevated access. Instead, privileges are requested for a specific task, granted for a limited time, approved through a defined workflow and automatically revoked when the approved window expires. ZSP reflects a broader shift in modern security, replacing standing access with temporary access to reduce what an attacker can exploit. Keeper helps enforce ZSP by granting Just-in-Time (JIT) access and automatically revoking it when the approved window expires, moving users from zero privilege to exactly the access they need, then back to zero automatically.

Continue reading to learn the importance of ZSP, how it works in Keeper and where Keeper enforces it across environments.

Why standing privileges are a security risk

A privileged account that stays active indefinitely gives attackers a long-lasting target: the credentials don’t expire, the access is constantly available and there’s no given moment when those rights are taken away. If attackers steal or compromise one of these accounts, they inherit standing privileges in their entirety.

The bigger problem is blast radius since a compromised account with standing access rarely stops at the system for which it was intended. Attackers use standing privileges to move laterally across environments, reaching additional servers, databases and cloud resources in their paths. What may begin as a single compromised credential can quickly turn into a foothold across your entire infrastructure if the user has standing access. When privileges are permanent, access isn’t tied to a specific request, task or timeframe, leaving no clear record of why someone could reach a system at a certain moment. That ambiguity makes investigating security incidents involving standing privileges and proving compliance much more challenging.

How zero standing privilege works in Keeper

Keeper helps enforce ZSP through Keeper Privileged Cloud, which extends KeeperPAM’s JIT access framework to your identity providers and federated applications. Instead of provisioning permanent admin rights, Keeper Privileged Cloud grants elevated access only when it’s requested, only for an approved time window and only under the workflow controls you define. Users default to no privilege and elevate through a controlled, auditable process, then return to zero when the task is done. Below is how ZSP works in practice for Keeper.

Configure access policies

On a PAM Cloud record, admins define the rules of engagement using JIT and Workflow settings. This includes whether a request needs approval, who can approve it, how long access lasts once granted and which role the user is elevated into. These settings help determine exactly how privileged access is requested, approved and time-boxed, ensuring no elevation happens beyond the boundaries you set.

Share records with authorized users

Once a policy is in place, the PAM Cloud record is shared with the users who should be able to request access. Because elevation happens through your identity provider, each user needs an account in both your identity provider and Keeper tenant. With the record shared, those users can request elevated access when a task calls for it, without holding any standing privilege in the meantime.

Review and approve requests

When a user needs access, they can request it directly from their Keeper Vault or the Keeper Commander CLI. Designated approvers receive real-time notifications from tools like Slack, Teams, Jira and ServiceNow and can either approve or deny a request from any Keeper client, so requests aren’t stuck waiting for someone to be at their desk. Depending on the policy, approvers can also require a justification and a ticket number before granting access, linking every elevation to a documented reason.

Grant and revoke access automatically

After a request is approved, the Keeper Gateway performs the elevation on the identity provider or target resource, granting the user the configured group membership, role or entitlement so they gain the access the policy allows. When the approved duration expires, the Keeper Gateway automatically revokes that access, removing the temporary membership or assignment and returning the user to ZSP. It also records every elevation that requested access, who approved it, and when it started and ended so security and compliance teams have a clear, per-request account of how privileged access was granted and used.

Where Keeper enforces zero standing privilege

Keeper doesn’t confine ZSP to a single system or account type. The same JIT framework applies wherever privileged access exists in your environment, from the identity providers your users authenticate against to the cloud resources, databases and machines behind them.

Across your identity providers

Keeper Privileged Cloud extends JIT access across existing identity providers, including AWS IAM, Microsoft Entra ID, Google Cloud via Google Identity, Okta and Active Directory. Keeper grants and revokes privileges directly within your existing infrastructure, so elevation happens where your accounts already live with no disruption to how users authenticate. The identity provider remains your source of truth, while Keeper simply controls when a user is elevated into a privileged group and when they’re removed from it.

That reach is not only for the platforms themselves but also includes applications that federate access and authorization through these identity providers. Federated applications can also use Keeper for access control, allowing users to apply the same JIT model to the downstream apps that teams sign into every day.

Across cloud, databases and machines

Since ZSP isn’t just a cloud-console issue, KeeperPAM applies the same privilege-elevation framework beyond your identity providers. Using PAM Cloud, PAM Database and PAM Machine records, you can extend time-limited access to cloud resources, databases and individual machines, bringing the same lifecycle to the infrastructure behind your identity layer.

Beyond elevation, the Keeper Gateway also rotates privileged credentials so they don’t linger as static targets, and for databases and machines it can provision ephemeral accounts, injecting credentials server-side so the user never handles them. All of it sits within Keeper’s zero-knowledge architecture, meaning credentials and secrets remain end-to-end encrypted and are never exposed to Keeper or anyone else. Together, automated rotation and zero knowledge ensure that even the credentials that enable privileged access don’t persist as materials an attacker could steal and exploit.

Minimize your attack surface with Keeper

Zero standing privilege only works if it’s enforced consistently, which is where Keeper Privileged Cloud thrives. With Keeper, security teams have an auditable way to grant privileged access on demand and revoke it automatically, working through the identity providers and infrastructure you already run. Administrators get provable control over who can access what and when; users get the access they need without waiting for manual provisioning or holding on to rights they don’t.

Request a demo of KeeperPAM to see JIT access and automatic revocation in your environment.

Frequently asked questions

How is zero standing privilege different from least privilege?

Least privilege limits users to only the permissions their role requires, but those permissions are typically standing, so they stay active whether or not they’re in use. Zero standing privilege takes the idea of least privilege a step further: there is no default level of access; privileges are granted only when requested and approved, and revoked when the task is finished. Simply put, least privilege limits how much access a user can have, but ZSP shortens how long they hold it, ideally down to none until it’s necessary. Read our blog to learn more about zero standing privilege vs least privilege.

Which identity providers does Keeper support?

Keeper Privileged Cloud enforces JIT access across AWS IAM, Microsoft Entra ID, Google Cloud via Google Identity, Okta and Active Directory. Applications that federate access and authorization through these platforms can also use Keeper for access control, so the same JIT model extends to the other apps connected to your identity providers.

How do users access resources after approval?

Once an access request is approved, users can reach the resource via Keeper’s Remote Browser Isolation for a secure, browser-based session or continue using their existing workflows, like the AWS access portal or AWS CLI. Either way, access lasts only as long as it was warranted and is automatically revoked after the approved time window.