The blast radius problem

Not all access is equal. A read-only login to a dashboard is a minor risk if it leaks; the production database admin credential, the cloud root account, the CI/CD deploy key — those are the access that turns a small compromise into a company-ending one. Privileged access is defined by blast radius: how much damage the holder can do if they go rogue or get phished. And for most lean teams, the honest answer is that far too many people hold far too much of it, far too permanently.

The pattern is familiar. Early on, everyone needs to do everything, so everyone gets admin. The team grows, but the access never gets clawed back, because removing it feels like distrust and nobody wants to be the bottleneck. A year in, every engineer is a permanent root on production, prod credentials are a shared password in a chat thread, and the cloud root account is logged in on someone's laptop. None of it is malicious. All of it is the exact condition that turns one phished laptop into a total compromise. This is least privilege at its highest-stakes layer — the access where getting it wrong costs the most.

Standing access is the root of the problem

The core insight of privileged access management is that standing access — permanent, always-on admin — is the thing to attack. An attacker can only use the privileges that are live when they land. If admin rights sit dormant until someone explicitly elevates for a specific task, then a phished developer account is just a developer account, not an instant root.

  • Inventory who holds what, and over what. You cannot shrink privilege you can't see. Start from a list of every admin-capable account — human and machine — against every critical system, the same way your asset inventory tracks the systems themselves. The non-human identities usually outnumber the people and hold the scariest keys.
  • Separate everyday accounts from privileged ones. An engineer's daily-driver login — full of browser tabs and email — should not also be production root. A separate, hardened admin identity means the account that gets phished isn't the account that can wreck prod.
  • Make elevation explicit and temporary. Just-in-time access — request, get it for an hour, lose it automatically — collapses the standing-privilege window to near zero. Even a lightweight version (a documented request and a manual grant-then-revoke) beats permanent admin, because the default state of the account is not dangerous.

The controls a lean team can actually run

You don't need an enterprise PAM platform to get most of the benefit. You need discipline applied to a short list:

  • Phishing-resistant MFA on every privileged account, no exceptions. Privileged access is where weak MFA hurts most — these are the accounts worth a targeted attack, so they get the strongest identity hardening you have, not the baseline.
  • Kill shared privileged credentials. A shared prod password means no accountability and no clean revocation — you can't remove one person without rotating it for everyone. Individual named access, or short-lived credentials issued per person, restores the audit trail. Where a shared secret is unavoidable, it lives in a vault, never a chat thread, under your secrets-management discipline.
  • Define a break-glass path — and alarm it. There are real emergencies where someone needs root now. The answer isn't standing access; it's a documented break-glass account that's heavily monitored, so using it fires a loud alert and creates a record. Break-glass should be rare and noisy, never routine and silent.
  • Log and alert on privileged actions. Every use of admin rights belongs in your detection pipeline. Privileged actions are exactly what an attacker performs after a compromise, so they're the highest-value signal you can watch — and the first thing an incident responder reaches for.
  • Review privileged access on a cadence, ruthlessly. Standing admin accumulates by default. A recurring access review aimed specifically at the privileged tier — and immediate revocation at offboarding — keeps the list from quietly growing back.

Over-privilege is a finding, not a footnote

When a review surfaces a developer with standing prod root they haven't used in months, or a service account with admin scope it doesn't need, that's a finding with an owner and a clock — ranked by blast radius. Standing root on production outranks a stale admin login to a low-value tool, and gets the shorter deadline. This is the same exposure-first triage you run everywhere, pointed at the access that can do the most harm.

It anchors the audit, too

Access control is the first thing nearly every framework examines, and privileged access is where assessors look hardest — who can touch production, how elevation works, whether shared admin credentials exist, how access is removed when people leave. A clean inventory, named privileged accounts, time-boxed elevation, an alarmed break-glass path, and a record of regular reviews are exactly the evidence those questions want, dropping straight into continuous evidence collection.

One honest caveat: a platform can inventory privileged accounts, flag standing or unused admin access and shared credentials as findings, track the remediation, and keep access-review evidence current for an assessor — it organizes and proves the work. It does not provision your accounts, enforce just-in-time elevation, rotate your credentials, or grant or guarantee any certification; the separation of duties, the break-glass design, and the revocations are operational steps your team owns, and which obligations apply to you is a question for counsel.

Privileged access is the difference between an incident and a catastrophe — it's defined by blast radius, and most lean teams hand out far too much of it far too permanently. The fix isn't an enterprise PAM suite; it's attacking standing access: separate admin identities from daily logins, make elevation explicit and temporary, kill shared prod passwords, alarm the break-glass path, log every privileged action, and review the privileged tier ruthlessly. An attacker can only use the keys that are live when they land — so make the dangerous ones off by default.