Privileged access is the access that can change the system itself, not just use it. Admin consoles, root shells, service accounts, cloud owner roles, and the secrets that unlock them are the accounts an attacker wants most, because one of them is usually enough to reach everything else. Privileged access management, or PAM, is the practice of removing standing power from those accounts and handing it out in small, recorded, time-boxed pieces.
PAM is a discipline for controlling, securing, and monitoring accounts that hold elevated rights. A normal identity reads a record or files a ticket. A privileged identity can create other accounts, disable logging, read every mailbox, rotate encryption keys, or delete a production database. That gap in blast radius is the whole reason PAM exists as its own control set, separate from ordinary access. It sits next to entitlement management, which governs the everyday permissions a normal identity carries, and identity lifecycle management, which governs how identities are created and retired. PAM is the layer for the small number of paths that can change or destroy the environment.
Attackers concentrate here because of leverage. Standing privileged access means a credential exists, all day every day, that is worth stealing. Least privilege is the countermeasure, and NIST SP 800-53 states it directly. AC-6(5) restricts privileged accounts to a defined, small set of roles, and AC-6(2) requires that people with admin rights use non-privileged accounts for ordinary work. SOC 2 frames the same idea in CC6.1, which expects logical access to be restricted to protect assets. The posture PAM aims for is simple to say and hard to reach. No human or machine holds a privileged credential it is not using right now.
The first move in PAM is to stop shared privileged passwords from standing still. Vaulting means the credential lives in a secured store, not in a person's head, a wiki, or a config file. Access to the vault is brokered, so a request to use root is authenticated, authorized, and logged before the secret is ever revealed, and often the secret is injected into the session so the user never sees it. Rotation means the credential changes on a schedule and after every checkout, so a password captured today is useless tomorrow. For service accounts and keys, the same logic runs through secrets management: store the secret centrally, hand it to the workload at runtime, rotate it automatically, and never let it sit in plaintext in a repository or an environment file. NIST covers credential handling under IA-5, authenticator management, and account handling under AC-2.
Vaulting a standing password beats a sticky note, but the credential still exists all the time. Just-in-time access, or JIT, goes further. Privilege is granted only when it is requested, only for the task at hand, and only for a set window, then it is removed automatically. Zero standing privilege, or ZSP, is the end state that JIT moves toward. Between tasks the account has no elevated rights at all, so there is no standing credential to steal and no idle admin session to hijack. In practice this looks like an engineer requesting one hour of database-admin access, an approver granting it, the rights activating, and the rights expiring on their own.
The exposure window shrinks from always to minutes. Least privilege applied to time, not just scope: no account holds power it is not using right now.
Review who holds standing accessGranting privilege narrowly is half the job. The other half is being able to show what was done with it. Privileged session monitoring records the actions taken during an elevated session: commands run, systems touched, and in higher-assurance setups a full keystroke or screen recording. This does two things. It deters misuse, because people behave differently when the session is on the record, and it produces evidence you can hand to an incident responder or a reviewer without reconstructing events from scattered logs. NIST maps to this directly. AC-6(9) calls for logging the use of privileged functions, AU-2 defines which events are logged, and AU-12 requires the system to generate those audit records. The word to hold onto is evidence. Access controls set intent, recorded sessions prove what actually happened, and that gap is where most audits and most breach investigations either succeed or stall.
The count of identities, human and machine, holding always-on elevated rights.
The share of privileged access granted through request-and-expire instead of standing rights.
How long shared secrets and service-account passwords go between rotations. Old credentials compound exposure.
The share of privileged sessions that are recorded and reviewable. Also watch orphaned service accounts with no owner or recent use.
| Standing privileged access | Just-in-time PAM | |
|---|---|---|
| Access model | Rights are always on, assigned once and left in place | Rights are granted per request, for one task, then removed |
| Credential | A long-lived shared or admin password that rarely changes | Vaulted and rotated, often injected so the user never sees it |
| Exposure window | Continuous. The account is a target 24/7 | Minutes to hours, bounded by the grant, then zero |
| Auditability | Shared logins blur who did what. Attribution is weak | Each elevation ties to a person, a reason, and a session record |
| Failure mode | One stolen credential grants durable, unnoticed access | A missed approval or expiry blocks work, it does not hand over the keys |
Find the standing privileged access hiding in your estate.
Run an access review