Should organisations prioritise just-in-time access or standing permission cleanup first?

Why standing permission cleanup changes the answer

Standing permission cleanup is the first leverage point because it removes access that exists all the time, regardless of whether anyone is actively using it. If a role, token, or account is already too broad, JIT only delays misuse, it does not shrink the pre-existing attack surface. That is why cleanup usually delivers the biggest immediate reduction in exposure.

JIT is most effective after entitlement hygiene is underway. It works best when the access path is already bounded by ownership, purpose, and time, so the temporary elevation is the exception rather than the safety net for a messy baseline.

For teams formalising that sequence, the Privileged Access Management Guide and the Just-in-Time Access and Zero Standing Privilege Guide both reinforce the same practical order: reduce persistent privilege first, then use JIT to keep needed elevation narrow and accountable.

Cleanup also matters more when the environment contains unused, unowned, or duplicated non-human identities, because those accounts often keep working long after the business need has faded. A standing entitlement that nobody reviews is already a governance failure; adding JIT on top does not fix that failure mode.

Where JIT helps, and where it does not

JIT is a control for duration and activation, not a substitute for entitlement inventory. It reduces the time window of exposure, but it cannot correct excessive permissions, orphaned service accounts, stale admin roles, or secrets that were never supposed to remain valid in the first place.

That distinction is important in cloud and machine-access environments, where standing privilege often hides inside broad roles, long-lived secrets, and over-permissive service identities. The more accumulated access you have, the less meaningful a temporary elevation mechanism becomes, because the real problem is who can already do what.

NHIMG’s Cloud PAM and CIEM Guide and Service Account Security Guide are useful here because they separate effective permissions from granted permissions and show why discovery, right-sizing, and governance have to precede or accompany JIT.

The same logic applies to secrets and tokens. If a credential is long-lived, shared, or unnecessary, making its use time-bound is helpful but still leaves an avoidable standing blast radius until the underlying entitlement is removed or rotated.

When you want a control path that has already been shown to fail at scale, Guide to NHI Rotation Challenges and Ultimate Guide to NHIs, Static vs Dynamic Secrets both point to the same practical issue: lifecycle control is part of access cleanup, not a later optimisation.

What a sensible order looks like in practice

Start with the access that creates the largest uncontrolled blast radius: privileged roles, shared accounts, unused accounts, stale service identities, and permissions that no owner can justify. Then use JIT to constrain the remaining legitimate elevation paths so they are time-bound, reviewable, and tied to a real business action.

Failure mode: Teams often deploy JIT as a visible improvement while leaving dormant privilege untouched. That creates a false sense of control, because the environment still contains access that can be abused without any elevation workflow being triggered.

Decision rule: If a permission is not needed for continuous operation, remove or narrow it first; if it is needed, make it eligible for JIT with explicit ownership and expiry. If you cannot name the owner, purpose, and review cadence, it is a standing access problem, not a JIT problem.

The strongest practical signal is whether you can inventory and explain every persistent privilege path. If you cannot, the cleanup work is still the bottleneck. If you can, JIT becomes the right next control because it prevents privilege from remaining active longer than necessary.

Practitioner takeaway: treat JIT as the control that polishes a controlled access model, not the mechanism that creates one. The fastest risk reduction usually comes from deleting or right-sizing standing privilege before you try to time-box what is left.

Risk and Threat Considerations

Standing privilege concentrates risk because it creates always-on access paths that attackers, insiders, and compromised automation can exploit without waiting for an approval workflow. JIT lowers dwell time, but it does not help if the environment already contains stale entitlements, shared credentials, or unowned identities that remain usable indefinitely.

Failure mechanism: Excessive or orphaned access survives until it is explicitly discovered and removed, which means compromise, misuse, or accidental impact can occur through an access path that was never meant to stay active.

Impact: The practical result is larger blast radius, weaker accountability, and more ways for a single credential, role, or account to reach sensitive systems before any temporary-access control can intervene.

Practitioner Guidance

What to prioritise: remove or right-size persistent access first when you find unused admin roles, stale service accounts, shared credentials, or permissions with no clear owner. JIT is then used to constrain the remaining legitimate exceptions, not to mask a poor baseline.

What to verify: confirm that every standing entitlement has an owner, a purpose, and a review cadence, and that every temporary elevation path expires automatically. If either of those cannot be shown, the control is incomplete.

Practitioner takeaway: the best sequencing is usually cleanup, then JIT, then continuous review. That order reduces the maximum amount of exposed privilege before you optimise the time window on what still has to exist.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• Should organisations prioritise external exposure or internal credential governance first?
• What should organisations prioritise first: AI automation or access cleanup?
• Should organisations prioritise data classification or permission cleanup first?