PAM

How it works

PAM (Privileged Access Management) puts a broker in front of high-risk credentials, root, domain admin, database superuser, cloud IAM admin roles, instead of handing them to engineers directly. Passwords for those accounts live in a vault (CyberArk, HashiCorp Vault, Delinea) that rotates them automatically; a user requests a session, the vault checks the policy, then either injects the credential without ever showing it or brokers a time-boxed, recorded session. Every privileged action is logged, and access typically expires in minutes or hours instead of staying valid indefinitely.

When it matters

PAM matters the moment a compromised laptop or phished engineer could reach production databases or cloud infrastructure directly, which for most companies is immediately after the first EC2 instance or RDS database goes live. It is the control auditors ask about hardest, because standing admin credentials are the single biggest blast radius in a breach: the 2020 Twitter hack and countless ransomware incidents trace back to a privileged account with no time limit and no monitoring. Pair it with MFA on the vault itself and zero trust network access so the vault is not just another static secret to steal. See Replace Static API Keys.

Common misconceptions

• "PAM is only for large enterprises." A ten-person startup with one AWS root account and no rotation has more privileged-access risk than a large company with a vault, because there is no fallback if that one credential leaks.
• "A password manager is basically PAM." A password manager stores secrets for humans to retrieve and use. PAM brokers time-boxed access, rotates credentials automatically, and records sessions; the human often never sees the password at all.
• "PAM slows engineers down." A well-run vault issues a session in seconds through a CLI or SSO-backed request; the friction that actually slows teams down is a shared root password nobody remembers the rotation schedule for.