Zero Standing Privilege: The Case for Just-in-Time Access Across Humans and Machines

Every privileged account that exists right now - whether it belongs to a sysadmin, a contractor, or a CI/CD pipeline - is a credential waiting to be stolen. The access doesn't have to be used. It just has to exist. That's the standing privilege problem, and it's the root cause behind the majority of serious breaches.

The fix isn't more MFA. It's removing the privilege when it isn't actively needed.

What Standing Privilege Actually Is

Standing privilege is the default access model most organizations still run: users, service accounts, and AI agents hold permanent entitlements regardless of whether they're currently using them. A DBA has production write access at 3 AM on a Sunday. A contractor retains admin rights three months after their engagement ended. A CI/CD service account carries admin-level IAM permissions it needed once, six months ago.

Forrester highlighted Zero Standing Privilege (ZSP) architectures as the definitive new standard at its 2025 Security & Risk Summit, citing the Continuous Access Evaluation Protocol (CAEP) to dynamically assign permissions at runtime. The reason is simple: standing privilege is a dormant attack surface. The moment a credential is compromised, every permission attached to it is immediately available to the attacker - no escalation required.

The numbers make the risk concrete. Compromised privileged identities accounted for 33% of security incidents in 2024, up from 28% in 2023, according to the IDSA Identity Security report. And the problem is compounding on the machine side: 97% of non-human identities (NHIs) carry excessive privileges, increasing unauthorized access and broadening the attack surface, according to Entro Security's 2025 State of Non-Human Identities and Secrets report.

That last figure deserves a pause. Nearly every service account, API token, and workload credential in your environment has more access than it needs. All of it, all the time.

Defining JIT Access and Zero Standing Privilege

Just-in-Time (JIT) access grants time-limited, task-specific permissions to a human or non-human identity only when needed, and revokes those permissions automatically when the task is done or the time window expires. There is no persistent elevated access - only transactional elevation.

Zero Standing Privilege (ZSP) is the architectural destination: a state where JIT is the only access pattern. Nobody holds permanent privileged access at all. Every elevation is requested, policy-evaluated, time-bound, and logged.

The two concepts work together. JIT is the mechanism; ZSP is the goal.

The Four Patterns That Work

JIT isn't a single technology - it's a set of architectural patterns. Each addresses a different slice of the privilege problem.

1. Request -> Approve -> Auto-Expire

The core workflow: a user or system explicitly requests access to a specific resource, the request is evaluated against policy (auto-approved for low-risk, human-reviewed for high-risk), access is provisioned for a defined window, and revocation is automatic at expiry.

The critical design rule: revocation must never be manual - the moment revocation depends on a human remembering to act, the standing privilege problem is reintroduced. Auto-expiry is non-negotiable.

Not every request needs a human reviewer. A developer requesting read access to a non-production environment during business hours can be auto-approved. A contractor requesting admin access to a production database at 11 PM on a Friday should trigger a human review.

2. Time-Bound Grants with Tiered Approval

Policy should define approval tiers based on risk:

Access Type	Approval Path	Max Duration
Read-only, non-prod	Auto-approve	4 hours
Write, non-prod	Peer approval	8 hours
Read, production	Manager approval	2 hours
Write/admin, production	Security owner + manager	1 hour
Break-glass	Dual approval + SIEM alert	30 minutes

The policy engine evaluates the requester's role, the sensitivity of the resource, time of day, location, and recent activity patterns - not just identity.

3. Ephemeral Credentials for Workloads

For machine identities, JIT takes a different form. Workload identity federation issues tokens that are ephemeral, often expiring in an hour or less, drastically minimizing exposure risks - and workloads have no permanent, always-on access pathways.

The flow: a workload proves its identity through cryptographic attestation (a cloud-signed token, a container's service account token), a policy engine evaluates the request in real time, and an ephemeral credential is issued scoped to the specific task. When the task completes, the credential is invalid. CyberArk's 2025 Identity Security Landscape found that 42% of machine identities carry privileged access, while 61% of organizations lack identity security controls for cloud workloads. Ephemeral credentials close both gaps simultaneously.

4. Break-Glass with Full Logging

Break-glass is the emergency exit - access for scenarios where standard paths are unavailable due to an outage, compromise, or critical incident. It's necessary. It's also one of the most abused patterns in practice.

Misuse or compromise of break-glass accounts with static, highly privileged access can lead to breaches with catastrophic consequences and significant data exposure. The controls that make break-glass safe: dual approval, immediate SIEM alerting, session recording, automatic credential rotation after use, and mandatory post-use review. The audit question isn't whether break-glass was used - it's whether the organization can prove it was necessary, limited, and reversed promptly.

JIT by Audience: Three Distinct Patterns

Privileged Human Operators (Admins, SREs, DBAs)

This is the classic PAM use case, but most organizations still run it wrong - permanent admin accounts that "just exist" because removing them feels risky. The right model: zero standing admin roles. Every elevation is a JIT request tied to a ticket, a change window, or an incident. Session recording captures what was done. Access expires when the window closes.

The practical starting point: identify your highest-risk standing accounts (production database admins, cloud root accounts, domain admins), remove the standing role, and replace it with a JIT workflow. Start there before touching anything else.

External Contractors and Third Parties

Contractors are a high-risk category because their access lifecycle is managed outside your HR system. They onboard fast, their engagement scope changes, and offboarding is inconsistent. Standing privilege per user is reviewed infrequently - user access reviews occur anywhere from quarterly by the most diligent organizations to never by others. For contractors, that gap is even wider.

The JIT pattern for contractors: provision access scoped to the specific project and tools required, set a hard expiry date tied to the engagement end date, require re-approval for any extension, and auto-revoke at expiry regardless of whether anyone remembers to act. For deeper guidance on governing contractor access, see our post on Time-Bound Access & JIT Contractor Privileges.

AI Agents and Non-Human Identities

This is the fastest-growing and least-governed category. NHI sprawl surged 44% year-over-year between H1 2024 and H1 2025, with non-human identities now outnumbering human identities by 144 to 1 in cloud-native environments.

AI agents are qualitatively different from static service accounts: they can acquire privileges at runtime through tool use, OAuth flows, and role assumption. Traditional static permissions can't handle this level of autonomy. The JIT model for agents: a minimal baseline role with no sensitive permissions, JIT elevation for any operation that requires broader access, token scoping to the specific tool invocation, and automatic revocation when the task completes. Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.

For a detailed implementation guide on AI agent access patterns, see How to Govern AI Agent Access Without Killing Developer Velocity.

Three Pitfalls That Quietly Break JIT

Getting JIT on paper is easy. Getting it to actually reduce your attack surface is harder. These are the failure modes that matter.

Pitfall 1: Over-Approval (The Rubber Stamp Problem)

When every request routes to a human approver with no policy guardrails, approvers become the security model. Under pressure, approvals become rubber stamps. JIT exists on paper but does nothing operationally. The fix: policy-driven auto-approval for low-risk requests, human review only for genuinely elevated risk. Approvers should see context - the requester's role, the resource sensitivity, the time of day - not just a name and a button.

Pitfall 2: Break-Glass Abuse

Break-glass is designed for genuine emergencies. In practice, it becomes the path of least resistance when the normal JIT workflow feels slow or inconvenient. Break-glass access creates a compliance problem because the control exception often becomes the only path that matters during an incident, creating a gap between privileged action and recordkeeping that auditors cannot reliably reconstruct. The control: alert immediately on every break-glass use, require a post-use justification within 24 hours, and review patterns monthly. If break-glass is being used weekly, your normal JIT workflow is too slow.

Pitfall 3: Partial Coverage (JIT Only Where You Can Reach)

This is the most common and least-discussed failure mode. Organizations implement JIT for their cloud infrastructure and their SCIM-connected SaaS apps - and leave everything else on standing access. The long tail of SaaS tools (project management, collaboration, design, code review) often has no JIT coverage at all because the IGA platform can't reach them.

Security teams should treat JIT as a lifecycle control tied to task execution - and if the target system keeps a persistent role, a cached token, or an unrevoked API credential, JIT has not actually reduced exposure. Coverage gaps are where attackers find the path of least resistance. A JIT program that covers 60% of your app stack leaves 40% of your identities on permanent standing access.

Iden's Approach: One Policy Plane, Every App, Humans and Machines

The coverage problem is exactly what makes JIT hard to operationalize at scale. Most IGA platforms govern the apps they can reach via SCIM - and leave the rest unmanaged. That means your JIT policy applies to Okta-connected apps but not to Notion, Linear, Figma, or the internal tools your engineering team built.

Iden's universal connector technology reaches every app in your stack - whether it supports SCIM, an API, or neither - and applies the same time-bound, policy-driven access model across all of them. Human identities and non-human identities (service accounts, API tokens, AI agents) are governed in a single plane. Access requests, approvals, time-bound grants, and auto-revocation work the same way regardless of which app is involved.

The result: a JIT program that actually covers your full attack surface, not just the apps your previous vendor could reach.

JIT Rollout Checklist

Use this as your implementation sequence. Don't try to do everything at once - start with the highest-risk standing accounts and expand from there.

---

Standing privilege is a design choice, not a technical necessity. Every permanently elevated account in your environment is a bet that it won't be compromised before someone remembers to remove it. JIT access removes that bet - for admins, contractors, service accounts, and AI agents alike. The goal isn't perfect security. It's making sure that when a credential is stolen, the blast radius is measured in minutes, not months.