Killing Standing Privileges: Why Just-in-Time Access is the Future of PAM

If you had to pick a single control that changes the game for cloud security, you might want to choose killing standing privileges.

Identity is now the easiest way in for attackers. Gartner has warned that mismanagement of identities, access, and privilege will be the top reason for cloud security failures. Meanwhile, Verizon’s Data Breach Investigations Report shows that nearly 80% of data breaches involve the misuse of credentials.

Security professionals built traditional Privileged Access Management (PAM) around static accounts and vaults. In the cloud era, PAM must modernize beyond the static. We argue this in our new publication, Managing Privileged Access in a Cloud-First World. Just-in-Time (JIT) access, Just-Enough Access (JEA), and Zero Standing Privileges (ZSP) need to be standard controls for cloud-era PAM.

Below, learn how to move from always-on admin rights to a Zero Standing Privileges model using Just-in-Time access.

 

Why Standing Privileges Are a Liability in Cloud-First Environments

In on-prem, it was common (and sadly still is) for admins to have always-on rights to servers, databases, or network devices. As long as the perimeter was “good enough,” those standing privileges felt manageable.

Cloud changed the math:

• Resources are ephemeral. Instances, containers, and serverless functions spin up and down in seconds. Static admin accounts do not map cleanly to this behavior.
• Entitlements explode, with AWS, Azure, and GCP each exposing tens of thousands of actions. Over time, roles accumulate more rights than they need (classic privilege creep).
• Non-human identities (APIs, bots, and AI agents) dominate, often holding powerful permissions. They also lack traditional oversight, making them ideal targets.

The result is a huge attack surface made up of long-lived credentials and over-privileged accounts.

The new CSA publication explicitly calls for a decisive shift away from “traditional persistent privileged accounts” toward ZSP. In ZSP, you only grant privileged rights when needed and for the shortest possible time.

 

What Just-in-Time and Just-Enough Access Actually Mean

Just-in-Time (JIT) access and Just-Enough Access (JEA) are two sides of the same coin:

• JIT access provides privileged rights only when necessary. This is typically for a limited period and usually via an approval or ticket-based workflow. After the task completes, the system automatically revokes access.
• JEA ensures users receive only the exact permissions needed for a specific task or role, nothing more.

Together, JIT and JEA support the principle of least privilege in a practical way. They try to determine what exact permissions a given identity needs, for what task, and for how long.

This model does not just apply to classic IT admins. It should also be applied to:

• Developers deploying to production
• Finance and HR staff with access to sensitive systems
• Third-party vendors and contractors
• Non-human identities like service accounts and AI agents

In other words: if someone (or something) can perform a privileged activity, they should be brought under the same JIT/JEA model.

 

The Building Blocks of a Zero Standing Privileges Strategy

Several elements make a JIT/JEA strategy work in practice.

 

1. Time: How Long Should Access Last?

Define strict access duration limits based on the task:

• 30–60 minutes for routine admin changes
• A few hours for maintenance windows
• Longer only with explicit, documented justification

Once the window expires, the system automatically revokes access with no manual cleanup and no lingering risk.

 

2. Entitlements: What Exactly Can the User Do?

Instead of broad “admin” roles, JEA pushes you to scope entitlements narrowly:

• Create task-based roles (e.g., “rotate database credentials,” “restart Kubernetes pod,” or “approve payroll batch”)
• Remove generic rights like *:* or “Owner” unless absolutely necessary

Entitlements should only be the specific permissions essential to complete the activity.

 

3. Approvals: Who Signs Off?

Tie JIT access into your existing workflows:

• IAM/IGA tools to validate policy and risk
• ITSM systems like ServiceNow or Jira for change tickets
• ChatOps channels like Slack or Teams for quick approvals

The goal is to make justifiable requests and approvals simple while still auditable.

 

4. Auditability: Can You Prove What Happened?

For every JIT grant, you should know:

• Who requested access
• What they were approved to do and for how long
• What they actually did (via logs and, ideally, session recordings)

Comprehensive logs and real-time monitoring are key, including the ability to terminate high-risk sessions instantly.

 

5. Dynamic Risk Adaptation: Is the Context Safe?

This is where cloud-native PAM becomes powerful. Rather than static rules, you can use contextual signals (such as device posture, location, and behavior) to adapt. For example:

• If new device: Require step-up MFA or a shorter access window
• If high-risk geography: Restrict what actions are allowed
• If unusual time of day or unusual resource: Trigger extra approval

This lines up with Gartner’s Continuous Adaptive Risk and Trust Assessment (CARTA) concept. It also follows the broader Zero Trust idea of “never trust, always verify.”

 

JIT Models You Can Actually Implement

Ephemeral Accounts: Create temporary accounts on demand, tied to a specific user and task. Automatically deprovision them once the user completes their job. These are great for jump-in/jump-out access to sensitive systems or shared infrastructure.

Temporary Elevation: Temporarily escalate a regular user to a higher role (e.g., from “support engineer” to “DB maintainer”). Log the elevation, capture the approvals, and revoke rights automatically.

Justification-Based Access: Every access request requires a clear business justification, linked to a ticket or change record. This makes later forensic work and audits much easier.

Dynamic JIT Access: Advanced setups use analytics and ML to adjust access in real time based on context and risk. For example, a clean, low-risk request might be auto-approved. A higher-risk one routes to a human approver or gets downgraded entitlements.

Brokered/Remote Access: In legacy environments, you may still need to rely on jump hosts and shared accounts. CSA advises strict compensating controls:

• MFA for every session
• Per-session credential checkout with automatic rotation
• Full video or keystroke recording

 

Don’t Forget Non-Human Identities

Non-human identities (service accounts, APIs, bots, and AI agents) often require elevated access to critical resources. You must govern them with the same diligence and rigor as human privileged users.

For cloud-native PAM, that means:

• Using cloud-native constructs like IAM roles, managed identities, and GCP service accounts instead of static keys.
• Issuing short-lived tokens and ephemeral service identities rather than long-lived credentials.
• Rotating secrets automatically and keeping them in secure vaults rather than in code or configuration.
• Monitoring machine activity (API calls, configuration changes, data access) the same way you monitor human admins.

As recent industry research shows, machine identities are exploding faster than human ones. This makes them a growing portion of the identity attack surface. If you leave them out of your JIT/ZSP program, you’re leaving a huge back door open.

 

How to Start Your Journey to Zero Standing Privileges

A practical, phased approach might look like this:

Baseline your privileged landscape: Inventory all privileged identities (human and non-human) across on-prem and cloud. Identify where standing privileges are most dangerous (e.g., production cloud accounts, domain admins, or CI/CD pipelines).

Target your highest-risk use cases first: Migrate them to JIT/JEA. Use temporary elevation for admins, ephemeral accounts for vendors, and short-lived tokens for workloads.

Tie JIT into existing workflows: Integrate with ITSM, IAM/IGA, and ChatOps. Avoid making the users learn a completely new way of working.

Turn on monitoring and session recording: Make sure you log every privileged session and, where appropriate, record them. This is especially important in browser-based consoles and cloud control planes.

Iterate with data: Analyze entitlement usage and behavior to continually right-size access and refine roles over time.

 

Want the Full Picture? Read the CSA Guidance

This blog only scratches the surface of the new CSA publication. Managing Privileged Access in a Cloud-First World goes much deeper into:

• Identity and secrets sprawl
• PAM’s role in Zero Trust architectures
• Securing DevOps, CI/CD, and Infrastructure-as-Code
• Governance, compliance, and cyber insurance drivers

If you’re serious about modernizing PAM and moving toward ZSP with JIT access, the full document is well worth your time. Share it with your IAM team and use it as a blueprint to redesign privileged access—before attackers do it for you.