Privileged User Management

Key Control Areas

• Credential Vaulting and Lifecycle Management (IA-05, AC-02, CM-03, SC-28, IA-04): The credential vault is the foundation of PAM. IA-05 governs authenticator management: privileged passwords stored in an enterprise vault (CyberArk, HashiCorp Vault, Delinea, BeyondTrust), encrypted at rest and in transit, with automatic rotation after every checkout or on a scheduled basis. No privileged credential should exist in plaintext: not in scripts, not in configuration files, not in documentation, not on sticky notes. AC-02 manages the privileged account inventory: every privileged account must be discovered, classified (human admin, service account, application account, emergency account), and assigned an owner. Discovery scanning must run continuously to detect new privileged accounts, privilege escalation, and shadow admin accounts. CM-03 controls configuration changes to the vault itself: vault configuration changes require dual approval, are logged, and are tested before deployment. SC-28 protects credentials at rest: vault storage uses HSM-backed encryption, master keys are split across multiple custodians, and backup vaults are equally protected. IA-04 manages the identifier lifecycle: privileged accounts are created through a formal request process, reviewed regularly, and disabled immediately when no longer required. Service accounts are the hardest to manage -- they proliferate, their owners leave, and their passwords are embedded in configurations that nobody wants to touch.
• Just-In-Time Access and Zero Standing Privileges (AC-02, AC-06, AC-17, PE-03, CM-05): Just-in-time access transforms privileged access from a permanent state to a temporary event. AC-02 enables dynamic account provisioning: admin rights are added to a user's existing account (or a dedicated admin account is checked out) only when a specific task requires them, and removed automatically when the task is complete or the time window expires. AC-06 enforces least privilege: JIT requests must specify the scope (which systems, which actions, which data) and the duration (minimum necessary, not 'until I'm done'). AC-17 governs remote privileged access: administrative access through VPN, bastion hosts, or cloud consoles uses the same JIT model -- no standing remote admin access. PE-03 extends physical access controls to privileged environments: data centre access, console access, and out-of-band management access follow the same JIT principles. CM-05 restricts access to production configuration changes: changes require privileged access obtained through the JIT workflow, linking every change to an approved request. Zero standing privileges is the target state: no human account has permanent administrative rights. This is achievable for many systems (cloud IAM, modern AD, database access) but challenging for some legacy systems and all break-glass scenarios. Track the ratio of standing-to-JIT privileges as a maturity metric.
• Session Brokering, Isolation, and Recording (AC-17, AU-02, AU-12, SI-04, AC-03): Privileged sessions must be isolated and recorded. AC-17 manages remote access sessions through a PAM proxy or jump server: administrators do not connect directly to target systems but through a brokered session that the PAM platform controls. AU-02 defines which privileged session events must be logged: every command entered, every file accessed, every configuration change, every database query. AU-12 generates the audit records: full session recording (video-style replay for RDP/VNC, command-level logging for SSH) stored immutably with the session metadata including who, when, why (linked to the access request), and from where. SI-04 monitors privileged sessions in real time: anomaly detection on command patterns, alerting on high-risk actions (adding users to admin groups, modifying security configurations, accessing crown jewel data), and the ability to terminate sessions immediately when policy violations are detected. AC-03 enforces command filtering: restricting which commands can be executed even within an approved privileged session, preventing accidental or deliberate actions outside the approved scope. Session recording serves three purposes: deterrence (admins behave differently when recorded), investigation (full timeline when incidents occur), and compliance (demonstrable evidence of privileged access controls for auditors).
• Service Account and Application Credential Management (IA-05, AC-02, SA-04, CM-02, SC-12): Service accounts are the largest and least-managed privileged attack surface. IA-05 applies to service account credentials: passwords must be vaulted, rotated automatically, and never embedded in source code or configuration files. Application credentials should use short-lived tokens (OAuth client credentials, cloud IAM role assumption) rather than long-lived passwords wherever possible. AC-02 requires a complete inventory of service accounts with documented owners, purposes, and the systems they access. Every service account must have a human owner who is accountable for its use and who reviews its continued necessity. SA-04 addresses service account credentials in the acquisition process: new applications must be designed to retrieve credentials from the vault at runtime rather than storing them in configuration files. CM-02 establishes baseline configurations for service accounts: minimum required permissions, restricted logon types (service logon only, no interactive logon), and network restrictions limiting where the account can authenticate from. SC-12 governs cryptographic key management for service-to-service authentication: API keys, TLS certificates, and signing keys follow the same vault-and-rotate model as passwords. The most dangerous service accounts are those with domain admin or cloud admin equivalent permissions that were created years ago and whose original purpose is forgotten.
• Break-Glass and Emergency Access (AC-02, AU-02, IR-04, PM-14, AC-06): Emergency access must work when everything else has failed. AC-02 defines break-glass account management: pre-provisioned emergency accounts stored in the vault with credentials sealed in a dual-custody process (two people required to retrieve). Break-glass accounts must work when the primary PAM platform is unavailable -- this means local accounts on critical systems, pre-positioned credentials on offline media, or hardware tokens in a physical safe. AU-02 ensures break-glass access generates maximum audit trail: alerts to the SOC, notifications to the CISO and security team, automatic creation of an incident ticket that requires review within 24 hours. IR-04 integrates break-glass access with incident response: break-glass credentials may be needed during a security incident precisely when the PAM platform is a target. PM-14 tests break-glass procedures regularly: quarterly tests that validate credentials work, alerts fire, and the post-use review process functions. AC-06 limits break-glass scope: even emergency accounts should not be global admin -- create tier-specific break-glass accounts (domain admin, cloud admin, network admin) rather than a single god account. Break-glass is a paradox: it must be easy enough to use in an emergency but controlled enough that it cannot be abused. The solution is ease of use combined with maximum visibility.
• Privileged Access Governance and Reviews (AC-02, CA-02, AU-06, PM-12, AC-06): Governance ensures the PAM programme remains effective over time. AC-02 mandates regular access reviews: quarterly certification of all privileged accounts (human and service), with explicit re-approval or revocation. Reviews must cover: is the account still needed, does it still need this level of access, is the owner still appropriate, when was it last used. CA-02 assesses the effectiveness of PAM controls: are vault policies being followed, is JIT adoption increasing, what percentage of privileged access is still standing. AU-06 analyses privileged access audit records: trending privileged session frequency, identifying accounts that are checked out but never used (suggesting over-provisioning), detecting anomalous access patterns (admin access at unusual hours, from unusual locations, to unusual systems). PM-12 monitors the insider threat indicators that privileged access amplifies: data exfiltration by DBAs, configuration sabotage by disgruntled admins, and privilege abuse during notice periods. AC-06 enforces privilege separation: no single account should be able to both configure security controls and suppress the audit trail. The dual-admin principle ensures that critical privileged actions require two authorised individuals. Governance metrics should include: percentage of privileged access that is JIT vs standing, average privileged session duration, vault coverage (percentage of privileged accounts managed by PAM), and orphaned account count.
• Cloud and Hybrid Privileged Access (AC-02, AC-17, SA-09, SC-07, IA-02): Cloud environments introduce distinct privileged access challenges. AC-02 manages cloud IAM roles: AWS root accounts locked with MFA and hardware tokens, Azure Global Admin similarly secured, GCP organisation admin roles assigned to break-glass accounts only. Cloud IAM allows programmatic privilege assumption that has no on-premises equivalent -- a compromised developer workstation with cached cloud credentials can assume admin roles instantly. AC-17 governs remote access to cloud management planes: cloud console access through the PAM broker, CLI access using temporary credentials from the vault, and API access using short-lived tokens. SA-09 manages third-party cloud services: SaaS platforms with admin consoles require the same PAM discipline as infrastructure -- vaulted credentials, JIT where supported, session recording where possible. SC-07 protects the boundary between cloud management planes and the corporate network: cloud admin access should not be possible from any endpoint, only from hardened privileged access workstations (PAWs). IA-02 enforces strong authentication for cloud privileged access: phishing-resistant MFA (FIDO2/passkeys) for all cloud admin access, with conditional access policies that restrict admin operations to compliant devices from known networks. Hybrid environments are the hardest: on-premises AD synced to Azure AD creates privilege escalation paths where cloud compromise leads to on-premises compromise and vice versa.

When to Use

This pattern applies to every organisation with systems that have administrative or root-level access -- which is every organisation. It is particularly critical for: organisations with regulatory obligations around privileged access (financial services, healthcare, government), environments where privileged access abuse could cause significant financial or operational harm (trading systems, payment systems, critical infrastructure), organisations that have experienced breaches involving compromised privileged credentials, environments with large numbers of administrative accounts (Active Directory, cloud IAM, database servers), organisations with significant outsourcing where third-party administrators need privileged access, any organisation implementing or operating Zero Trust Architecture (SP-029) where privileged access is a key control plane.

When NOT to Use

There are no contraindications for privileged access management -- the question is one of scale and sophistication. Very small organisations (under 20 staff) may implement PAM through procedural controls (documented shared credential management, dual-custody for admin passwords) rather than deploying enterprise PAM tooling. Environments with very few systems may not justify the cost of a commercial PAM platform, but should still vault credentials using password managers and enforce MFA on all admin access. Organisations should not attempt to implement full ZSP in a single phase -- start with credential vaulting for the highest-risk accounts, then expand to JIT, then session recording, then ZSP as maturity grows.

Typical Challenges

The most common challenge is cultural resistance: administrators who have had root or domain admin credentials for years resist having them vaulted and requiring checkout. Service account management is where PAM projects stall: thousands of service accounts with embedded credentials in legacy applications that nobody understands. Password rotation breaks things -- applications with hardcoded credentials fail when the vault rotates their password, requiring application remediation before onboarding. Legacy systems that do not support API-driven credential injection require manual or wrapper-based approaches. Cloud IAM adds complexity with multiple identity planes (AWS IAM, Azure AD, GCP IAM) each requiring different integration approaches. Operational Technology environments often have shared credentials on devices that cannot be integrated with PAM. JIT access creates latency: administrators must request and wait for access rather than connecting immediately, which meets resistance for incident response scenarios (hence break-glass). PAM platform availability becomes a single point of failure: if the vault is down, nobody can administer anything, making vault high availability and break-glass procedures essential. Vendor sprawl: many organisations end up with multiple PAM solutions across different technology tiers, creating management and coverage gaps.

Threat Resistance

Privileged User Management directly addresses the most impactful attack techniques. Credential theft via pass-the-hash and Kerberoasting is mitigated by credential vaulting with automatic rotation that ensures stolen hashes expire before they can be exploited (IA-05, AC-02). Lateral movement using compromised admin credentials is limited by JIT access that ensures privileged credentials exist only during approved windows (AC-02, AC-06). Living-off-the-land attacks that abuse legitimate admin tools are detected through session recording and command monitoring that flags anomalous administrative behaviour (AU-12, SI-04). Privilege escalation through misconfigured cloud IAM roles is prevented by continuous discovery and access reviews that identify over-permissioned roles (AC-02, CA-02). Insider threat from privileged users is deterred by session recording and detected by behavioural analytics on privileged access patterns (AU-06, PM-12). Service account compromise -- one of the most common initial access vectors for advanced attackers -- is mitigated by vaulting service account credentials, rotating them automatically, and restricting their network and logon scope (IA-05, CM-02). The fundamental principle: if an attacker cannot obtain a privileged credential, cannot use it without detection, and cannot persist with it because it rotates, the value of compromising any single account is dramatically reduced.

Assumptions

The organisation has an identity management capability that can enumerate and classify accounts (see SP-010). A credential vaulting solution is deployed or budgeted for. Network architecture supports session brokering through jump servers or PAM proxies. Systems support the concept of individual accountability -- shared admin credentials are being eliminated. Change management processes exist to link privileged access to approved changes. Security monitoring is in place to consume and alert on privileged access events (see SP-031). Management understands that PAM introduces operational friction by design and supports the trade-off.

Developing Areas

• Just-in-time access is maturing as the standard model for human privileged access, but adoption remains uneven. Cloud-native JIT (Azure PIM, AWS IAM Identity Center) covers approximately 40% of enterprise cloud admin access, while on-premises JIT through PAM platforms covers less than 25% of domain admin access. The gap is widest for network devices, databases, and legacy applications where JIT integration requires custom API development or wrapper scripts that most PAM vendors do not support out of the box.
• Cloud PAM for ephemeral infrastructure is an unsolved architectural challenge. In environments where infrastructure is created and destroyed in minutes (Kubernetes pods, Lambda functions, auto-scaling groups), traditional PAM models of credential checkout and session recording do not apply. Emerging approaches include workload identity federation, short-lived certificate-based authentication, and policy-as-code access controls, but no unified PAM model spans both persistent infrastructure and ephemeral cloud-native workloads.
• Zero standing privilege adoption is the stated aspiration of most PAM programmes but the operational reality of fewer than 5% of enterprises. The primary blockers are service accounts with embedded credentials in legacy applications, shared admin credentials on network devices, and break-glass requirements that inherently require pre-positioned standing access. Measuring progress toward ZSP (ratio of standing to JIT privileges) is itself an emerging practice that most PAM platforms do not natively support.
• Privileged access for AI agents and autonomous service accounts is a rapidly emerging challenge with no established governance model. AI coding assistants, automated remediation bots, and orchestration platforms increasingly require elevated privileges to perform their functions, but they do not fit human-centric PAM models of checkout, approval, and session recording. The question of how to apply least privilege, accountability, and session monitoring to non-human entities operating at machine speed is largely unanswered by current PAM architectures.
• Session recording analytics and anomaly detection are evolving from passive storage to active monitoring. Traditional session recording produces terabytes of video and command logs that nobody reviews unless an incident occurs. Emerging capabilities use NLP and behavioural analytics to flag anomalous commands, detect privilege abuse patterns, and alert on high-risk actions in real time. However, the false positive rates remain high and the privacy implications of analysing every administrator keystroke are creating friction with works councils and privacy regulators in the EU.