Every organisation carries a quiet liability on its books that never appears in the accounts: the administrator rights, database superusers and cluster-admin bindings that people hold all day, every day, whether they are using them or not. Nobody decided to create that liability. It accumulated, one reasonable request at a time. And when an attacker gets hold of a credential, it is that standing access, not the cleverness of the attack, that decides how bad the day becomes.
This post is for anyone who has to explain access risk upwards or fix it downwards. It sets out why standing privilege is the risk you already carry, why it is so persistent, what it costs, and what replacing it with just-in-time (JIT) access really involves — including the parts that are harder than a vendor slide suggests.
In short
- Attackers increasingly log in rather than break in. Once they hold a credential, the damage is set by what that credential can do at that moment.
- Standing access is permission held whether or not it is needed. Most of it is unused most of the time, which makes it pure exposure.
- It persists for human reasons. Removing access feels risky, granting it feels helpful, and nobody owns the clean-up.
- Replacing it is an operating model, not a form. Access has to be fast to get, narrow when granted, watched while used and removed on time, or people route around it.
- Start by measuring it. A count of standing administrators and escalation paths, by system, is the number a board can follow quarter by quarter.
Most breaches log in
The popular picture of a breach is a clever exploit against an unpatched server. That still happens, but year after year the large breach studies point at something more mundane: stolen, guessed, phished or leaked credentials, and the legitimate access that comes with them. An attacker with a valid session does not trip the alarms built for intruders. They look like an employee, a contractor or a service doing its job.
data
The Verizon Data Breach Investigations Report has for several years listed the use of stolen credentials among the leading initial actions in breaches. IBM’s Cost of a Data Breach study put the global average cost of a breach at roughly US$4.9 million in its 2024 edition, and has consistently found that breaches involving compromised credentials take among the longest to identify and contain.
Sources: Verizon DBIR (multiple years); IBM Security / Ponemon Institute, Cost of a Data Breach Report 2024. Figures vary by year, region and sector; treat them as orders of magnitude.
The detail that matters for a security leader is what happens next. A credential is only as dangerous
as the permissions attached to it. A stolen session for an engineer who holds read access to one
log group for the next forty minutes is a nuisance. The same session for an engineer who has held
AdministratorAccess on the production payments account for two years is an incident
that reaches the board, the regulator and possibly the press. The attacker did the same work in both
cases. The difference was decided months earlier, by whoever granted the access and whoever did not
take it away.
What “standing access” means
Standing access is any permission that exists continuously, rather than for the period of a specific task. Some of it is necessary: a service account that runs a nightly job needs its permissions every night. Much of it is not. It tends to fall into a handful of recognisable shapes:
| Shape | Typical example | Why it is dangerous |
|---|---|---|
| Standing administrator | An engineer permanently assigned AdministratorAccess on a production account | Any compromise of that person’s session is a compromise of the account |
| Escalation path | A deployment role that can pass a privileged role to a new function and invoke it | Not an administrator on paper, one or two API calls from being one |
| Database superuser | A shared login with SUPERUSER and BYPASSRLS on a database holding card data | Bypasses every table-level and row-level control the application relies on |
| Cluster-wide binding | cluster-admin granted to a developer to debug one namespace | One namespace’s problem becomes access to every workload and secret in the cluster |
| Forgotten break-glass | An emergency administrator account unused for half a year | Rarely watched, often weakly owned, and fully privileged |
| Unused role | A migration role that was never removed after the project | Pure exposure: no business value, full blast radius |
In the demo organisation used throughout this blog, Northwind Labs (fictional), the first discovery run found eight open items of exactly these kinds: four standing administrators, one escalation path through a CI deployer role, a database login with superuser rights that had never been used, and roles unused for more than ninety days. None of them is exotic. Most security teams will recognise every line.
Why it persists
If standing privilege is so plainly risky, why does every estate have so much of it? Because every force acting on access pushes in the same direction.
- Granting is helpful; removing is risky. The person who grants access unblocks a colleague today. The person who removes it might break a job at 2 a.m. Incentives point one way.
- Getting access is slow, so people keep it. If a production read takes a ticket and two days, nobody hands it back. Slow access processes manufacture standing access.
- Roles are designed for the widest need. A pre-built role has to cover everything anyone in that team might ever do, so every holder carries the union of everyone’s needs.
- Nobody owns the clean-up. Identity teams own joiners and leavers. Platform teams own the cloud. Security owns policy. The administrator rights a mover kept from their last team belong to no one in particular.
- Reviews certify rather than question. A quarterly spreadsheet with hundreds of lines and no usage data gets approved line by line, because the reviewer has no evidence to do anything else.
data
Cloud permission studies have repeatedly found that only a small fraction of the permissions granted to identities are actually used. Microsoft’s 2023 State of Cloud Permissions Risks report found that the large majority of granted permissions went unused across the multicloud environments it analysed, and that a significant share of identities with high-risk permissions were inactive.
Source: Microsoft, 2023 State of Cloud Permissions Risks Report. Exact percentages depend on the estate and the period measured.
What it costs, beyond the breach
Breach exposure is the headline cost, but standing privilege also has running costs that show up in budgets every quarter, even in a year with no incident at all.
For the CISO
Standing administrators are the largest single multiplier on the blast radius of a phished or leaked credential. Reducing them is one of the few controls that limits damage after detection has already failed.
Every audit cycle asks the same questions about privileged access — who has it, who approved it, when it was reviewed — and standing access makes those answers long and hard to defend.
For the platform lead
Access tickets interrupt engineers on both sides: the person waiting and the person granting. Standing access is often the platform team’s defence against that interruption.
Broad roles make incident investigation harder. When twenty people could have made a change, the audit log has to be read rather than glanced at.
For the board
The question to ask is simple: how many people could take over our most important systems today, if their laptop were compromised? If the answer is not a small, named and falling number, the organisation is carrying risk it has not chosen.
Regulators and auditors increasingly expect privileged access to be limited, time-bound, approved and reviewed. Standing access makes each of those harder to show.
Replacing it: what just-in-time access actually involves
The idea of just-in-time access is simple: nobody holds powerful access by default; they ask for it when they need it, receive it for the length of the task, and lose it automatically afterwards. The execution is where programmes succeed or fail. A JIT programme that only adds a request form in front of the same broad roles produces the same exposure plus a queue. To actually reduce risk, each step of the lifecycle has to do real work.
console, Slack, CLI, API"] --> B["Draft from the catalogue
resource, level, duration, ticket"] B --> C["Narrow to least privilege
inside the entitlement ceiling"] C --> D{"Explained risk score
and access flow"} D -->|"low"| E["Approved automatically"] D -->|"medium or high"| F["Owner, named approver
or two people, step-up MFA"] E --> G["Broker in your network
creates the grant"] F --> G G --> H["Session watch
activity versus scope"] H --> I["Expiry: broker revokes
on its own clock"] I --> J["Prepared access review
and audit evidence"]
The just-in-time lifecycle in InsightKeys. Each step removes a reason people keep standing access.
In InsightKeys, that lifecycle is run by agents with a person in charge of each decision that matters. A request starts as a sentence — “read the invoices table in the payments database for INC-4412, 1 hour”. An intake agent drafts the request from the resource catalogue and never invents a resource. A least-privilege scoper narrows the permission: in one demo request, a broad read-only grant was cut down to six log actions on a single log group. A risk agent scores the request from 0 to 100 and explains every point, and an access flow decides whether that score means approve on the spot, ask the owner, ask for a second factor, or ask two people.
The grant itself is made by a broker that runs inside the customer’s own network and alone holds the credential that can change permissions. It creates a narrowly scoped permission set, role, database login or Kubernetes RoleBinding for that one grant, and removes it at expiry on its own clock, even if InsightKeys’ control plane cannot be reached. While the grant is live, a session watch agent compares what the person does with what they asked for. In the demo, a grant to read payment service logs saw an attempt to read a payment provider key from the secrets manager; AWS denied it, and the agent flagged it and asked security to approve a revocation.
Speed is a security control
The point most often missed is that JIT access only reduces risk if it is faster than the workaround. An engineer under incident pressure will choose the path that works. If that path is a shared administrator account, the programme has failed regardless of what the policy says.
A ticket, a manager’s click, a platform engineer’s afternoon. Access granted for a task is never handed back, because asking again next week would cost another day.
Low-risk requests are approved in seconds, on-call engineers working an open incident get context-aware routing, and expiry is automatic. Holding access buys nothing.
That is why the risk score treats context as evidence. An engineer who is on call for the team that owns the resource, working a referenced open incident, asking for a narrow scope for one hour, scores lower than the same request from someone else at midnight with no ticket. The weights are visible and owned by the customer. Low-risk requests can be approved automatically where the access flow allows it; risky ones get a second factor and, above a threshold, two approvers who are never the requester.
What it does not solve
Honest limits
Just-in-time access shrinks the window and the scope of privilege; it does not make a compromised session harmless during that window. It also only covers the systems it is connected to. InsightKeys 1.0 grants through AWS IAM Identity Center, AWS IAM, PostgreSQL and Kubernetes; Google Cloud, Azure, MySQL, Snowflake, GitHub and others are planned, not available today. Machine identities that genuinely need continuous permissions remain standing by design and need least-privilege work of their own. And no tool removes standing access by itself: someone has to decide, system by system, that the old administrator rights go.
There is also a cultural cost. Engineers who have held broad access for years will notice its absence, and the first weeks of a programme are where trust is won or lost. That argues for starting with one team and one system, proving that access arrives quickly, and expanding from there rather than switching off administrator rights across the estate in one weekend.
Where to start
The first step is measurement, because it turns an abstract risk into a list with owners. Run discovery over the accounts, databases and clusters that matter most. Count the standing administrators, the escalation paths and the access unused for ninety days or more. Then put the count in front of the people who own those systems.
See it
- Install the broker in one network and connect discovery
- Publish the count of standing admins and escalation paths by system
- Pick one team and one production system to move first
Move one team
- Requests by sentence in Slack or the console
- Auto-approval for low-risk reads only
- Convert that team’s standing admin to on-request access
Prove it
- Run the first prepared access review
- Export grants and reviews as audit evidence
- Report standing admin left, and time to access, to leadership
Those two numbers — standing administrators left, and how long it takes to get access — should move in opposite directions. If standing admin falls while time to access stays short, the programme is working. If both rise, people are routing around it.
The breach you fear will probably start with a valid login. What it can do next was decided long before.
Standing access is a choice made by default. Measure it, make access fast enough that nobody needs to keep it, and let it expire on its own clock.