Introduction: The Liability of "Standing Access

The Problem with Always-On Permissions

Imagine you are issued a master key to every room in a hospital on your first day of work. You carry that key everywhere — to lunch, to the gym, home at night. If you lose it, or someone steals it, they instantly have access to the pharmacy, the server room, and the patient records vault. That is exactly what "standing access" looks like in software systems.

In most organizations, if you are a Senior Engineer, you are given "Admin" access on Day 1. You keep that access 24 hours a day, 7 days a week, 365 days a year, until you quit. This is called Standing Access — permanent, always-on privileges that exist whether or not you are actively using them.

Why is this dangerous?

• Attack Surface: If your laptop is compromised at 3:00 AM on a Sunday while you are asleep, the attacker inherits your Admin rights immediately. They do not need to do anything clever — your credentials are the key.
• Insider Threat: A disgruntled employee has immediate, unilateral power to delete databases, exfiltrate data, or sabotage deployments without needing to ask anyone for permission first.
• Audit Gaps: Security teams struggle to distinguish "normal" admin activity from "malicious" activity when the user always has the keys. There is no signal that separates routine access from an attack in progress.
• Credential Sprawl: Over time, people accumulate access they no longer need. The engineer who fixed one production issue three years ago still has write access to that system today.

The core problem is that standing access violates the Principle of Least Privilege (PoLP): every user, process, and system should have only the minimum permissions required to do their current job — and nothing more.

The Solution: Zero Standing Privileges (ZSP)

Just-in-Time (JIT) Access flips the model entirely. By default, no one has access to anything. Permissions do not exist until they are explicitly requested, approved, and granted — and they vanish automatically when the task is done.

When you need to fix a bug in production:

1. You request access, stating your reason and how long you need it.
2. The request is evaluated against policy (automated or human approval).
3. You are granted access for a specific, bounded duration (e.g., 1 hour).
4. The access auto-expires and is revoked without any manual action.

This drastically reduces the "blast radius" of a compromise. If an attacker steals your credentials at 3:00 AM, they inherit nothing — because you have nothing. The attack surface collapses from "everything, always" to "only what was explicitly granted, only while it was needed."