Cloud teams should use JIT access as the operating model for temporary permissioning and zero standing privilege as the posture that prevents permanent access from reappearing. If standing privilege still exists, JIT becomes an exception layer rather than the default security boundary.
Why JIT Comes First and ZSP Comes After
Use JIT access to define how privilege is granted, and ZSP to define the steady state you are trying to reach. JIT should make elevation deliberate, time bound, and auditable. ZSP then removes the leftover default of permanent access so teams are not rebuilding standing privilege through exceptions, shared admin paths, or dormant high-trust roles.
The sequencing matters because cloud environments tend to accumulate convenience permissions. If you start with JIT without a ZSP posture, you can reduce how often access is used while still preserving a permanent privilege base. The right sequence is to treat JIT as the operating pattern and ZSP as the control objective that constrains what can remain assigned when no task is active.
Where cloud teams already rely on roles, groups, and break-glass paths, JIT should narrow active access to the minimum window needed for the task, while ZSP checks whether the underlying role design still leaves persistent rights behind. That is the key difference between temporary elevation and real privilege reduction.
What Changes in Cloud Control Design
Once ZSP is the target state, cloud teams have to redesign around eligibility rather than convenience. The practical question becomes which roles can be activated temporarily, which approvals are needed, which sessions must be observed, and which entitlements should be removed entirely because they are too broad to keep standing.
This is where access architecture starts to matter more than access process. A cloud team can have a strong JIT workflow and still fail if the same users, service principals, or admin groups retain broad baseline permissions. In that case, JIT only masks the problem. ZSP forces the baseline to be thin enough that activation is an exception, not a routine administrative habit.
Cloud teams should also separate human convenience from operational necessity. Roles that support deployment, support, or emergency response may need carefully bounded standing access, but the default for routine administration should still trend toward ephemeral activation. The design goal is not to eliminate all privilege, but to ensure persistent privilege is rare, justified, and reviewable.
How to Tell Whether the Sequence Is Working
The sequence is working when access reviews show fewer always-on roles, activation events are short and purpose specific, and admins do not need standing elevation to complete ordinary work. In a healthy model, the cloud platform can answer three questions cleanly: who had access, why it was activated, and when it expired.
It is not enough to measure how many JIT requests succeed. Teams also need to watch whether permanent permissions are still being added to solve friction. If the approval path is so burdensome that people bypass it, or if exceptions become the normal way to unblock work, then JIT is compensating for weak privilege design instead of enforcing it.
Good sequencing also shows up in entitlement hygiene. The fewer roles with persistent write access, the easier it is to keep activation meaningful. When persistent administrative permissions remain widespread, JIT can reduce exposure but cannot deliver the sharper boundary that ZSP is supposed to create. For cloud privilege architecture, Just-in-Time Access and Zero Standing Privilege Guide is the most direct practical reference for this progression.
Risk and Threat Considerations
Cloud privilege problems usually start when temporary access is layered on top of existing standing access instead of replacing it. That leaves too many paths into high-value systems, and it makes compromise easier to monetize because an attacker only needs one valid elevated path to move from limited access to control of cloud resources. The same pattern also increases blast radius when a role, token, or admin workflow is abused.
Failure mechanism: Permanent permissions remain in place, so JIT becomes an overlay rather than a boundary. Over time, teams accumulate exceptions, shared admin access, and roles that are only nominally temporary, which creates a privilege path that is still exploitable even when JIT is in use.
Impact: Excess privilege increases the chance of unauthorized changes, broader lateral movement, and faster takeover of cloud control planes, especially when administrative paths, secrets, or automation identities are already trusted by default.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | JIT and ZSP both implement least-privilege access reduction for cloud admin rights. |
| IA-5 — Authenticator Management | JIT depends on controlled credential and token lifecycle for temporary elevation paths. | |
| Recommendation — Enforce AC-6 to remove standing cloud privilege and activate elevation only when needed. Apply IA-5 to rotate and expire elevation credentials used for JIT access. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Continuous verification and least privilege | The question is about sequencing temporary access with a zero-standing-privilege posture. |
| Recommendation — Verify each access request continuously and keep privilege absent until explicitly needed. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Cloud teams need explicit management of standing and temporary access across cloud roles. |
| Recommendation — Use CIS-6 to remove standing admin access and govern just-in-time elevation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The subject is about cloud access policy and enforcing no-standing-privilege design. |
| Recommendation — Define and enforce access rules that prevent persistent cloud privilege from accumulating. | ||
Practitioner Guidance
What to prioritise: Start by identifying every role or group that still has active cloud privilege when no task is in progress. Remove the obvious standing admin paths first, then decide which ones genuinely need an activation workflow and which ones should be retired or split into narrower roles. A direct Privileged Access Management Guide helps frame the broader control model, while the Cloud PAM and CIEM Guide is useful when entitlement reduction and effective-permission cleanup are part of the sequence.
Decision rule: If a role is still needed every day, do not call it JIT-ready until you can explain why it must remain standing. If the answer is “because it is easier,” treat that as privilege debt, not an acceptable operating model. For emergency-only access, validate the break-glass path separately so it does not become the hidden default, and use the Break-Glass and Emergency Access Account Guide to keep that exception bounded.
Practitioner takeaway: JIT is the control you use to constrain time and context, but ZSP is the state that proves privilege is no longer assumed to exist between tasks. If standing access still exists, you have not finished the design.
Related resources from NHI Mgmt Group
- How do security teams decide whether JIT access or zero standing privilege is the better target?
- Who is accountable for standing privilege when teams adopt JIT access and Zero Standing Privileges?
- What is the difference between JIT access and Zero Standing Privilege?
- What is the difference between JIT access and zero standing privilege for NHI governance?