Walk through almost any SOC 2 or ISO 27001 audit of a cloud environment and the same category of finding shows up: too many people have standing access to production, nobody can prove it is reviewed, and the access that was granted “temporarily” never went away. It is not an exotic failure. It is the default state of a fast-growing engineering team that granted access as it needed it and never built the machinery to take it back.
This article is about why standing access is the recurring audit problem, what SOC 2 and ISO 27001 actually ask for around access control, and how just-in-time access resolves the finding at its root — not by documenting the standing access more thoroughly, but by eliminating it.
Why Standing Access Is the Finding Auditors Keep Flagging
Standing access is permanent entitlement: an engineer, a role, or a service that can reach a sensitive system at any moment, whether or not they are using it right now. It accumulates naturally. Someone needed production access for an incident eighteen months ago. A contractor needed database access for a migration last quarter. A new hire was given the same broad role as the person they replaced because that was faster than scoping a narrower one. None of it was revoked, because revoking access requires someone to notice it, question it, and act — and quarterly access reviews rarely catch anything, because by the time you review it, the standing access looks like the baseline.
Auditors flag this because standing access is where risk and provability both break down at once:
- Risk: A credential that exists but is not in use is pure downside. It cannot help anyone when it is idle, but a leaked or compromised one gives an attacker the same reach as the legitimate holder — at 2 AM, when no one is watching. The industry data is consistent on this: the large majority of cloud breaches involve compromised or over-privileged credentials.
- Provability: When access is permanent, “who has access to production and why?” has no clean answer. The honest answer is “a list of people, for reasons that made sense at the time, that nobody has fully re-verified.” That is precisely what an auditor cannot accept as evidence of least privilege.
What SOC 2 and ISO 27001 Actually Require
Neither framework says “you must use just-in-time access.” Both describe outcomes that standing access makes very hard to demonstrate and that JIT makes almost automatic.
SOC 2
The Common Criteria around logical access — CC6.1, CC6.2, CC6.3 — ask you to restrict access to authorised users, grant it based on role and need, and remove it when it is no longer required. For a Type II report, you must show these controls operated over a period. The implicit demands are: least privilege, a defensible provisioning and deprovisioning process, and evidence that access was reviewed and removed. Standing access struggles with every one of these. Least privilege erodes as entitlements accumulate; deprovisioning depends on someone remembering; and “evidence of review” is a spreadsheet whose honesty everyone quietly doubts.
ISO 27001
Annex A access-control objectives — around access restriction, privileged access management, and review of user access rights — ask for the same substance: access limited to what the role requires, privileged access tightly controlled, and rights reviewed and adjusted. ISO auditors want to see that privileged access in particular is not simply handed out and left. Standing admin on production is the archetype of what these controls exist to prevent.
The common thread is that both frameworks are really asking three questions: Is access limited to need? Can you prove it was reviewed? Can you prove it was removed when no longer needed? Standing access answers all three with “sort of, if you trust our process.” JIT answers all three with logs.
The Mechanism: Request, Approve, Time-Box, Auto-Revoke
Just-in-time access replaces permanent entitlement with a lifecycle. Instead of having access, people request it when they need it, use it for a bounded window, and lose it automatically when the window closes.
- Request. An engineer who needs access asks for it — in Slack or a console — specifying what they need, for how long, and why (a ticket, an incident, a task).
- Approve. The request routes by sensitivity. Low-risk, read-only access can auto-approve. Production admin can require one approver, or a quorum, or an on-call auto-approval tied to an active incident.
- Time-box. Access is granted only for the requested window. There is no “I’ll clean it up later.”
- Auto-revoke. When the timer expires, the entitlement is removed automatically. Nothing to remember, nothing left behind.
The crucial property is what this does to the baseline: in steady state, no one has standing access to anything sensitive. Access exists only during active, justified, time-boxed sessions. The question “who has standing admin on production?” has a new answer — nobody — and that answer is structural, not aspirational.
Why This Fixes the Audit Finding at the Root
The reason JIT resolves the finding rather than papering over it is that it changes what the evidence is. Under standing access, the evidence of good access control is a set of documents describing a process. Under JIT, the evidence is the operational record of the system itself:
- Least privilege is demonstrated because the default is zero privilege; access is the exception, scoped to a role and a window, not the baseline.
- Review stops being a quarterly spreadsheet exercise. Every grant was already reviewed — at the moment it was requested, by an approver, with a reason attached. The review is continuous and inherent, not periodic and reconstructed.
- Removal is automatic and logged. “How do you ensure access is removed when no longer needed?” is answered with “it expires automatically; here is the revocation log for every session.”
- Attribution is exact. Because each session is tied to a named human for a bounded window, “who accessed production and when?” is a query, not an investigation.
For an auditor, this is a categorical improvement. They are no longer evaluating whether to trust your process. They are reading the ledger your process produces as a byproduct.
Across Every Surface, Not Just the Cloud Console
Standing access is not only a cloud-console problem. It hides in every access surface, and a credible zero-standing-privilege program has to reach all of them — otherwise the audit finding just moves to the surface you did not cover:
- Cloud console: Time-boxed AWS, Azure, and GCP access through existing SSO, with the identity-layer assignment flipped only for the window.
- Databases: Keyless, identity-stamped access to production databases, so shared passwords stop living on laptops and every session ties to a real human.
- Kubernetes: Ephemeral kubeconfigs scoped to a role and namespace, so standing cluster-admin disappears — including for private clusters.
- VMs: Time-bound, session-recorded host access that replaces shared SSH keys and always-on bastions.
- Non-human identities and AI agents: CI/CD pipelines and coding agents that currently hold permanent credentials get seconds-level, auto-revoking access instead.
The value of running these through one engine is that the audit story is uniform. Rather than a different access model and a different log format per surface, there is one lifecycle — request, approve, time-box, auto-revoke — and one identity-stamped audit trail across all of them. When the auditor asks about privileged access to production, the answer covers console, database, Kubernetes, and VMs in the same breath, backed by the same kind of evidence.
How Cloudanix Implements Zero Standing Privilege
Cloudanix is IDP-native: it works with the identity provider you already run — AWS IAM Identity Center, Entra ID, Okta, Google Cloud Identity, and others — and flips assignments at the identity layer for the duration of a grant, rather than inserting a proxy or gateway into the path. For engineers, that means zero new tools: the same SSO portal, the same kubectl, the same SSH, the same database client. JIT is invisible until the moment someone needs access they do not currently have.
Approvals are configurable to match real operational risk — auto-approve read-only, one approver for staging, a quorum for production admin, and PagerDuty-triggered auto-approval so a live incident is never blocked waiting on a human. Requests come through Slack or the console, scheduled or on-demand. Every request, approval, session, command, and revocation is logged with the real human identity and lands in the customer’s own storage. And because access risk is correlated with the broader CIEM and posture picture, over-privileged identities flagged by posture analysis can feed directly into tightening JIT policy — closing the loop between detecting a problem and removing the standing access behind it.
Crucially, this is not a rip-and-replace project. Standing access is removed surface by surface, and because engineers keep their existing workflows, adoption does not depend on retraining the whole organisation. The access review that used to consume days per quarter becomes a report you export on demand.
The Objection: “Won’t This Slow My Engineers Down?”
The most common pushback against eliminating standing access is that it will add friction — that engineers who used to have access on tap will now wait on approvals and lose velocity. This objection is worth taking seriously, because if JIT genuinely slowed people down, they would route around it, and a control people route around is worse than no control at all (it provides false assurance).
The resolution is that friction is a policy choice, not an inherent property of JIT. The lifecycle lets you tune where the friction lands:
- Low-risk access carries no friction. Read-only access to a development environment can auto-approve instantly. The engineer requests it and has it in seconds, with the only difference from before being that it now expires and is logged. For the large majority of day-to-day access, the experience is effectively unchanged.
- Friction is reserved for genuine risk. Production admin — the access that actually warrants a second look — is where you place an approval, a quorum, or an escalation. This is access that should involve a human decision, and placing a brief approval there is not friction so much as the control the auditor is asking for in the first place.
- Incidents never wait. The scenario everyone worries about — a production outage at 2 AM with nobody awake to approve — is handled by incident-triggered auto-approval. When a PagerDuty incident is active, the on-call engineer’s access can be granted automatically for the duration, so an emergency is never blocked on a human approver.
Tuned this way, engineers feel almost nothing in their normal workflow, and the organisation still gets zero standing privilege in steady state. The teams that struggle with JIT adoption are usually the ones that applied uniform friction everywhere — requiring an approval for even trivial read access — rather than matching the friction to the risk. Done well, the net effect on velocity is close to neutral, and in some cases positive, because engineers stop filing tickets and waiting hours for manual grants that a scoped auto-approval now handles in seconds.
A Sensible Rollout Order
For a team starting from broad standing access, the highest-leverage sequence is usually:
- Start where blast radius is highest. For most teams that is production cloud console and production database access, or Kubernetes cluster-admin if the estate is Kubernetes-first. Remove standing access there first.
- Set approvals to match reality. Auto-approve the genuinely low-risk paths so engineers feel no friction; gate the dangerous ones. Friction is what drives people to work around controls, so tune it deliberately.
- Extend to the remaining surfaces — VMs, SaaS, non-human identities — so the audit finding has nowhere to migrate to.
- Replace the quarterly review with the JIT ledger. Once access is ephemeral and logged, the periodic review is redundant; the evidence is already continuous.
The Takeaways
- Standing access is the recurring SOC 2 and ISO 27001 finding because it breaks both risk and provability at once.
- Neither framework mandates JIT, but both ask for least privilege, reviewable access, and reliable removal — outcomes standing access makes hard and JIT makes automatic.
- JIT fixes the finding at the root by making zero privilege the default and turning the access record into the evidence.
- Zero standing privilege has to span every surface — console, database, Kubernetes, VMs, and non-human identities — or the finding simply moves.
- IDP-native, zero-new-tools implementation is what makes adoption realistic: engineers keep their workflows, and the quarterly access review becomes an export.
If standing admin access is the finding you keep seeing — or the one you expect your next auditor to raise — the durable fix is not to document it better. It is to make it stop existing.
Book a Free Assessment to see zero standing privilege working across your cloud, databases, Kubernetes, and VMs on one engine.
Related Resources
- What is Zero Standing Privilege?
- What is IAM JIT (Just-In-Time Access)?
- SOC 2 Readiness with JIT: How Ephemeral Access Simplifies Procurement and Compliance
- PAM for Cloud Infrastructure: Why Traditional PAM Falls Short
- User Access Review in Cloud Security: A Foundational Guide
- Kubernetes JIT for GKE Clusters: Eliminating Standing Access
- Implementing JIT Access in AWS, Azure & GCP: Complete Guide
