TL;DR: OCI teams often drift into standing access because manual role creation is faster in the moment, while just-in-time provisioning keeps permissions short-lived, scoped and auditable, according to P0 Security. The practical issue is not authentication alone, but whether least privilege survives real operational pressure without becoming permanent by default.
At a glance
What this is: This is a video about using just-in-time, least-privilege provisioning to keep Oracle Cloud Infrastructure access ephemeral instead of standing.
Why it matters: It matters because IAM and PAM teams need controls that let engineers work in OCI without leaving persistent permissions behind in the session, audit, and offboarding lifecycle.
👉 Watch P0 Security's video on just-in-time OCI access and least privilege
Context
OCI access often breaks down at the handoff between authentication and authorization. A user can sign in through SSO and still have no effective permission to manage the resources they own, which creates pressure to grant standing access as a workaround.
That pattern is an NHI governance problem as much as an access management one. When cloud permissions are created for convenience and left in place, the organization accumulates standing privilege that is difficult to justify, review, or revoke cleanly.
Key questions
Q: What breaks when OCI access is not granted just in time?
A: When OCI access is pre-provisioned and left standing, engineers can keep permissions long after the task that justified them. That creates privilege creep, weakens audit clarity, and increases the blast radius if an account is misused. The failure is not login, but authorization that outlives its business purpose.
Q: Why do standing cloud permissions increase risk in OCI environments?
A: Standing permissions turn a one-off operational need into always-on access, which means attackers or insiders inherit more capability than the task requires. In cloud environments, that broadens lateral movement potential and makes containment harder because the access does not naturally expire with the work.
Q: How do security teams know if just-in-time access is actually working?
A: Look for short-lived sessions, automatic revocation, and complete request-to-access logs. If approvals are still creating durable permissions, or if teardown depends on manual cleanup, then the programme is only partially ephemeral. Effective JIT should leave little or no reusable privilege behind after the task ends.
Q: Should teams use just-in-time access instead of permanent OCI roles?
A: Yes, when the role exists only to complete a bounded task. Permanent roles make sense only when the business function truly requires continuous authority. For most operational cloud work, just-in-time access gives a better balance of usability, auditability, and privilege control.
Technical breakdown
Why standing OCI access keeps reappearing
Standing access persists when teams treat authorization as a pre-provisioning exercise instead of a task-scoped decision. In OCI, the user can authenticate successfully through SSO, but the actual permissions to act are granted separately through roles and group membership. If the organisation pre-creates broad users, groups, and policies just to reduce friction, access becomes durable even when the task is temporary. The result is not a failure of login, but a failure of entitlement design. Least privilege is lost because the privilege model is optimized for speed instead of scope.
Practical implication: Replace permanent role assignments with task-scoped entitlement requests that expire automatically.
How time-bound role issuance changes the control model
Just-in-time provisioning shifts authority from a standing entitlement to a temporary authorization event. The user keeps the same authenticated OCI session, but the role appears only after approval and disappears when the duration ends. That means the access decision is tied to the work item, not to the user’s baseline identity. This is materially different from simply creating a user account and leaving it in place. The control value comes from constraining both time and scope, so the session reflects only the approved task window.
Practical implication: Treat approval, duration, and resource scope as mandatory parts of the access decision, not optional metadata.
Why automatic revocation matters for audit and containment
Automatic revocation closes the lifecycle gap that manual cleanup almost always leaves behind. When access ends by policy rather than by memory, the organization can show who requested access, who approved it, what it covered, and exactly when it ended. That improves auditability and also reduces containment risk if a session or account is later abused. In governance terms, the important change is that access no longer outlives the task. The credential state becomes observable, finite, and reviewable instead of a long tail of permissions nobody can confidently account for.
Practical implication: Make revocation automatic and auditable so expired access cannot linger after the work is complete.
NHI Mgmt Group analysis
Standing access is a governance failure, not an authentication failure. The article makes clear that users can sign in through SSO and still be forced into over-broad permissions because the operational path of least resistance is to make access permanent. That pattern creates privilege creep by design, not accident. The practitioner lesson is to treat convenience-driven permanence as a control defect in the entitlement model.
Ephemeral access is the right baseline for cloud roles that exist only to complete a task. OCI access that is granted for a defined duration and revoked automatically aligns authorization with work scope instead of employment or account ownership. That matters because the risk is not simply who can log in, but how long they can continue acting after the need has ended. Practitioners should measure cloud access by expiry and scope, not by whether an account exists.
Just-in-time provisioning exposes the weakness of coarse policy structures. If the only practical way to unblock engineers is to hand out permanent roles, then the policy model is too blunt for operational reality. The control gap is not the absence of a workflow, but the absence of a safe, fast, and narrow entitlement path. IAM and PAM programmes should treat that friction as a design signal, not a user problem.
Zero standing privilege in cloud sessions is becoming a baseline expectation. The strongest value in this pattern is not speed, it is that permissions remain tied to the request, the reason, and the expiry window. That gives security teams a cleaner audit story and a smaller blast radius when an account is misused. Practitioners should move cloud access reviews from static membership checks toward issuance-time governance.
Ephemeral authorization window: this is the control boundary that matters when access is granted only for the duration of a task. Once cloud teams accept that the useful access window is shorter than the account lifecycle, the governance model changes from permission ownership to permission expiry. The implication is that entitlement management has to follow task duration, not user tenure.
From our research library:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to Gartner.
- Read next: NHI Lifecycle Management Guide
What this signals
Zero standing privilege is the key design shift here: cloud teams should stop thinking about who has access in general and start governing when access exists at all. That moves entitlement review from static membership to issuance-time controls, which is where cloud risk is often decided.
The operational signal is simple. If a team still needs permanent users, groups, or policies to keep OCI work moving, then the access model is too coarse for secure use in production. That is where cloud IAM and PAM programmes need to converge, because short-lived privilege is easier to audit and harder to abuse.
For practitioners
- Enforce zero standing access for OCI work Require engineers to request scoped OCI permissions at the moment they need them, rather than pre-assigning permanent roles and groups.
- Tie approval to task duration and resource scope Capture a reason, a finite expiry, and the exact OCI resource set in every access request so the approval maps to the job being performed.
- Automate expiry and revocation Remove the granted OCI membership and associated permissions automatically when the time window ends, with manual revocation available for exceptions.
- Review emergency access patterns Identify where teams still create standing OCI roles to unblock work and replace those paths with approved just-in-time workflows.
Key takeaways
- Standing cloud access persists when convenience wins over entitlement discipline, and that is where privilege creep starts.
- Just-in-time OCI roles keep access tied to a task window, which improves containment and auditability at the same time.
- The strongest control is automatic expiry, because permissions that end on schedule do not depend on manual cleanup.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on removing standing OCI privilege and keeping access tightly scoped. |
| NHI-01 — Improper Offboarding | Automatic expiry and revocation address the lifecycle gap that leaves cloud access lingering. | |
| Recommendation — Enforce task-scoped OCI entitlements so permissions never remain broader than the approved need. Tie OCI access revocation to task expiry so temporary privilege does not survive the approval window. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The piece is explicitly about least-privilege authorization for cloud operations. |
| Recommendation — Apply least privilege to OCI role issuance and avoid permanent access paths for short tasks. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on how cloud permissions are granted, scoped, and withdrawn. |
| Recommendation — Govern OCI entitlements as a lifecycle process, with expiry and revocation built into authorization. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Standing privilege increases the impact of credential misuse and lateral movement in cloud. |
| Recommendation — Map over-privileged OCI access to credential-access and lateral-movement exposure during detection and review. | ||
Key terms
- Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
- Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
- Ephemeral authorization: A short-lived permission model that grants access only for the immediate task and expires quickly. It reduces the chance that an AI agent or service account can reuse an earlier decision after the task changes, which is a common source of NHI blast radius.
What's in the full article
P0 Security's full video covers the operational detail this post intentionally leaves for the source:
- The step-by-step OCI request flow, including approval handoff and session refresh behaviour
- The exact workflow for mapping an existing SSO identity into OCI without pre-provisioning users and groups
- The automatic revocation process that removes group membership and permissions when the access window ends
- The live user experience showing how engineers keep working without switching accounts or credentials
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
