What is Privileged Access Management?

Definition

Privileged Access Management (PAM) is the cybersecurity discipline focused on controlling, monitoring, securing, and auditing accounts, credentials, and sessions that hold elevated privileges in IT systems.

Privileged accounts include:

• Domain Admins and Enterprise Admins
• Local administrators on workstations and servers
• Root accounts on Linux/Unix
• Cloud root and Global Administrators
• Database administrators (DBAs)
• Hypervisor and infrastructure admins
• Service accounts with high privileges
• Break-glass / emergency accounts
• Application administrators

Gartner defines PAM as the tools and practices used to "monitor and manage all activities related to privileged accounts."

NIST SP 800-53 (AC-6, IA-2) requires organizations to enforce least privilege and additional protections for privileged accounts.

---

Why PAM Matters

Privileged accounts are the most valuable target for attackers. A single compromised Domain Admin or cloud root account can:

• Encrypt every server in a ransomware attack.
• Exfiltrate every customer record.
• Disable security controls.
• Persist across detection cycles.
• Move freely across environments.

Real-world incidents — NotPetya, SolarWinds, Colonial Pipeline, MGM, Microsoft Midnight Blizzard — repeatedly highlight the catastrophic impact of compromised privileged access.

PAM directly mitigates this risk by enforcing:

• Strong vaulting and rotation
• Just-in-time elevation
• Session recording and monitoring
• Approval workflows
• Strict auditing

---

Core Capabilities of PAM

A modern PAM platform typically provides:

1. Credential Vaulting

Privileged credentials are stored in an encrypted vault, not in scripts, wikis, or password managers.

2. Credential Rotation

Passwords, SSH keys, and API tokens are rotated automatically — often after every use.

3. Just-in-Time (JIT) Access

Privileges are granted only when needed, for a limited time, then automatically revoked. Eliminates standing privilege.

4. Session Brokering

Users connect to target systems through the PAM platform, never directly. The PAM tool injects credentials so users don't see them.

5. Session Recording and Monitoring

Privileged sessions are recorded (video and/or keystroke) and replayable for audit and forensics.

6. Approval Workflows

Sensitive elevations require approval — sometimes multi-party.

7. Discovery

Continuously discovers privileged accounts across the environment so they don't go unmanaged.

8. Reporting and Audit

Generates evidence for SOX, PCI DSS, HIPAA, ISO 27001, SOC 2.

9. Secrets Management

Manages application secrets — API keys, database credentials, certificates.

10. Privileged Identity Management (PIM)

Specifically for cloud platforms (e.g., Microsoft Entra ID PIM), JIT activation of admin roles with approval and notification.

---

PAM Concepts

Standing Privilege

A user or account that always holds privileged rights, regardless of whether they're using them. Standing privilege is the largest source of risk PAM tries to remove.

Just-in-Time (JIT) Privilege

Privileged rights are granted only for the duration of a specific task, after authentication and (usually) approval.

Zero Standing Privilege (ZSP)

The aspirational state where no human identity carries persistent admin rights. Privileges are always elevated on demand.

Break-Glass Accounts

Emergency accounts used only when normal access is unavailable. Vaulted, rarely used, hardware-key-protected, monitored on every use.

Tiered Administration

A model (popularized by Microsoft) that separates admin accounts and workstations into tiers based on the sensitivity of the assets they touch:

• Tier 0: identity infrastructure (domain controllers, IdPs).
• Tier 1: servers and applications.
• Tier 2: user workstations.

Admin credentials must never cross tiers downward.

---

How PAM Works in Practice

Example 1: Server Administration via Vault

An SRE needs to log into a production server.

1. They authenticate to the PAM portal with MFA.
2. They request a session on the target server.
3. An approver signs off (or policy auto-approves for trusted personas).
4. PAM checks out a temporary password from the vault and brokers the SSH session.
5. The session is recorded.
6. After the time window, the password is rotated and the session ends.

The SRE never sees the password and never holds standing access.

Example 2: Microsoft Entra ID PIM

A user is eligible for the Global Administrator role but not active.

1. They activate the role in PIM with MFA + justification.
2. The activation is logged and (optionally) requires approval.
3. The role is active for, say, 1 hour.
4. After 1 hour, the role automatically deactivates.

This converts standing global admin into JIT global admin.

Example 3: Cloud Root / AWS Root

The AWS root account:

• Is stored in the vault with hardware MFA.
• Has no API keys.
• Is used only in true emergencies.
• Is alerted on every login.

For day-to-day administration, IAM roles assumed via SSO (with STS short-term credentials) replace root usage.

Example 4: Service Account Secret

A reporting application needs database credentials.

• The credentials live in the vault.
• The application requests them via a workload identity at runtime.
• PAM rotates them on a schedule.
• No developer ever sees the credential.

Example 5: Third-Party Vendor Access

A vendor needs to support a system for two weeks.

• PAM provisions a time-bound account.
• Sessions are brokered through PAM with full recording.
• Network access is restricted to specific systems.
• Access auto-expires at the end of the engagement.

Example 6: Help Desk Local Admin

Help desk technicians sometimes need local admin on user workstations.

• Standing local admin is removed.
• PAM grants temporary local admin via LAPS-style password vaulting.
• Each elevation is logged.

---

Common PAM Use Cases

Use Case	What PAM Provides
Domain admin protection	Vaulting, JIT, session recording
Cloud admin protection	PIM/JIT for cloud roles
DBA access	Brokered, recorded database sessions
SSH/RDP gateway	Centralized broker with credential injection
Vendor access	Time-bound, monitored remote access
Secrets management	API keys, DB creds, certificates in a vault
Service account control	Discovery, ownership, rotation
Compliance evidence	Audit logs, session videos, approvals
Insider risk	Approval and recording deter abuse
Incident response	Forensic evidence of privileged actions

---

Common PAM Mistakes

1. Vaulting Without Eliminating Standing Privilege

Putting credentials in a vault is good. Continuing to leave admin rights always-on is bad. Real benefit comes from JIT.

2. Skipping Discovery

If you don't continuously discover privileged accounts, the unmanaged ones become the attack vector.

3. Ignoring Service Accounts

Many PAM programs focus on humans and forget service accounts — usually the most privileged identities in the environment.

4. Weak MFA on PAM Portal

The PAM portal itself must use phishing-resistant MFA. If attackers compromise it, they get the keys to everything.

5. PAM Bypass

Direct SSH/RDP/API paths to systems that bypass PAM defeat the whole control.

6. Stale Approvals

If approvers rubber-stamp every request, the workflow is theater.

7. No Session Review

Recording sessions but never reviewing them or sampling them removes deterrence.

8. Ignoring Cloud-Native PAM

Cloud platforms have native JIT mechanisms (PIM, IAM Identity Center, IAM Conditions). Ignoring them in favor of legacy on-premises PAM only creates duplication.

---

PAM Best Practices

1. Aim for Zero Standing Privilege for human identities.
2. Vault all privileged credentials, including service accounts.
3. Rotate credentials automatically, ideally after each use.
4. Use JIT elevation with approval for all admin actions.
5. Broker sessions via the PAM platform; block direct paths.
6. Record and audit all privileged sessions.
7. Tier administration and prevent credential reuse across tiers.
8. Protect the PAM platform itself with hardware MFA and strict access.
9. Inventory and tighten service accounts.
10. Manage break-glass accounts with hardware keys and monitoring.
11. Integrate PAM with IGA and SIEM for end-to-end identity governance.
12. Map and monitor attack paths that lead to privileged access.

---

PAM Checklist

• Are all human admin accounts JIT-only?
• Are all privileged credentials vaulted and rotated?
• Are sessions brokered and recorded?
• Are approval workflows in place for sensitive elevations?
• Are service accounts inventoried, owned, and rotated?
• Are break-glass accounts protected and monitored?
• Are admin tiers defined and enforced?
• Is PAM portal access protected with phishing-resistant MFA?
• Are bypass paths (direct SSH, console access) blocked?
• Are PAM logs sent to SIEM and alerted on anomalies?
• Are privileged group memberships reviewed at least quarterly?
• Is attack path analysis used to find indirect routes to privilege?

---

How Forestall Helps

PAM controls known privileged accounts. But many compromises succeed because attackers find paths that turn ordinary access into privileged access — paths that PAM tools don't see.

Forestall complements PAM by mapping:

• Every identity that can become privileged, directly or indirectly.
• Hidden routes through nested groups, ownership, ACLs, and delegations.
• Service accounts that bypass PAM controls.
• Cloud and AD identities with effective Tier 0 access.

This lets PAM teams know which non-vaulted identities still need to be brought under control.

---

Frequently Asked Questions

Is PAM the same as IAM?

No. IAM manages all identities. PAM is the subset focused on privileged identities and sessions.

What's the difference between PAM and PIM?

PIM (Privileged Identity Management) is often used for cloud-native JIT role activation (e.g., Microsoft Entra ID PIM). PAM is the broader category that also covers vaulting, session brokering, and on-premises privileged accounts.

Do small organizations need PAM?

Yes. The fundamentals — vault privileged credentials, eliminate standing admin, MFA all elevations — apply at any size.

Should service accounts be in PAM?

Absolutely. They are often the most privileged identities. Discovery, ownership, vaulting, and rotation are essential.

Does PAM eliminate the need for least privilege?

No. PAM enforces least privilege over time and access. Both are required.

---

Conclusion

PAM exists because privileged access is the highest-impact target in any environment. By vaulting credentials, eliminating standing privilege, brokering sessions, and recording activity, PAM dramatically reduces both the likelihood and impact of privileged compromise.

But PAM is most effective when paired with continuous identity attack path analysis — because the most dangerous privileged access is often the access nobody knew existed.