Ask ten people what privileged access management software does, and most will describe a vault: passwords rotated, sessions recorded, checkout logged. That's real, and it's necessary. It's also only half the category. The other half doesn't touch a single credential, and it's the half that decides whether the credential should exist in the first place.
The term "privileged access management software" gets used as if it names one thing. In practice it names two, solving two different problems that happen to share a name and, often, a budget line. Confusing them is how organizations end up with a beautifully secured vault full of access nobody remembers approving.
Type One: Credential Security
This is the PAM most people picture. The job is protecting the credential itself once it's clear that a given piece of privileged access should exist.
Vaulting. Privileged passwords, API keys, and secrets live in an encrypted store instead of a spreadsheet, a sticky note, or a shared Slack channel. Nobody holds the actual credential in plaintext.
Rotation. Passwords change automatically on a schedule, or after every use, so a credential that leaks has a short shelf life instead of a permanent one.
Just-in-time checkout. Instead of a standing password someone can use any time, a user requests access, gets a temporary credential for a session, and the credential reverts or expires when the session ends.
Session recording. What actually happened during a privileged session is logged and, often, replayable, so "we don't know what the admin account did" stops being an acceptable answer.
The identifying question for this type: if you removed this tool, would credentials be exposed in plaintext, unrotated, or unmonitored? If yes, that's Type One.
CyberArk, BeyondTrust, Delinea, and similar vendors are Type One. So is infrastructure-focused tooling like HashiCorp Vault and Teleport, which take the same problem further toward ephemeral, dynamically issued credentials that barely exist long enough to be stolen.
Type Two: Access Governance
This is the half most conversations about PAM software skip entirely, and it sits logically upstream of everything Type One does. A vault secures a credential. Governance decides whether that credential, or that role, or that entitlement, should exist at all, for this specific person, right now.
Identifying what's actually privileged. Not every "Admin"-named role deserves the label, and plenty of innocuously named roles carry serious privilege. Governance tracks privilege as an explicit, structured attribute on the permission or role itself, rather than guessing from a name.
Scoring the real risk. A privileged grant that allows deleting financial records is not the same risk as one that allows read-only access to the same data. Governance scores privilege per person, per grant, not as a flat label.
Gating the request. High-privilege requests route through stricter approval paths, sometimes multiple stacked approval levels, with the approver told explicitly that what they're reviewing is privileged.
Reviewing on a schedule, with teeth. Privileged accounts get flagged distinctly in access reviews and can require multi-level sign-off, not the same single rubber stamp routine access gets.
Catching combinations no single grant reveals. Two individually reasonable privileged grants held by the same person can add up to a conflict nobody would approve knowingly, someone who can both create and approve the same transaction, for instance. This is a governance problem, not a credential problem; a perfectly secured vault does nothing to catch it.
Covering the identities nobody's job includes reviewing. Service accounts and API integrations routinely hold standing high-privilege access that no human ever revisits. Governance tooling flags this population by design, whether or not a person is behind the account.
Zluri is the clearest example of Type Two: it deliberately does not vault credentials, rotate passwords, or record sessions, and says so directly. What it does is track privilege as data, score it, gate requests, run scheduled reviews with real scrutiny, catch dangerous combinations, and continuously reduce standing privilege across the estate, all without touching the credential layer at all.
Type One vs Type Two, Side by Side
Why the Distinction Actually Matters
Buying the wrong type for your problem wastes budget. If your acute issue is that admins share root passwords over Slack, the most sophisticated governance platform in the world doesn't fix that; you need a vault. If your acute issue is that nobody can say who holds privileged access or why, the deepest credential vault in the world doesn't fix that either; it just secures access that shouldn't exist in the first place.
A vault without governance is precise security around the wrong perimeter. It protects exactly the credential it's told to protect, beautifully, while access sprawl accumulates entirely outside its view. Type One tools generally aren't built to ask "should this person have this at all," only "is this credential secure once it exists."
Governance without a vault leaves the credential itself exposed. Knowing precisely who should hold privileged access, and having decided correctly that they should, doesn't help if that credential is sitting in plaintext somewhere.
Neither type is the lesser half. They answer different questions: "is this credential secure" and "should this access exist at all." A mature privileged access program needs an honest answer to both, which in practice means running tools from both types together rather than expecting one to cover for the other.
How to Tell Which Type You're Evaluating
Ask any vendor claiming to do "PAM" three direct questions. Do you vault and rotate credentials? Do you record privileged sessions? Do you decide whether a given privileged grant should exist, and keep checking? A Type One tool answers yes to the first two and treats the third as out of scope. A Type Two tool does the reverse. A genuinely rare tool answers yes to all three, and it's worth being skeptical of how deep that coverage actually goes on both sides before assuming a single platform solves the whole problem.
Frequently Asked Questions
Is one type of PAM software better than the other?
They're not competing for the same job, so "better" doesn't really apply. Type One secures the credential; Type Two decides whether the access behind that credential should exist. An organization with serious credential exposure needs Type One first. An organization with unreviewed access sprawl needs Type Two first. Most mature programs eventually need both.
Can a single tool do both types well?
In principle, but in practice most vendors specialize, because the two problems require genuinely different product depth: cryptographic credential handling and session infrastructure on one side, entitlement modeling and review workflows on the other. Evaluate the depth of each half separately rather than assuming breadth of claim equals depth of coverage.
Which type should a growing SaaS-heavy organization start with?
It depends on the acute failure mode. If credentials are shared insecurely or unrotated, start with Type One. If privileged access has sprawled across a SaaS estate with nobody able to say who holds what and why, start with governance, then add vaulting for the credentials governance confirms should exist.
Does Type Two governance replace the need for access reviews generally?
No, it strengthens them specifically for privileged access. Standard access reviews still cover the broader access estate; governance-type PAM adds the sharper scrutiny, distinct flagging, and multi-level sign-off that privileged access specifically warrants, layered on top of the review process rather than separate from it.
.svg)
