Privileged Access Management (PAM): Vaulting and Just-in-Time Access

Privileged credentials are the skeleton keys of your infrastructure. Admin accounts, service accounts with database write access, cloud IAM roles with deployment permissions, root credentials for network devices — an attacker who obtains any of these can move laterally, escalate privileges, and cause damage far beyond what a standard user account would allow.

PAM (Privileged Access Management) is the set of policies, processes, and technology that controls, monitors, and audits how privileged credentials are stored, accessed, and used.

Why PAM Matters

The Verizon Data Breach Investigations Report consistently identifies compromised credentials as the leading attack vector — present in 74%+ of breaches. A significant portion of those involve privileged credentials.

The specific risks PAM addresses:

• Credential sharing — A team shares a single root or admin password. When it changes, operations break. When an employee leaves, you cannot be sure all credential knowledge is gone.
• Hardcoded credentials — Service accounts with passwords embedded in scripts, config files, or application code. No rotation, no audit trail.
• Indefinite access — A contractor is given admin access for a project, finishes, and access is never revoked.
• No audit trail — Admin activities are logged at the OS level but not correlated to the individual who performed them.
• Lateral movement — An attacker compromises one privileged account and uses it to compromise others in the same Tier 0 zone.

PAM Architecture

A PAM solution typically consists of:

Credential Vault — Encrypted storage for privileged credentials. The vault stores passwords, SSH keys, API keys, and certificates. Applications and users request credentials from the vault rather than storing them locally.

Session Manager — A jump host or proxy through which all privileged sessions are routed. The session manager provides session recording, command filtering, and real-time monitoring.

Password Manager — Automates credential rotation. After a privileged session ends (or on a defined schedule), the password manager rotates the credential so it cannot be reused.

Access Request Workflow — Just-in-time (JIT) access: users request access to a privileged account, the request is approved (automatically or by a manager), access is granted for a limited time, and automatically revoked when the window expires.

Credential Vaulting

The vault is the foundation of any PAM program. All privileged credentials should be stored in the vault — none should exist in:

• Spreadsheets or documents
• Password manager browser extensions not managed by IT
• Application code or configuration files
• Chat messages or email

Vault access patterns:

Human access (interactive session):

1. Engineer requests access to prod-db-admin via PAM portal
2. PAM checks policy — is this person authorized for this system at this time?
3. If approved, PAM provides a time-limited, one-time credential — or opens a proxied session where the engineer never sees the password
4. Session is recorded
5. When session ends, credential is automatically rotated

Machine access (application-to-application):

1. Application authenticates to vault using its own identity (certificate, IAM role, Kubernetes service account)
2. Vault returns the requested credential for the session
3. Application uses it; credential is rotated after use or on schedule

HashiCorp Vault implementation (open-source alternative):

# Enable database secrets engine
vault secrets enable database

# Configure PostgreSQL connection
vault write database/config/production-db \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-role,readonly-role" \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/myapp" \
  username="vault-admin" \
  password="initial-password"

# Create a dynamic credentials role
vault write database/roles/app-role \
  db_name=production-db \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT app_user TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

Applications call vault read database/creds/app-role and receive a unique username and password valid for 1 hour. No shared credentials, no rotation coordination required.

Just-in-Time (JIT) Access

Standing privileged access — accounts that always have admin rights — presents a constant attack surface. JIT access means privileges exist only when needed.

JIT patterns:

Time-limited elevation: A DevOps engineer's normal account has read-only access to production. When they need to deploy, they request elevation via the PAM portal. Approval is granted (automatically for low-risk operations, or by a manager for high-risk ones). They have admin access for 2 hours. When the window expires, access is automatically revoked.

Break-glass accounts: Emergency admin accounts for disaster recovery scenarios, stored in the vault with mandatory dual-person access (two people must both approve) and full session recording. Used rarely, audited always.

Teleport for infrastructure JIT:

# Teleport access request
kind: role
version: v7
metadata:
  name: prod-admin-requestable
spec:
  allow:
    request:
      roles: ["prod-admin"]
      thresholds:
        - approve: 1   # 1 approver required
          deny: 1
      annotations:
        reason: "required"  # Must provide justification

# Request access
tsh request create --roles=prod-admin \
  --reason="Investigating P1 incident #1234" \
  --reviewers=alice@company.com

# After approval, access is automatically granted and timed
tsh request show <request-id>

Session Recording and Auditing

Privileged session recording provides an immutable audit trail of exactly what was done during each privileged session. This serves three purposes:

1. Forensic investigation — After an incident, replay the session to understand what commands were run, what data was accessed, what changes were made.
2. Compliance — PCI DSS, HIPAA, and SOX require detailed logging of privileged activities. Session recordings satisfy this requirement.
3. Deterrence — People behave differently when they know their actions are recorded.

What to record:

• All terminal (SSH, RDP) sessions to privileged systems
• Database query sessions
• Cloud console sessions for admin activities
• Application admin console sessions

Storage: Session recordings can be large. Store in immutable object storage (S3 with Object Lock) for compliance-required retention periods. Use lifecycle policies to move to cold storage after 90 days.

CyberArk vs BeyondTrust vs Delinea

The enterprise PAM market is dominated by three vendors:

CyberArk

Strengths:

• Deepest privileged access coverage — endpoints, cloud, DevOps, RPA
• Best-in-class privileged threat analytics (Privileged Threat Analytics module)
• Most mature PCI/HIPAA/FedRAMP compliance features
• Large professional services ecosystem

Weaknesses:

• High licensing and implementation cost
• Complex to deploy and maintain
• Steep learning curve for administrators

Best for: Large enterprises, regulated industries (banking, healthcare, government), organizations with complex privileged access environments.

BeyondTrust

Strengths:

• Strong remote access capabilities (BeyondTrust Remote Support)
• Good cloud and SaaS privileged access management
• Competitive pricing vs. CyberArk
• Unified platform for privileged access and vulnerability management

Weaknesses:

• Threat analytics less mature than CyberArk PTA
• UI less polished than competitors

Best for: Mid-market organizations, organizations with significant remote support requirements.

Delinea (formerly Thycotic + Centrify)

Strengths:

• Easier deployment than CyberArk
• SaaS-native delivery available
• Good cloud entitlement management
• Competitive pricing

Weaknesses:

• Less feature-complete than CyberArk for complex scenarios
• Smaller professional services ecosystem

Best for: Mid-market, cloud-first organizations wanting faster time-to-value.

Starting a PAM Program

You do not need an enterprise PAM product to start. A phased approach:

Phase 1 (Month 1-3): Discover and inventory all privileged accounts. This is often shocking — most organizations find 3-5x more privileged accounts than they expected.

Phase 2 (Month 3-6): Vault the highest-risk credentials — domain admin, cloud admin, database admin, network device root. Even a basic secrets manager (AWS Secrets Manager, HashiCorp Vault) significantly reduces exposure.

Phase 3 (Month 6-12): Implement JIT access for human privileged access to production systems. Add session recording.

Phase 4 (Ongoing): Roll out to all privileged access categories. Reduce standing privileges toward zero. Automate credential rotation.

PAM is one of the highest-ROI security investments an organization can make — not because it prevents all attacks, but because it dramatically limits what an attacker can do with any single compromised credential.