Privileged Access Management

1. What is Privileged Access

Privileged Account Types

Privileged accounts hold elevated rights that, if compromised, can result in full organizational compromise. Understanding each type is the first step toward controlling them.

Root / Local Admin: Unrestricted OS access. On Linux, root controls every file, process, and service. On Windows, local Administrator can bypass most security controls.
Domain Admin: Controls the entire Active Directory forest. A single compromised Domain Admin account means every Windows system is owned.
Service Accounts: Non-human accounts used by applications and scheduled tasks. Often over-permissioned, rarely rotated, and shared across teams.
Cloud Admin Roles: AWS root account, Azure Global Administrator, GCP Owner. These grant billing and identity control in addition to resource access.
Database Admins (DBA): SA accounts in SQL Server, SYSDBA in Oracle, postgres superuser. Direct access to all data without application-layer controls.
Network Device Admin: Enable-mode on Cisco, admin on firewalls and switches. Can reroute or capture all network traffic.

Why Privileged Accounts Are Targeted

Attackers focus on privilege escalation because it converts limited initial access into unrestricted control. The attack path is well-understood and repeatable.

Initial Access: Phishing email, exposed RDP, vulnerable web app, or supply chain compromise gives a foothold with limited rights.
Credential Theft: Mimikatz, credential dumping from LSASS, token impersonation, or Pass-the-Hash to harvest privileged credentials cached on the compromised host.
Privilege Escalation: Exploit unpatched local vulnerability or misconfiguration to gain local admin, then pivot to higher-privilege accounts.
Lateral Movement: Use harvested credentials (PtH, PtT, Kerberoasting) to move across the network, targeting systems with more valuable accounts.
Domain Compromise: Reach Domain Admin or DCSync rights. At this point the entire AD forest is compromised — no system is trusted.
Objective Achieved: Ransomware deployment, data exfiltration, persistent backdoor installation at the highest privilege level.

Principle of Least Privilege

Every account — human or service — should hold only the minimum permissions required to perform its specific function, and only for as long as needed.

Audit existing permissions quarterly — most accounts accumulate rights over time
Use role-based access instead of individual permission grants
Time-bound elevated access: request, approve, use, auto-revoke
Separate administrative accounts from daily-use accounts (admin@domain for admin tasks, user@domain for email/browsing)
Service accounts should only have rights to their specific resources, not domain-wide rights
Cloud IAM: use fine-grained policies, not AdministratorAccess for all services

Account Type	Risk Level	Primary Threat	Controls Needed
Domain Admin	Critical	DCSync, Golden Ticket, forest compromise	Vault, JIT, session recording, Tier 0 workstation only
Cloud Root / Global Admin	Critical	IAM takeover, resource destruction, billing fraud	MFA hardware key, alert on every use, no daily use
Local Admin	High	Lateral movement via PtH, credential dumping	LAPS (unique password per host), Credential Guard
Service Account	High	Kerberoasting (if SPN set), credential theft	Vault-managed, no interactive login, gMSA where possible
DBA / SA Account	High	Data exfiltration, data destruction	Vault, session recording, query logging, DAM
Network Admin	High	Traffic interception, backdoor routes	Vault, jump server, full session recording

2. PAM Core Controls

Just-in-Time (JIT) Access

Standing privileged access is one of the most dangerous configurations in enterprise IT. JIT eliminates persistent privilege by making access time-limited and approval-gated.

Request: Admin submits a business justification, target system, and required duration through the PAM portal or ticketing integration
Approve: Manager or second admin reviews and approves (or auto-approves for pre-defined low-risk requests)
Access Granted: Privileged credentials are checked out or a time-limited session token is issued; access window starts
Auto-Revoke: At expiration, access is automatically revoked, password is rotated, and session is terminated regardless of activity
Audit Trail: Every request, approval, access, and revocation is logged with timestamp and reason

Zero standing privilegeTime-boundApproval workflow

Privileged Session Management (PSM)

PSM acts as a proxy between the administrator and the target system. The admin never connects directly — all traffic flows through the PAM proxy, enabling recording and control.

Session Proxy: Admin connects to PAM; PAM connects to target with vaulted credentials. Admin never sees the actual password.
Video Recording: Full screen recording of RDP, VNC, and web sessions stored tamper-evidently for audit and forensics
Keystroke Logging: All keystrokes in SSH and terminal sessions captured as searchable text — find "DROP TABLE" or "wget" across all sessions
Session Termination: Automatic or manual session kill for suspicious activity; alerts trigger on blacklisted commands
Session Replay: Forensic review of any past session frame-by-frame or by text search
Command Allow/Blocklists: Block specific commands (rm -rf /, shutdown, net user) in real time

Password Vaulting

A password vault stores privileged credentials in an encrypted repository. Critically, the human admin never knows the actual password — they check out access, use it, and the password rotates automatically.

No Human Knowledge: Passwords are random, complex, and known only to the vault. Eliminates shared passwords and post-departure risks.
Automatic Rotation: After each check-out, or on a schedule (daily/weekly), passwords are automatically changed and verified
High Availability: Enterprise vaults run as clustered services with encrypted backups — loss of vault access cannot block legitimate work
Application-to-Application: Applications can also check out credentials programmatically, eliminating hardcoded passwords in config files
SSH Key Management: Vault manages SSH private keys, rotating and distributing them to target systems without human handling

Break-Glass Emergency Accounts

Every organization needs emergency admin access for when normal PAM infrastructure fails. Break-glass accounts provide this escape hatch with strict controls.

Credentials stored offline — printed and sealed in a physically secured envelope, or split across two safes
Use of break-glass triggers immediate alerts to security leadership, CISO, and incident response
All activity during break-glass use is reviewed within 24 hours — treat every use as a potential security incident
Credentials rotated immediately after each use — the envelope is destroyed and a new one created
Two-person integrity: require two authorized individuals present to use break-glass credentials
Test break-glass procedures quarterly to ensure envelopes are accessible and credentials work

Emergency onlyImmediate alerting

3. PAM Solutions Comparison

CyberArk

The market leader for enterprise PAM. Comprehensive feature set including Vault (Enterprise Password Vault), PSM (session recording/proxy), AAPM (Application Access Manager for non-human credentials), and CyberArk Identity for broader IAM.

EPV (Enterprise Password Vault): core credential store with HSM integration
PSM (Privileged Session Manager): full video + keystroke recording for RDP, SSH, web
AAPM: eliminates hardcoded application credentials, API integration for DevOps
Defender: MFA for privileged sessions, step-up authentication
SaaS (Privilege Cloud) and on-premises deployment options

EnterpriseHigh cost

BeyondTrust

Strong in both PAM (Password Safe) and endpoint privilege management (Privilege Management for Windows/Mac/Linux). Good for organizations that need both server PAM and desktop least-privilege enforcement.

Password Safe: vault + session management for servers and network devices
Privilege Management: elevate specific applications without local admin rights
Remote Support: secure vendor/support access with session recording
Compliance reporting built-in for SOX, PCI, HIPAA

EnterpriseEndpoint focus

Delinea (formerly Thycotic / Centrify)

Good mid-market PAM option. Secret Server is the core vault product. Strong Unix/Linux PAM integration and AD bridging. More accessible pricing than CyberArk while covering core use cases.

Secret Server: vault with web UI, workflow engine, and SIEM integration
Privilege Manager: application control and least privilege for endpoints
Server Suite: Unix/Linux identity bridging to Active Directory
Cloud-hosted (Secret Server Cloud) or on-premises

Mid-marketGood Linux support

HashiCorp Vault + Cloud-Native PAM

HashiCorp Vault is the developer-preferred secrets and PAM platform, especially in cloud and Kubernetes environments. Cloud-native alternatives from AWS and Azure serve organizations already deep in a single cloud.

HashiCorp Vault: dynamic secrets (generate DB creds on demand), PKI engine, SSH CA, lease system
AWS Secrets Manager: RDS/Redshift auto-rotation, cross-account, Lambda integration
AWS SSM Parameter Store: simpler, cheaper, good for non-critical secrets
Azure Key Vault: certificates, keys, secrets with Managed Identity access (no credentials needed)
All cloud-native options lack enterprise PSM (session recording) — need separate tooling

DevOps-nativeOpen source option

Tool	Deployment	Password Vault	Session Recording	Cloud Native	Cost Tier
CyberArk	On-prem / SaaS	Yes (EPV)	Yes (PSM)	Partial	Enterprise ($$$)
BeyondTrust	On-prem / Cloud	Yes (Password Safe)	Yes	Partial	Enterprise ($$$)
Delinea Secret Server	On-prem / SaaS	Yes	Yes (add-on)	Partial	Mid-market ($$)
HashiCorp Vault	Self-hosted / HCP	Yes + dynamic	No	Yes	Open source / Enterprise
AWS Secrets Manager	AWS-only	Yes	No	Yes (AWS)	Pay-per-use ($)
Azure Key Vault	Azure-only	Yes	No	Yes (Azure)	Pay-per-use ($)

4. Linux & Windows Privileged Access

Linux Privilege Controls

Linux privileged access centers on sudo configuration, PAM modules for auditing, and restricting direct root login. Every privileged action should be attributable to a named user.

Disable direct root SSH: Set PermitRootLogin no in sshd_config. Require su or sudo escalation from named accounts.
Sudo logging: All sudo commands appear in /var/log/auth.log (Debian) or /var/log/secure (RHEL) with username, command, and timestamp.
pam_tty_audit: PAM module that records all keystrokes during elevated sessions to the kernel audit log — even commands run after sudo su -.
visudo restrictions: Use Cmnd_Alias to restrict users to specific commands rather than granting full sudo. Use NOPASSWD sparingly and only for automation.
auditd: Linux audit daemon captures privilege escalation, file access by root, setuid execution, and account changes. Forward to SIEM.

Windows Privilege Controls

Windows privileged access hardening spans Active Directory security groups, credential protection, local admin password management, and PowerShell delegation.

Protected Users Security Group: AD group that blocks NTLM authentication, DES/RC4 Kerberos encryption, and credential caching. Add all privileged accounts.
Credential Guard: Virtualization-based security (VBS) isolates LSASS in a secure enclave. Makes credential dumping with Mimikatz significantly harder.
LAPS v2 (Local Administrator Password Solution): Microsoft-native tool that generates a unique, random local admin password for every Windows machine, stored in AD with access controls. Eliminates lateral movement via shared local admin passwords.
JEA (Just Enough Administration): PowerShell remoting with constrained runspaces. Administrators only have access to specific cmdlets needed for their role — not a full shell.
AD Tiering: Tier 0 (DCs, PKI, AD Connect) — Tier 1 (member servers) — Tier 2 (workstations). Admin accounts must not cross tiers; a Tier 2 admin account cannot authenticate to a Tier 0 system.

# sudoers: restrict deployment user to only restart specific service
# Edit with: sudo visudo
Cmnd_Alias WEBAPP_CMDS = /usr/bin/systemctl restart webapp, \
                          /usr/bin/systemctl status webapp, \
                          /usr/bin/journalctl -u webapp

deploy ALL=(root) NOPASSWD: WEBAPP_CMDS
# deploy user CANNOT run arbitrary commands or get a shell

# Verify sudoers syntax before saving:
# visudo -c

# Enable pam_tty_audit for all privileged sessions in /etc/pam.d/sudo:
# session required pam_tty_audit.so enable=*

# Linux: check who has sudo rights
getent group sudo wheel
sudo -l -U username  # list a specific user's sudo permissions

# LAPS v2 - Windows: Read managed local admin password via PowerShell
# Requires LAPS module and permission to read the attribute
Get-LapsADPassword -Identity "WORKSTATION01" -AsPlainText

# Find machines without LAPS-managed passwords (should return none)
Get-ADComputer -Filter {ms-Mcs-AdmPwd -notlike "*"} -Properties ms-Mcs-AdmPwd

# Windows: Check Protected Users group membership
Get-ADGroupMember -Identity "Protected Users" | Select Name, SamAccountName

# JEA: Create a constrained endpoint
New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer `
    -VisibleCmdlets 'Get-Service','Restart-Service' `
    -Path C:\JEA\WebAdminRole.pssc

AD Tiering: The Most Violated PAM Principle

The most common PAM failure is using a Domain Admin account to browse the web, read email, or log into workstations. A Tier 0 account that touches a compromised workstation (Tier 2) can have its credentials stolen via LSASS dumping. Strict tier separation — enforced by Authentication Policy Silos in Active Directory — is non-negotiable for organizations managing critical infrastructure.

5. PAM Metrics & Maturity

PAM KPIs to Track

Measuring PAM program effectiveness requires quantitative metrics reviewed at least quarterly by security leadership.

% Privileged Accounts Vaulted: Target 100%. Any unvaulted privileged account is an uncontrolled risk. Start with inventory to know your denominator.
% Sessions Recorded: Target 100% of production server and network device admin sessions. Gaps in recording create forensic blind spots.
MTTR for Access Revocation: How quickly can a privileged account be disabled after a termination or incident? Target: under 1 hour for emergency, under 4 hours for standard offboarding.
Standing Privilege Ratio: Percentage of privileged accounts with persistent access vs JIT access. Target: drive toward 0% standing privilege for human accounts.
Shared Account Usage: Track and eliminate shared admin credentials. Every privileged action must be attributable to a named individual.
Password Age: Percentage of vaulted passwords last rotated within policy window. Flag accounts exceeding 30 days without rotation.

Common PAM Failures

PAM programs frequently fail in predictable ways. These are the leading causes of privileged access-related breaches.

Shared Admin Accounts: "administrator" or "root" used by multiple people. No individual accountability; cannot investigate post-incident.
Standing Privileges: Permanent Domain Admin or cloud Owner roles that sit idle but remain active. A credential theft at any time equals full compromise.
No Session Recording: Privileged activity occurs without a forensic trail. Incident investigation requires guessing what the attacker did.
Unvaulted Service Accounts: Application credentials stored in config files, scripts, or environment variables. Regularly exposed in code repository leaks.
Incomplete Inventory: PAM programs that don't know all privileged accounts exist. Shadow IT, forgotten service accounts, and legacy systems regularly surprise teams during assessments.
PAM for Servers, Not Cloud: On-premises PAM deployed without covering cloud IAM roles, which are equally (or more) powerful.

PAM Maturity Roadmap

Building a PAM program is a multi-year journey. Focus on highest-risk controls first rather than trying to achieve full maturity in one project.

Phase 1 — Inventory: Discover all privileged accounts (AD, cloud, network, database, application). You cannot protect what you don't know exists.
Phase 2 — Vault Tier 0: Vault Domain Admin, cloud admin, and firewall admin credentials. Deploy session recording for these accounts first.
Phase 3 — LAPS + Credential Guard: Eliminate shared local admin passwords. Deploy Credential Guard on all Windows servers and workstations.
Phase 4 — JIT Access: Replace standing privileged access with just-in-time workflows. Eliminate all permanent admin group memberships for human accounts.
Phase 5 — Service Account Management: Migrate service accounts to gMSA (group Managed Service Accounts) or vault-managed dynamic credentials.
Phase 6 — Cloud PAM: Extend JIT to cloud IAM roles. Implement AWS IAM Identity Center or Azure PIM for cloud privileged access.

The Ransomware Path Runs Through Privileged Accounts

In nearly every successful ransomware deployment, threat actors reach a privileged account before detonating their payload. Whether via Kerberoasting a service account, Pass-the-Hash to a local admin, or credential dumping from an over-privileged jump server — the common denominator is uncontrolled privileged access. Vaulting all privileged credentials and implementing just-in-time access breaks the attack chain at the most critical point. This single control family has the highest return on security investment of any PAM capability.