Privileged access management (PAM) is the set of policies, processes, and tools that control who can use accounts with elevated rights, when, for what purpose, and with what record of what they did. NIST's glossary defines a privileged account as a system account that holds the authorizations of a privileged user. In practice that means domain and server administrators, database and cloud administrators, and the service accounts that run with similar power. An admin password that many people share, that never changes, and that works at any time is exactly what PAM is meant to replace. This article explains how PAM works, what the standards ask for, and how to start before buying any product.
What counts as privileged access
NIST SP 800-53 describes privileged roles, in the discussion of control AC-2(7), as roles that let people perform security-relevant functions ordinary users cannot, such as key management, account management, database administration, system and network administration, and web administration. Privilege is about what an account can do, not about a job title. Common places to find it:
- Human administrators: domain, server, network, database, and cloud-tenant admins
- Application and service accounts: they run with high rights and often have no one watching them (see Service Accounts and Non-human Identities)
- Emergency (break-glass) accounts: powerful by design and rarely used, so they need extra monitoring
- Third-party and vendor access: outside engineers who need admin rights for a limited time
- Cloud and SaaS admin roles: for example tenant or subscription owners, who can change everything beneath them
Why it matters
MITRE ATT&CK catalogs "Valid Accounts" (T1078) as a technique where adversaries obtain and abuse credentials of existing accounts for initial access, persistence, privilege escalation, or defense evasion. Because the activity looks like a normal login, it blends in, and overlapping permissions across local, domain, and cloud accounts can let an attacker pivot to domain or enterprise administrator. MITRE cites groups such as Wizard Spider and Lazarus Group as examples. The point is that one stolen admin credential is not one lost account. It can be the whole environment.
The March 2023 IAM guidance for administrators from CISA and NSA (under the Enduring Security Framework) groups its recommendations into five areas: identity governance, environmental hardening, identity federation and SSO, multifactor authentication, and IAM auditing and monitoring. PAM touches several of them, especially governance, MFA, and monitoring of privileged activity.
How PAM works
The UK NCSC's secure system administration guidance sets out five principles: trust your management devices, protect administration interfaces, manage risk with tiers, use privileged access management, and log and audit administration. Its PAM principle asks you to control who, where, when, why, and how administration happens, give administrators least privilege, and take access away when it is not needed. Those five questions are a useful way to read any PAM design.
- Who: each administrator uses a named account with MFA, not a shared one. SP 800-53 has controls requiring MFA for privileged accounts (IA-2(1)) and non-privileged accounts for non-security tasks (AC-6(2))
- Where: admin work comes from a trusted device and a controlled path. Remote access to privileged commands must be authorized with its rationale documented (AC-17(4)), and network access to privileged commands is limited (AC-6(3))
- When: rights are time-limited. SP 800-53 has controls to disable temporary and emergency accounts automatically after a set time (AC-2(2)) and for dynamic privilege management (AC-2(6))
- Why: elevation is tied to an approved task, such as a ticket, and privileges are reviewed periodically to confirm the need remains (AC-6(7))
- How: use of privileged functions is logged (AC-6(9)), privileged role assignments are monitored, and access is revoked when no longer appropriate (AC-2(7))
PAM products typically deliver this with a few building blocks: a vault that stores and rotates privileged credentials, a broker or gateway that opens sessions without revealing the password, recording of sessions and commands, and just-in-time (JIT) elevation with an approval step. Whether you need all of them depends on your size. What matters more than the brand is that the five controls above actually happen.
Strengths, limits, and where PAM fits
- Strengths: limits the damage when a credential leaks, replaces shared passwords with individual accountability, produces an audit trail for investigations and compliance, and reduces always-on rights
- Limits: does not stop an attacker who already controls an approved admin session, so pair it with MFA and monitoring
- Coverage gaps: only accounts you have discovered are protected, and service accounts, cloud roles, and SaaS admin often fall outside the first rollout
- Friction: approval steps slow urgent fixes unless an emergency path is designed in advance
- Single point of failure: the vault and broker become critical infrastructure and high-value targets, so protect and back them up accordingly
PAM is one part of identity security. IAM manages everyone's identity and access, IGA handles access reviews and the joiner-mover-leaver lifecycle, and PAM focuses on the highest-risk subset. In a zero trust design, PAM is how you apply least privilege and per-session verification to administrators; see Zero Trust Architecture: Components and Roadmap. For a side-by-side of the acronyms, read IAM, IGA, PAM and CIEM compared. Administrator MFA should be phishing-resistant where possible; see Which MFA Is Safer?.
A simple maturity ladder
The ladder below is a rough way to place your organization. It is our own illustration, not a formal standard, and you do not need to reach the top rung on every system. Start with the systems where a compromise would hurt most.
Common mistakes
- Protecting only human admin passwords: service accounts and API keys carry the same power but are often forgotten
- Buying a tool before discovery: you cannot protect accounts you have not found, so survey local admins, service accounts, and cloud roles first
- Leaving access on "just in case": temporary rights that never expire become permanent rights
- Forgetting break-glass accounts: a shared password, no alert when it is used, and never tested
- Treating the vault as a finished project: rotation, reviews, and revocation have to keep happening
- No plan for vendors: a shared, always-open VPN account means nobody knows who did what
Start today
- List privileged accounts: domain admins, local admin on servers, databases, cloud tenant owners, service accounts, and vendor accounts. Count them and assign an owner to each
- Separate admin from daily accounts: read email and browse the web with an account that has no elevated rights
- Turn on MFA for every privileged account: start with cloud consoles and remote access
- Retire shared admin passwords: change them whenever someone leaves, then move them into a vault
- Turn on logging for privileged activity and make sure someone reads it weekly
- Test break-glass accounts: they work, they raise an alert when used, and the credentials are stored safely
Not sure where you stand? Use the self-assessment, then pick two or three of the gaps above to close first.
The permission to delete backups or switch off backup jobs should also be controlled as privileged access; see an example in The 3-2-1-1-0 Backup Strategy and Immutable Backups.
Removing users' local admin rights is a condition that Microsoft's baselines assume. For the steps to harden device settings, see Endpoint Hardening with CIS Benchmarks: Where to Start.
Encryption keys need the same strict access control as privileged accounts. See Encryption Key Management: KMS, HSM and BYOK.
References and further reading
- NIST SP 800-53 Rev. 5: Security and Privacy Controls: source of the AC-2(7), AC-6, and IA-2(1) controls cited here
- NIST Glossary: privileged account: the definition of a privileged account
- NCSC: Secure system administration: five principles for administering systems safely
- CISA: Enduring Security Framework IAM guidance (March 2023): the announcement, with a link to the administrator guide
- MITRE ATT&CK T1078: Valid Accounts: the technique and its list of mitigations
- CISA Zero Trust Maturity Model: five pillars, including identity, and four maturity stages