Use the account’s authentication pattern, dependency profile, and business criticality. Accounts that operate continuously may need ownership and rotation, while accounts that no longer need standing privilege are better candidates for JIT or deprovisioning.
How to choose between vaulting and JIT for discovered accounts
Discovered accounts are best treated as a policy decision, not a default technical pattern. If the account still supports a live dependency and must be available continuously, vaulting plus tight rotation is often the safer operating model. If the account exists only for occasional elevation or can be activated on demand, JIT usually reduces standing privilege and limits blast radius.
The right choice depends on how often the account must authenticate, whether downstream systems expect uninterrupted access, and whether the account can tolerate wait time or approval on activation. That is why the same discovery event can lead to very different outcomes: keep, vault, convert to JIT, or remove entirely. The decision should be driven by actual use, not by the account type alone.
In practice, teams should classify discovered accounts by function before deciding on custody. Some accounts are operational identities with legitimate continuous dependencies, while others are legacy, duplicate, or overprovisioned accounts whose only safe state is no standing privilege. The most important question is whether the account needs persistent authority to keep a service running, or whether it can be made ephemeral without breaking the business process.
What makes an account a vaulting candidate versus a JIT candidate?
Vaulting fits accounts that still need to exist, still need secret protection, and still need controlled rotation. Those accounts may be embedded in integrations, scheduled jobs, or systems that cannot yet tolerate activation delays. Vaulting helps centralise control of the credential, preserve ownership, and support rotation when the account remains part of normal operations. A strong internal reference on NHI lifecycle management is useful here because the decision is really about lifecycle state, not just storage.
JIT fits accounts where standing privilege is the problem, not the existence of the account itself. If an account only needs access during a change window, incident response event, maintenance action, or approval-based task, JIT can reduce exposure by making access time-bound and purpose-bound. That aligns with the logic in Just-in-Time Access and Zero Standing Privilege Guide, which treats dormant access as avoidable risk when continuous access is not required.
Some discovered accounts should not be vaulting or JIT candidates at all. If ownership cannot be established, the account has no current business dependency, or the access path is obsolete, deprovisioning is usually the better answer. A good decision process starts by asking whether the account is needed, then whether it needs persistent access, and only then whether the credential should be vaulted or activated just in time.
How should teams operationalise the decision?
Use a simple sequence: confirm ownership, map dependencies, test whether the account can function without standing privilege, and then choose the lightest control that preserves service continuity. If the account supports a continuously running workload, application, or integration, vaulting and rotation are often the interim control while engineers redesign the dependency. If the account is only needed for occasional administrative action, move it to JIT and remove any permanent entitlement that is not strictly required.
Discovery should also trigger a review of secret age, rotation feasibility, and reuse. Long-lived or shared credentials are strong signals that vaulting alone is not enough unless the team can rotate reliably. That is why Guide to NHI Rotation Challenges matters: it highlights that rotation becomes harder as dependencies multiply, so the vaulting decision should include whether the team can actually sustain credential hygiene over time.
If the account is discovered in a cloud vault or secret store, review whether the secret is protecting a real production dependency or simply preserving legacy access. The Azure Key Vault Contributor escalation 2024 example is a reminder that overbroad vault access can turn storage into privilege amplification, so the control choice must include who can read, update, or delegate the secret. A vault is only useful when access to the vault is tighter than the access the secret confers.
Risk and Threat Considerations
Discovered accounts are risky because they often reveal either stale access or hidden dependencies. If a team vaults everything by default, dormant accounts can keep wide-reaching permissions alive for months. If a team pushes everything to JIT without understanding downstream dependencies, it can break production workflows or create shadow exceptions that reintroduce standing privilege elsewhere.
Failure mechanism: The main failure modes are excessive standing privilege, weak ownership, long-lived secrets, and overbroad vault access. Attackers and insiders both benefit when a discovered account can still authenticate, still reach sensitive systems, and still be missed by routine review. The risk is highest when the account is shared, reused across environments, or protected only by a vault that is itself broadly readable.
Impact: Poor decisions here can lead to account takeover, lateral movement, unintended persistence, and delayed revocation. At scale, a single mistaken vaulting decision can preserve access paths that should have been removed, while a poorly designed JIT path can create emergency exceptions that nobody later retires.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Discovered accounts often hinge on credential lifecycle, rotation, and revocation. |
| IA-9 — Service Identification and Authentication | Vaulted or JIT accounts commonly authenticate services, workloads, or integrations. | |
| AC-6 — Least Privilege | The vaulting versus JIT decision is fundamentally about reducing standing access and excess privilege. | |
| Recommendation — Enforce credential rotation, expiration, and revocation for discovered accounts with ongoing access. Bind non-human accounts to strong service authentication and narrow their permitted use. Remove standing access and grant only the minimum privileges required for the task or dependency. | ||
| CIS Controls v8 | CIS-5 — Account Management | Discovered accounts require inventory, ownership, and lifecycle control before custody decisions. |
| Recommendation — Inventory, assign owners, and retire or tighten discovered accounts based on current business need. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Vaulting is often used when an account still needs a secret, but long-lived secrets raise exposure. |
| Recommendation — Shorten secret lifespan and replace long-lived credentials with ephemeral access where possible. | ||
Practitioner Guidance
What to prioritise: Start with whether the account is still needed and who owns it. If ownership is unclear, treat the account as a revocation candidate first, not a vaulting candidate. If the account is necessary, decide whether the dependency truly requires continuous access or whether activation can be time-bound without operational harm.
Decision rule: If the account must remain continuously available to a production dependency, vault it and enforce rotation, review, and access restriction around the vault itself. If the account does not need standing privilege, move it to JIT or eliminate it entirely. Do not use vaulting to preserve convenience when the business process can tolerate ephemeral access.
What good looks like: The account has a named owner, a documented dependency, a measurable rotation path, and no more access than the workload or operator actually needs. The control choice is explicit, reviewed, and reversible, instead of being inherited from historical setup.
Practitioner takeaway: Vaulting protects accounts that still need to exist; JIT is the cleaner answer when the account only needs temporary authority. The key judgement is whether the dependency is continuous or merely occasional, because that determines whether you are preserving a legitimate operating account or leaving unnecessary standing privilege in place.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams decide whether a discovered privileged account needs vaulting or a different control?
- How should security teams decide between personal and managed Apple Accounts on company-owned devices?
- How should security teams decide between vault-based PAM and vaultless JIT access?