No, the two controls should be implemented together. JIT reduces the time a credential can be used, while rotation limits the value of any credential that is exposed. If one is present without the other, attackers still have too much room to act. The stronger programme combines both.
Why This Matters for Security Teams
JIT access and secrets rotation solve different parts of the same exposure problem, so treating them as competing priorities creates a gap attackers can exploit. JIT narrows the time window for use, while rotation reduces the value of a credential that has already leaked. In practice, exposed tokens still travel through tickets, chat, and code paths, which is why NHIMG research found that 44% of NHI tokens are exposed in the wild, including Teams, Jira, Confluence, and code commits, in The 2025 State of NHIs and Secrets in Cybersecurity.
That exposure pattern is not solved by a single control. The OWASP Non-Human Identity Top 10 treats lifecycle weakness, secret leakage, and over-privilege as connected failure modes, not isolated issues. A token that is short-lived but never rotated still has too much utility if it is copied into logs or scripts. A rotated secret that is long-lived in practice still leaves a broad blast radius if access is not time-boxed. Current guidance suggests building both controls into the same operating model, especially where PAM, RBAC, and approval workflows are already stretched by machine-to-machine traffic. In practice, many security teams encounter this failure only after a leaked credential has already been reused across multiple systems.
How It Works in Practice
The practical answer is to tie JIT and rotation into one credential lifecycle. JIT should issue the minimum access needed for a task, for the shortest viable duration, and revoke it automatically when the task ends. Rotation should then ensure that any credential still in circulation is replaced on a schedule that reflects its exposure risk, not just its age. For NHIs, that usually means short TTLs for ephemeral secrets, strong workload identity, and automated renewal paths rather than shared static credentials.
This is where organisations often benefit from pairing identity governance with secrets management. The Guide to the Secret Sprawl Challenge is useful here because sprawl usually creates the conditions where both JIT and rotation fail. NHIMG research also shows that 62% of all secrets are duplicated and stored in multiple locations, which makes rotation slower and less reliable in the real world, as documented in The 2025 State of NHIs and Secrets in Cybersecurity.
- Use JIT for access issuance, not as a substitute for secret hygiene.
- Rotate secrets on exposure triggers, not only on fixed calendar intervals.
- Prefer dynamic secrets or workload-bound tokens over long-lived static credentials.
- Revoke and replace secrets automatically when offboarding, pipeline changes, or anomalous use occurs.
For implementation patterns, the Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference, alongside the OWASP Non-Human Identity Top 10. These controls tend to break down when shared service accounts are embedded in legacy pipelines because one account can be impossible to revoke without interrupting multiple workloads.
Common Variations and Edge Cases
Tighter access control often increases operational overhead, requiring organisations to balance reduced exposure against automation cost and pipeline complexity. That tradeoff is most visible in CI/CD, service meshes, and integration-heavy environments where secrets are created and consumed at high speed. Best practice is evolving, but there is no universal standard for whether JIT should precede rotation or vice versa in every environment; the safer answer is to implement both as complementary controls and let risk decide the rollout order.
Some teams start with rotation because they already have known leakage, while others begin with JIT because standing access is the more urgent problem. Either path is acceptable if the end state is the same: no long-lived standing access and no secrets with indefinite usefulness. The Guide to NHI Rotation Challenges is especially relevant where application changes, certificate dependencies, or vendor integrations make rotation brittle. In those settings, rotation can fail if an app expects a secret to remain valid across release windows, while JIT can fail if approvals are too slow for machine workflows.
External guidance also supports this layered view. The OWASP Non-Human Identity Top 10 emphasises lifecycle control, and current NHI governance practice aligns with that by treating access duration and credential freshness as separate but linked safeguards. In mature programmes, the question is not which control comes first, but how quickly both can be enforced across every workload class.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and lifecycle weakness are central to this JIT vs rotation decision. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access timing supports JIT issuance and revocation. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires continuous verification, which supports both JIT and rotation. |
Automate secret rotation and shorten credential lifetime wherever NHI-03 exposure risk is present.
