Vault vs. vaultless PAM gets framed as a product category debate, but it's really a question about what you're trying to protect in the first place. A vault protects a secret. A vaultless, just-in-time model protects a moment of access. Those sound similar until something goes wrong, and then the difference is the whole story.
What a vault actually protects
The classic privileged access vault centralizes credentials — root passwords, service account secrets, database admin logins — rotates them on a schedule, and checks them out to a human or a process for a session. The thing it protects well is credential sprawl: nobody is supposed to know the production database password anymore, because nobody needs to, because the vault hands out a short-lived checkout instead. That's a real and durable win. Where it leaks is in everything the vault doesn't model. A vault knows who checked out a credential. It often does not know, with any precision, what they did with it once the session started, or whether the privilege they checked out was actually the minimum privilege the task required. Standing roles tend to survive inside a vaulted environment precisely because the vault is doing its job quietly in the background — the password is rotated, the audit log is tidy, and nobody notices that an engineer has had standing access to a payments database for eight months because a project needed it once.
What vaultless, just-in-time access actually protects
The vaultless model flips the unit of protection from the secret to the grant. Instead of storing a long-lived credential and checking it out, the system issues access for a bounded window, tied to a specific request, and revokes it automatically when the window closes. Picture a team where an on-call engineer needs production database access to diagnose an incident: in a vaultless model, they request access, get a time-boxed grant scoped to that database, work the incident, and the grant simply stops existing an hour later — no credential to rotate because there was no durable credential to begin with. That's a strong answer to standing privilege, which is arguably the more dangerous failure mode in practice, since it's the gap between who could act and who should be acting right now. Where vaultless models leak is at the edges of the request path itself: the approval workflow, the policy that decides what's grantable, and the identity system feeding it all. A just-in-time grant is only as trustworthy as the thing deciding to grant it — if that policy engine is misconfigured, or if the approval step is a rubber stamp, you've built an efficient machine for issuing privilege on demand rather than eliminating it.
The honest tradeoff is this: vaults are good at making secrets hard to steal, and comparatively weak at making privilege hard to accumulate. Vaultless models are good at keeping privilege from accumulating, and only as strong as the request-and-approval plumbing that decides who gets a grant and why. Neither model protects against a bad decision made through a legitimate channel — a vault will faithfully check out a credential to someone who shouldn't have requested it, and a vaultless system will just as faithfully issue a time-boxed grant to the same person. The protection is structural, not judgmental.
In practice a lot of environments end up running something closer to both, because the two approaches protect different layers. Service-to-service authentication and legacy systems that were never built to understand short-lived tokens tend to still need a vault, because there's a durable secret involved whether anyone likes it or not. Human access to sensitive systems is where the just-in-time model earns its keep, because the whole point is that no one should be sitting on standing privilege between incidents. PAFTAK's PAM practice supports both shapes — managed cloud deployments of Idira and on-premise implementations — because the right model is a question about the environment, not a preference.
The underlying point holds regardless of which model you pick: controlling access to software is the same discipline as building it, and the access-control problem doesn't change whether the thing touching your system is a person checking out a password or an automated process requesting a grant. A vault answers 'who has the secret.' A just-in-time model answers 'who is acting right now, and for how long.' Pick the one that answers the question you're actually worried about — or, more often, build the environment that can answer both.