Lakshya

Identity & Access · Chapter 5

Privileged access — why admin is different

The single highest-value control surface in an enterprise, and what PAM products actually sell.

A privileged account is one that can change the system rather than merely use it — domain admin, root, cloud account owner, database superuser, the CI/CD service account that can deploy anything. These deserve a separate regime, because compromising one converts an intrusion into a total loss.

THE SAME ADMIN, TWO MODELS — EXPOSURE WINDOW SHOWN TO SCALE STANDING ACCESS — a permanent admin account usable by anyone who obtains it — every hour of every day shared password in a vault · rotated quarterly · used by four people · logged as one identity JUST-IN-TIME — request, approve, expire 45 minutes, tied to a change ticket, one named human no standing credential exists · every elevation is a request with a reason · expiry is automatic This is what CyberArk, HashiCorp Vault and cloud-native PAM are all fundamentally selling. Not a better password store — the removal of the standing credential altogether.
The exposure window is the whole argument. A standing admin credential is available to an attacker every hour of every day. A just-in-time credential exists for the length of an approved task. Same person, same job, radically different risk — and the second one is also better evidence, because every elevation carries a reason.

What PAM tooling actually does

  • Vaulting — credentials stored centrally, never known by the human. The oldest capability and the least interesting.
  • Rotation — automatic change after use, so a captured secret has a short life.
  • Brokered sessions — the admin connects through the PAM system, which injects the credential and records the session. The human never handles the secret.
  • Just-in-time elevation — the important one. No standing privilege at all; access is requested, approved, granted for a window, and expires automatically.
  • Session recording — keystroke or video capture of privileged sessions, which is as much a deterrent and an evidence source as a preventive control.

CyberArk and HashiCorp Vault are not the same product

Centre of gravityTypical buyerPrimary use
CyberArkHuman privileged accessSecurity / IAM teamAdmins reaching servers, network kit, databases; session recording; compliance evidence
HashiCorp VaultMachine and application secretsPlatform / engineering teamApplications fetching database credentials and API keys; dynamic short-lived secrets; encryption as a service

They overlap and both vendors have grown into the other's territory, but the distinction holds in practice and is worth stating precisely in an interview. CyberArk's classic problem is the human administrator; Vault's classic problem is the application that needs a database password at runtime. Vault's most distinctive capability is dynamic secrets — it creates a credential on demand with a short lease, so the credential your application uses did not exist an hour ago and will not exist in an hour.

Where PAM programmes actually fail

Not in the technology. They fail because the vault is deployed, the admins keep their standing accounts “for emergencies”, and eighteen months later half of privileged activity still bypasses the system entirely.

So the metric that matters is not “is PAM deployed?” but “what percentage of privileged sessions went through it last month, and what is the trend?” Ask for that number. Very often nobody has computed it, and that is itself the finding.

← Entitlements, RBAC and ABACSecrets management →