Lesson 12 of 35PAMPAM

What is PAM?Privileged Access Management explained

Locks down the small number of accounts that can do serious damage — admin logins, database credentials, service accounts — behind checkout, time-limits, and recording, instead of leaving powerful passwords sitting around unmonitored.

By Cyber Tool Stack Editorial TeamReviewed August 4, 2026

Verified August 4, 2026Sources: paloaltonetworks.com, paloaltonetworks.com, idsalliance.org

The lesson

Guarding the accounts that could burn it all down

A handful of logins — domain admins, database roots, service accounts — can undo every other defense a company owns. This lesson shows how those master keys get locked up, time-limited, and watched.

If it helps, think of it as… the signed-out master key

In a well-run building, the master key never lives in anyone's pocket. It sits in a locked cabinet at the front desk. A technician signs it out for a named job, keeps it for one hour under the lobby camera, and hands it back — and the building quietly changes the lock afterward, just in case a copy was made.

Admin requests access

named task, approval, fixed time window

Vault checks out credential

injected into the session, never revealed

Time-boxed session

recorded and watched as it happens

Access expires

credential rotated behind the admin

Session cut short

suspicious activity ends it early

Privileged access is requested, checked out from a vault, and used inside a recorded, time-boxed session before it is automatically revoked.

What it does

Privileged Access Management (PAM) locks down the small set of accounts that can do serious damage: domain administrators, database roots, cloud consoles, and the service accounts machines use to talk to each other. Instead of leaving those passwords in someone's head, a shared spreadsheet, or a script, PAM stores them in an encrypted vault, rotates them automatically, grants access only for a limited time and a stated reason, and records what happens during every privileged session.

An ordinary account can read its own email. A privileged account can read everyone's — or delete the backups. That asymmetry is why these accounts get a tool of their own.

The attack it stops

Nearly every major intrusion follows the same arc. An attacker lands on one ordinary laptop, often through phishing. What they hold is a low-value foothold — so they go hunting for privilege: cached admin passwords, credentials pasted into scripts, a password file on a shared drive. Each found credential lets them move laterally to more systems, until one yields full administrative control. With that, they can disable defenses, reach everything, and deploy ransomware everywhere at once.

PAM starves that hunt. Vaulted credentials aren't cached on laptops or written into scripts, so there is little to find. Passwords rotate after each use, so a stolen one goes stale almost immediately. Elevation requires a request, an approval, and a time window — a strange 3 a.m. checkout is a loud alarm. And session recordings mean that even successful misuse leaves a replayable trail.

How it works, step by step

Discover: the system inventories privileged accounts, human and machine. Most organizations find far more than they expected — especially service accounts nobody remembers creating.
Vault: passwords and keys move into an encrypted vault and start rotating automatically. Admins stop knowing them at all.
Request: an admin asks for access to a specific system, for a specific task, for a set window — an approach called just-in-time access. Policy or a human approves it.
Broker: the vault opens the session and injects the credential directly, so the user never sees or copies it.
Watch: the session is recorded — commands, screens — and unusual activity can end it while it is still running.
Expire: the window closes, access disappears, and the credential is rotated behind the departing admin.

What it doesn't do

PAM only guards accounts it knows about. Unmanaged service accounts, forgotten cloud keys, and credentials created outside the process are side doors around the vault, which makes discovery a continuing job rather than a one-time setup. It also doesn't govern ordinary users' permissions, and an approved admin can still do harm inside an approved session — recording documents that, but doesn't always prevent it.

The beginner misconception: "we only have three admins, so this is overkill." Count the machine identities — service accounts, build pipelines, automation keys — and the privileged population is usually in the hundreds, each one a set of keys to something important.

How it fits the stack

PAM sits on top of the everyday login layer of identity and single sign-on, adding heavier controls for heavier accounts. Deciding who should hold privilege at all is the job of identity governance, and session recordings become prime evidence for incident response. The application secrets it vaults overlap with encryption and key management.

Terms you just met

Each links to its plain-language definition in the glossary.

The field guide

Evaluating this category

A second pass for buyers: market context, distinctions that matter, and what to weigh when tools in this category start looking alike.

Most employee accounts, if stolen, let an attacker do limited damage — read one person's email, maybe access a few files. A small number of accounts are different: admin logins that can reconfigure a whole server fleet, database credentials that can read or delete every customer record, service accounts that let one system talk to another with broad access. Those accounts turn a minor breach into a catastrophic one, and need to be locked down far more tightly than an ordinary login.

The tool built for this locks those credentials in an encrypted vault, hands them out only when needed and only for a limited time, and records exactly what was done with them — instead of leaving powerful passwords in a spreadsheet or memorized by whoever needs them.

The problem it solves

Administrator and service-account credentials are often shared among several people, rarely rotated, and sometimes written down somewhere convenient — because rotating a password that a dozen scripts and people depend on is genuinely painful without the right tooling. That convenience is exactly what makes these accounts dangerous: if one leaks, there's no way to tell who used it, and revoking access means changing it everywhere it's hardcoded, which teams understandably avoid doing often.

The result: the most damaging accounts in the environment are frequently also the least monitored and least frequently changed — precisely backward from what a sound security posture should look like.

How it works

Privileged credentials — admin passwords, database logins, API keys, certificates — are stored in an encrypted vault instead of a document, script, or someone's memory. When someone needs one, they check it out through the vaulting system rather than knowing the password directly; the system grants access for a limited window and automatically rotates the credential afterward, so a checkout doesn't stay valid indefinitely.

Sessions using these credentials — an admin connecting to a production server, say — can be recorded or watched live, giving a clear audit trail of what happened during the session. Rather than granting standing, always-on admin rights, the system can grant temporary elevation for a specific task, expiring once the window closes. The same vaulting and rotation extends to non-human accounts too — service accounts and application credentials that connect one system to another — which are otherwise easy to forget about entirely.

PAM vs everyday IAM

Ordinary identity and access management handles login and access lifecycle for the whole workforce — everyone's day-to-day access to everyday apps. Privileged access management is a narrower, deeper layer focused on the small set of accounts that can cause outsized damage: vaulting, session recording, and time-limited elevation that would be overkill for an email login but essential for anyone touching production infrastructure or sensitive databases directly.

The two systems typically work together rather than compete: identity handles who the person is and enforces everyday login, while the privileged layer takes over at the moment someone needs to act with elevated rights.

Choosing one

Start by mapping how many truly privileged accounts and credentials exist — admin logins, database credentials, service accounts, API keys — since that inventory alone is often a wake-up call and shapes which capabilities matter most. A team of mostly human administrators cares most about session recording and just-in-time elevation; a team managing automated infrastructure cares more about secrets and service-account rotation at scale.

Deployment friction matters too: a vaulting system painful to check credentials out of gets quietly bypassed by frustrated admins going back to old habits, so ease of everyday use matters as much as the security model itself.

Capability taxonomy

What buyers typically evaluate when comparing tools in this category.

Privileged credential vaulting: Stores and rotates admin passwords and keys in an encrypted vault.
Session recording & monitoring: Records and can live-monitor privileged sessions for audit and investigation.
Just-in-time access: Grants elevated access for a limited time window instead of standing privilege.
Least-privilege elevation: Allows temporary privilege elevation for a specific task rather than full admin rights.
Secrets management: Manages API keys, certificates, and application secrets alongside human credentials.
Service account management: Discovers and rotates credentials for non-human, machine-to-machine accounts.