On this page

Privileged Access Management

Privileged Access Management (PAM) encompasses the policies, processes, and technologies that control access to administrative capabilities, sensitive credentials, and elevated permissions within an organisation’s technology environment. Where standard identity management governs routine user access, PAM addresses the accounts and credentials that can modify security controls, access all data within a system, or cause organisation-wide impact if compromised. A single compromised domain administrator account can disable security monitoring, exfiltrate the entire user database, and deploy ransomware across every connected system within hours. PAM exists to ensure that such powerful access is tightly controlled, monitored, and available only when genuinely required.

The scope of privileged access extends beyond human administrators to encompass service accounts, automation credentials, API keys, and machine identities that systems use to communicate with each other. These non-human identities frequently outnumber human users by a factor of ten or more in modern environments, and they present distinct challenges because they cannot respond to authentication prompts, do not take annual leave (providing natural session breaks), and often accumulate permissions over time as integrations expand. Effective PAM addresses both human and machine privileged access through complementary controls.

Privileged account: Any account with permissions exceeding those required for routine business functions. This includes domain administrators, database administrators, cloud subscription owners, application service accounts, and any identity capable of modifying security configurations or accessing data across trust boundaries.
Standing privilege: Persistent assignment of elevated permissions to an identity. The account holds administrative rights continuously, regardless of whether those rights are actively being used. Standing privileges represent the traditional model and carry the highest risk exposure.
Just-in-time access: Provisioning of elevated permissions only when needed, for a defined duration, with automatic revocation upon expiry or task completion. The account exists in a non-privileged state until access is explicitly requested and approved.
Credential vaulting: Secure storage of privileged credentials (passwords, keys, certificates) in an encrypted repository with access controls, audit logging, and often automated rotation. Users retrieve credentials from the vault rather than knowing them directly.
Session recording: Capture of privileged session activity for audit, investigation, and compliance purposes. Recordings may include keystrokes, screen video, command history, or structured logs depending on the session type and tooling.

Privileged Account Categories

Privileged accounts divide into three functional categories, each requiring distinct controls. Human administrative accounts present authentication and authorisation challenges similar to standard user accounts but with elevated risk. Service accounts and machine identities present automation and integration challenges. Emergency accounts present availability and accountability challenges.

Human administrative accounts include domain administrators, database administrators, network administrators, cloud subscription owners, security administrators, and any staff member with rights to modify system configurations or access data beyond their routine role. The defining characteristic is a human operator who authenticates interactively and makes decisions about actions to perform. Controls for human administrative accounts focus on strong authentication (hardware security keys where feasible), session monitoring, and ensuring administrative access is used only for administrative tasks.

A common anti-pattern is using a single account for both routine work (email, document editing, web browsing) and administrative tasks. This practice exposes administrative credentials to phishing attacks targeting routine activities. The separation principle requires that administrative accounts are used exclusively for administrative purposes, accessed from hardened workstations or through controlled jump servers, and never employed for activities that expose them to untrusted content.

Service accounts and machine identities operate without human interaction, authenticating programmatically to access resources on behalf of applications, automation systems, and integrations. A backup system authenticating to file servers, an application connecting to its database, a monitoring system querying endpoints, and a CI/CD pipeline deploying to production all use service account credentials. These accounts cannot complete multi-factor authentication challenges in the traditional sense, cannot recognise phishing attempts, and often require credentials embedded in configuration files, environment variables, or secrets management systems.

Service account credentials present particular risks because they frequently have broad permissions (granted during initial setup and never reduced), rarely rotate (to avoid breaking dependent systems), and remain active indefinitely (no human to offboard). A compromised service account password embedded in a configuration file checked into version control has exposed organisations repeatedly.

Emergency accounts provide access when normal authentication is unavailable. Sometimes called break-glass accounts, fire-call accounts, or emergency access accounts, these identities exist specifically for scenarios where the primary identity system is unavailable, all administrators are locked out, or a critical incident requires access that normal processes cannot provide quickly enough. Emergency accounts must be powerful enough to restore normal operations but are too dangerous for routine use. Their management requires secure credential storage, clear invocation procedures, and mandatory post-use review. The detailed procedures for emergency access appear in Break-Glass Access.

+------------------------------------------------------------------+
|                   PRIVILEGED ACCOUNT LANDSCAPE                   |
+------------------------------------------------------------------+
|                                                                  |
|  HUMAN ADMINISTRATORS           SERVICE ACCOUNTS                 |
|  +------------------------+     +------------------------+       |
|  |                        |     |                        |       |
|  |  Domain Admin          |     |  Application Service   |       |
|  |  Database Admin        |     |  Backup Service        |       |
|  |  Cloud Admin           |     |  Monitoring Agent      |       |
|  |  Security Admin        |     |  CI/CD Pipeline        |       |
|  |  Network Admin         |     |  Integration Service   |       |
|  |                        |     |  API Credentials       |       |
|  +------------------------+     +------------------------+       |
|           |                              |                       |
|           | Interactive                  | Programmatic          |
|           | authentication               | authentication        |
|           |                              |                       |
|           v                              v                       |
|  +----------------------------------------------------------+    |
|  |                    PAM CONTROLS                          |    |
|  |                                                          |    |
|  |  Credential Vaulting    Session Recording    JIT Access  |    |
|  |  MFA Enforcement        Access Logging       Rotation    |    |
|  +----------------------------------------------------------+    |
|                              |                                   |
|                              v                                   |
|                    EMERGENCY ACCOUNTS                            |
|                    +------------------------+                    |
|                    |                        |                    |
|                    |  Break-glass accounts  |                    |
|                    |  Sealed credentials    |                    |
|                    |  Post-use audit        |                    |
|                    |                        |                    |
|                    +------------------------+                    |
|                                                                  |
+------------------------------------------------------------------+

Figure 1: Privileged account categories and their relationship to PAM controls

Core PAM Principles

PAM implementations rest on four principles that guide control selection and architecture decisions: least privilege, separation of duties, just-in-time access, and accountability through logging.

Least privilege requires that accounts hold only the permissions necessary for their specific function, and hold those permissions only for the duration required. An administrator who needs to restart a service should not require domain administrator rights to do so. A backup service account that reads files should not have write permissions. A deployment pipeline that pushes to staging should not have production credentials. Implementing least privilege demands careful analysis of actual permission requirements and willingness to create more granular roles rather than assigning broad administrative groups for convenience.

Practical least privilege implementation often reveals that organisations have accumulated significant privilege sprawl, with accounts holding permissions granted years earlier for forgotten purposes. Privilege reduction requires discovery (what permissions exist), analysis (which are still needed), and remediation (removing excess permissions without breaking functionality). This process is never complete but rather continuous, as permissions accumulate naturally through change requests and must be actively managed downward.

Separation of duties ensures that no single individual can complete a sensitive action unilaterally. In financial controls, separation prevents one person from both authorising and executing a payment. In technology, separation prevents one administrator from both deploying a change and approving it, or from both accessing sensitive data and disabling the audit logs that would record that access. PAM supports separation through workflow approvals, dual-control mechanisms for critical actions, and role definitions that distribute capabilities across multiple individuals.

Just-in-time access transforms privileged access from a standing capability to an on-demand service. Rather than assigning an administrator permanent membership in the Domain Admins group, just-in-time access adds the administrator to that group only when they submit a request, receive approval (automated or manual depending on risk), and for a defined time window (typically 1 to 8 hours). When the window expires, group membership is automatically revoked. The account exists in a non-privileged state except during active administrative work.

Just-in-time access reduces the attack window from continuous to episodic. If an attacker compromises an administrator’s credentials at an arbitrary point in time, the probability that those credentials currently hold elevated privileges is low. The attacker must either wait for the administrator to request access (and use the session) or attempt to request access themselves (triggering approval workflows and alerting).

Accountability through logging ensures that all privileged access is recorded in sufficient detail for audit, investigation, and compliance. Logs must capture who accessed what, when, from where, and ideally what actions they performed during the session. For high-sensitivity access, session recording captures complete activity rather than just connection metadata. Logs must be protected from modification by the same administrators whose actions they record, requiring either segregated storage with different access controls or tamper-evident mechanisms.

Privileged Account Lifecycle

Privileged accounts progress through a lifecycle of provisioning, active use, periodic review, and eventual deprovisioning. Each phase requires specific controls to maintain security while enabling legitimate administrative work.

Provisioning creates the account and assigns initial permissions. For human administrative accounts, provisioning links to the identity lifecycle managed through Identity and Access Management. When a staff member requires administrative capabilities, the provisioning process should create a separate administrative account rather than elevating their standard account. This separation enables distinct security policies: the administrative account requires hardware tokens for authentication, accesses only from privileged access workstations, and faces more restrictive session policies.

Service account provisioning requires capturing the owning system or application, the responsible team, the specific permissions required, and the credentials storage mechanism. This information forms the basis for lifecycle management, as service accounts without clear ownership become orphaned over time. A service account registry, maintained in the configuration management database or as a dedicated inventory, tracks these attributes.

+------------------------------------------------------------------+
|                PRIVILEGED ACCOUNT LIFECYCLE                      |
+------------------------------------------------------------------+
|                                                                  |
|  +------------+     +------------+     +------------+            |
|  |            |     |            |     |            |            |
|  | PROVISION  +---->| ACTIVE USE +---->| REVIEW     +--+         |
|  |            |     |            |     |            |  |         |
|  +------------+     +------+-----+     +------+-----+  |         |
|                            |                  |        |         |
|  - Create account          |                  |        |         |
|  - Assign permissions      |           +------v-----+  |         |
|  - Vault credentials       |           |            |  |         |
|  - Document ownership      |           | MODIFY     |  |         |
|                            |           |            |  |         |
|                            |           +------+-----+  |         |
|                            |                  |        |         |
|                            |    +-------------+        |         |
|                            |    |                      |         |
|                            v    v                      |         |
|                     +------+----+------+               |         |
|                     |                  |               |         |
|                     | DEPROVISION      |<--------------+         |
|                     |                  |  (if no longer needed)  |
|                     +------------------+                         |
|                                                                  |
|  - Rotate credentials       - Verify necessity                   |
|  - Monitor usage            - Validate permissions               |
|  - Enforce JIT              - Update ownership                   |
|  - Record sessions          - Remediate excess                   |
|                                                                  |
+------------------------------------------------------------------+

Figure 2: Privileged account lifecycle phases

Active use is the operational phase where the account performs its intended function. Controls during this phase focus on authentication strength, session management, activity monitoring, and enforcement of the boundaries established during provisioning. For human administrators using just-in-time access, each usage episode involves requesting access, completing the approval workflow, performing the required work, and either explicitly releasing access or allowing automatic expiry.

Session policies for privileged accounts should enforce stricter controls than standard user sessions. Maximum session duration limits prevent indefinitely-active administrative sessions. Idle timeouts terminate abandoned sessions. Re-authentication requirements prevent session hijacking after an administrator steps away. These policies balance security against productivity, recognising that overly aggressive timeouts force repeated authentication and may drive administrators toward workarounds.

Periodic review validates that the account remains necessary, that permissions remain appropriate, and that ownership information is current. The procedures for conducting access reviews appear in Access Reviews and Recertification. For privileged accounts, review frequency should be higher than for standard accounts (quarterly rather than annually is common), and reviewers should have sufficient context to evaluate whether permissions remain justified.

Service account reviews face the challenge that the nominal owner may not understand what permissions the account actually uses. Effective review combines stated requirements (what permissions were originally requested) with observed usage (what permissions the account actually exercises) to identify and remove excess permissions. Reducing a service account’s permissions risks breaking functionality, so production changes require testing and rollback capability.

Deprovisioning removes the account when it is no longer required. For human administrators, deprovisioning triggers upon role change or departure. For service accounts, deprovisioning triggers when the dependent application is retired. The challenge for service accounts is detecting when they are no longer used, as no human departure signals the change. Monitoring for authentication attempts and API calls over an extended period (90 days is common) can identify dormant service accounts that may be candidates for deprovisioning.

Credential Vaulting

Credential vaulting stores privileged credentials in an encrypted repository rather than in human memory, configuration files, or spreadsheets. The vault provides secure storage, access control, audit logging, and often automated rotation. Users and systems retrieve credentials from the vault when needed rather than knowing them directly.

A credential vault stores secrets (passwords, API keys, certificates, SSH keys) encrypted at rest, controls access through authentication and authorisation rules, logs all access attempts, and may inject credentials into sessions or applications without revealing the actual secret to the requester. The distinction between retrieving a password (which the user then knows and could misuse) and connecting through a session where the password is injected (which the user never sees) is significant for high-sensitivity accounts.

Vault architecture determines security properties. A single vault becomes a high-value target and single point of failure. Distributed or replicated vaults improve availability but complicate consistency. Integration points (APIs, agents, plugins) expand the attack surface. The vault’s own administrative access requires careful management, as vault administrators can potentially access all stored secrets.

Password vaulting for human administrators replaces remembered or recorded passwords with vault-managed credentials. The administrator authenticates to the vault (with MFA), requests access to a target system, and either retrieves the current password or initiates a session where the vault injects the password. After use, the vault rotates the password so the previously-revealed credential is no longer valid.

Secrets management for applications and services provides credentials to automated systems through APIs, environment injection, or file-based secrets. An application starting up retrieves its database password from the vault rather than reading it from a configuration file. A CI/CD pipeline obtains deployment credentials at runtime rather than storing them in the pipeline configuration. This approach enables credential rotation without modifying application configurations and prevents credentials from appearing in version control.

+------------------------------------------------------------------+
|                   CREDENTIAL VAULT ARCHITECTURE                  |
+------------------------------------------------------------------+
|                                                                  |
|                        +------------------+                      |
|                        |                  |                      |
|                        |  CREDENTIAL      |                      |
|                        |  VAULT           |                      |
|                        |                  |                      |
|                        |  +------------+  |                      |
|                        |  | Encrypted  |  |                      |
|                        |  | Storage    |  |                      |
|                        |  +------------+  |                      |
|                        |                  |                      |
|                        |  +------------+  |                      |
|                        |  | Access     |  |                      |
|                        |  | Policies   |  |                      |
|                        |  +------------+  |                      |
|                        |                  |                      |
|                        |  +------------+  |                      |
|                        |  | Audit      |  |                      |
|                        |  | Logs       |  |                      |
|                        |  +------------+  |                      |
|                        |                  |                      |
|                        +--------+---------+                      |
|                                 |                                |
|         +-----------------------+------------------------+       |
|         |                       |                        |       |
|         v                       v                        v       |
|  +------+-------+      +--------+------+      +----------+----+  |
|  |              |      |               |      |               |  |
|  | Human Admin  |      | Application   |      | CI/CD         |  |
|  |              |      |               |      | Pipeline      |  |
|  | - Web UI     |      | - API call    |      |               |  |
|  | - CLI        |      | - Agent       |      | - API call    |  |
|  | - Session    |      | - Sidecar     |      | - Plugin      |  |
|  |   proxy      |      |               |      |               |  |
|  +--------------+      +---------------+      +---------------+  |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: Credential vault serving human administrators, applications, and automation

Credential rotation changes passwords, keys, or certificates on a scheduled or triggered basis. Automatic rotation eliminates passwords that persist indefinitely and limits the window during which a compromised credential remains valid. Rotation frequency depends on the credential’s risk exposure: high-privilege accounts rotating daily, standard service accounts rotating weekly or monthly, and API keys rotating on usage thresholds or calendar schedules.

Rotation requires coordination between the vault (which generates and stores the new credential) and the target system (which must accept the new credential). Failed rotation can break authentication, so rotation systems require monitoring, rollback capability, and clear alerting when rotation fails. Rotation of credentials used by multiple consumers (a shared service account password) requires either simultaneous update of all consumers or support for multiple valid credentials during a transition period.

Just-in-Time Access Implementation

Just-in-time (JIT) access transforms standing privileges into ephemeral access grants. The account exists without administrative permissions under normal conditions. When the administrator requires elevated access, they submit a request specifying the permission level needed and the duration. Approval (automatic based on policy or manual by a peer/manager) grants the permissions temporarily. When the time expires or the administrator explicitly releases access, permissions are revoked.

The JIT workflow involves several components: a request interface where administrators submit access requests, a policy engine that evaluates requests against rules, an approval mechanism for requests requiring human judgement, an access broker that provisions and deprovisions the actual permissions, and an audit system that records the complete sequence.

    Administrator          JIT Portal           Policy Engine        Target System
          |                    |                      |                    |
          |---(1) Request----->|                      |                    |
          |    elevated access |                      |                    |
          |                    |                      |                    |
          |                    |---(2) Evaluate------>|                    |
          |                    |    policy            |                    |
          |                    |                      |                    |
          |                    |<---(3) Approval------|                    |
          |                    |    decision          |                    |
          |                    |                      |                    |
          |                    |---(4) Provision-------------------------->|
          |                    |    permissions       |                    |
          |                    |                      |                    |
          |<---(5) Access------|                      |                    |
          |    granted         |                      |                    |
          |                    |                      |                    |
          |---(6) Perform administrative work----------------------------->|
          |                    |                      |                    |
          |                    |                      |       (7) Timer    |
          |                    |                      |           expires  |
          |                    |                      |                    |
          |                    |---(8) Revoke----------------------------->|
          |                    |    permissions       |                    |
          |                    |                      |                    |
          |<---(9) Access------|                      |                    |
          |    expired         |                      |                    |
          |                    |                      |                    |

Figure 4: Just-in-time access request and provision flow

Policy rules determine which requests require approval and which can be auto-approved based on context. A rule might auto-approve access to development environments during business hours while requiring manager approval for production access at any time. Rules might grant longer durations for certain roles or certain target systems. Rules should also prevent dangerous combinations, such as granting both “deploy to production” and “approve production deployments” to the same person simultaneously.

Access duration should be sufficient for realistic work sessions without being so long that permissions persist after the work is complete. Typical durations range from 1 hour for quick fixes to 8 hours for extended maintenance windows. Administrators can release access early when work is complete. Some implementations support extension requests for work that takes longer than anticipated, though extensions should require justification.

The implementation mechanism varies by target system. Cloud platforms (Azure, AWS, GCP) provide native JIT capabilities through their privilege management features. On-premises Active Directory implements JIT through temporary group membership, where the access broker adds the administrator to the privileged group and removes them upon expiry. Applications with their own access control implement JIT through API calls that modify the user’s role or permissions.

Session Recording and Monitoring

Session recording captures privileged session activity for audit, investigation, and compliance. Recordings provide evidence of what occurred during administrative sessions, enabling investigation of incidents, verification of compliance with procedures, and deterrence of malicious activity. Session monitoring extends recording to include real-time observation and alerting on suspicious patterns.

Recording mechanisms vary by session type. For graphical sessions (RDP, VNC), recording captures screen video and optionally keystroke injection, producing playable video files. For command-line sessions (SSH, PowerShell), recording captures command history and output, producing text logs or structured data. For database sessions, recording captures queries executed and results returned. For API access, logging captures requests and responses.

Recording generates substantial data. A 1080p RDP session recorded at 10 frames per second produces approximately 500MB per hour with efficient compression. Keystroke-only SSH logging produces perhaps 1MB per hour of active typing. Organisations must plan for storage requirements, retention periods, and retrieval mechanisms. Recording everything is infeasible for most; selective recording of high-sensitivity sessions focuses resources on the highest-risk access.

Privacy considerations affect session recording. Recordings of administrative sessions may capture incidental personal information (other users’ emails visible on screen while administering mail servers, for example). Data protection requirements may restrict who can access recordings, how long they are retained, and how they are secured. Recording policies should be disclosed to administrators and may require legal review in some jurisdictions.

Real-time monitoring adds alerts to recording. Suspicious patterns trigger immediate notification rather than waiting for post-hoc review. Examples include commands that match known attack patterns (credential dumping tools), access at unusual times, access to rarely-touched systems, or deviation from baseline administrator behaviour. Alert tuning prevents fatigue while catching genuine anomalies.

Recording coverage gaps

Session recording typically captures administrative tools (SSH clients, RDP sessions, administrative consoles) but may miss privileged actions performed through other channels. An administrator with database credentials could connect using a personal SQL client rather than the monitored jump server. Policy must reinforce technical controls by requiring use of monitored access paths.

Service Account Management

Service accounts present distinct management challenges because they authenticate programmatically, cannot complete interactive authentication challenges, and often accumulate permissions over time as integrations expand. Effective service account management requires inventory, ownership, permission minimisation, credential security, and monitoring.

Inventory catalogs all service accounts across the environment. Discovery mechanisms query directory services, cloud identity systems, and application configurations to find service account objects. The inventory captures each account’s name, owning application or service, responsible team, creation date, and documented purpose. Service accounts not appearing in the inventory represent unmanaged risk.

Ownership assignment associates each service account with a responsible individual or team. Ownership implies responsibility for reviewing whether the account remains necessary, validating that permissions remain appropriate, and responding to security events involving the account. Service accounts without clear ownership tend to persist indefinitely with unchanged credentials and accumulated permissions.

Permission minimisation reduces service account rights to the minimum required for function. Initial provisioning often grants broad permissions for convenience (“just make it work”), creating excess privilege that persists for the account’s lifetime. Permission analysis compares documented requirements against actual access patterns to identify unused permissions for removal.

Credential security applies vaulting and rotation to service account credentials. Credentials embedded in application configuration files, environment variables, or infrastructure-as-code templates present extraction risks. Migration to secrets management moves credentials into vaults where they can be rotated, accessed only by authorised systems, and logged for audit.

Monitoring tracks service account authentication patterns to detect anomalies. Baseline behaviour (which systems the account accesses, at what times, from which source addresses) enables detection of deviation. A service account that normally authenticates from a specific application server suddenly authenticating from an unknown IP address warrants investigation.

+------------------------------------------------------------------+
|                SERVICE ACCOUNT CREDENTIAL FLOW                   |
+------------------------------------------------------------------+
|                                                                  |
|  INSECURE PATTERN                 SECURE PATTERN                 |
|  (credentials in config)          (credentials from vault)       |
|                                                                  |
|  +----------------+               +----------------+             |
|  | Application    |               | Application    |             |
|  |                |               |                |             |
|  | config.yaml:   |               | On startup:    |             |
|  |  db_password:  |               |  1. Auth to    |             |
|  |   "P@ssw0rd"   |               |     vault      |             |
|  |                |               |  2. Retrieve   |             |
|  +-------+--------+               |     secret     |             |
|          |                        |  3. Connect    |             |
|          | Password               |                |             |
|          | in memory,             +-------+--------+             |
|          | on disk,                       |                      |
|          | in version                     | Secret retrieved     |
|          | control                        | at runtime only      |
|          |                                |                      |
|          v                                v                      |
|  +-------+--------+               +-------+--------+             |
|  | Database       |               | Vault          |             |
|  +----------------+               +-------+--------+             |
|                                           |                      |
|                                           | Credential           |
|                                           | injection            |
|                                           |                      |
|                                           v                      |
|                                   +-------+--------+             |
|                                   | Database       |             |
|                                   +----------------+             |
|                                                                  |
|  RISKS:                           BENEFITS:                      |
|  - Credential exposure            - Credential rotation          |
|  - No rotation                    - No disk exposure             |
|  - No audit trail                 - Access audit logging         |
|  - Credential sprawl              - Centralised management       |
|                                                                  |
+------------------------------------------------------------------+

Figure 5: Insecure vs secure service account credential patterns

Cloud Privileged Access

Cloud platforms provide native privileged access management capabilities that differ from on-premises patterns. Understanding these differences enables effective PAM architecture for cloud and hybrid environments.

Role-based access in cloud platforms uses roles as the primary authorisation mechanism rather than group membership. A user assumes a role to perform specific actions, and role policies define permitted actions on specific resources. Role assumption can require additional authentication factors, be time-limited, or be conditional on context (source IP, time of day, device posture).

Just-in-time capabilities are often built into cloud platforms. Azure Privileged Identity Management (PIM) provides native JIT for Azure AD roles and Azure resource roles. AWS Identity Center supports temporary permission set assignment. GCP supports temporary IAM bindings. These native capabilities integrate with cloud audit logging without requiring additional infrastructure.

Service principal and workload identity models replace traditional service accounts with identity federation for cloud workloads. A container running in Kubernetes obtains credentials from its assigned service account via the projected token volume; an Azure VM obtains credentials via the managed identity endpoint; an AWS Lambda function obtains credentials via the execution role. These patterns eliminate static credentials in favour of short-lived tokens bound to the workload’s identity.

Cross-account and cross-tenant access presents privileged access challenges when organisations manage multiple cloud accounts or tenants. A central security team may require administrative access across all accounts, while operational teams require access only to their specific accounts. Federation patterns enable central identity with delegated permissions, while audit consolidation enables security monitoring across the boundary.

Cloud-native PAM first

Before deploying a third-party PAM solution for cloud resources, evaluate whether cloud-native capabilities meet requirements. Azure PIM, AWS Identity Center, and GCP IAM Conditions provide JIT, approval workflows, and audit logging for cloud resources without additional tooling or cost. Third-party solutions add value for unified management across multiple cloud platforms or for hybrid environments spanning cloud and on-premises.

PAM Architecture Patterns

PAM solutions implement access controls through several architectural patterns: agent-based, agentless, and gateway-based. Each pattern presents different trade-offs for deployment complexity, coverage, and security properties.

Agent-based architectures deploy software agents on managed endpoints. The agent intercepts authentication, injects credentials, records sessions, and enforces policies. Agent deployment provides deep integration with target systems, enabling fine-grained control over sessions. However, agent deployment requires installation on each managed system, ongoing agent maintenance, and compatibility testing with each operating system and version. Agent compromise would expose the privileged access mechanism itself.

Agentless architectures manage privileged access without deploying agents on target systems. The PAM solution connects to target systems using their native management interfaces (WinRM for Windows, SSH for Linux, APIs for cloud platforms) to rotate credentials, retrieve session logs, and configure policies. Agentless deployment reduces footprint on target systems but may provide less granular session control and depends on the capabilities of native management interfaces.

Gateway-based architectures route privileged sessions through a controlled intermediary. Administrators connect to the PAM gateway rather than directly to target systems. The gateway authenticates the administrator, authorises the session, injects credentials toward the target, and records session activity. This approach centralises session recording and credential injection without requiring agents on target systems. However, the gateway becomes a critical path component; its unavailability prevents privileged access to all managed systems.

+------------------------------------------------------------------+
|                   PAM ARCHITECTURE PATTERNS                      |
+------------------------------------------------------------------+
|                                                                  |
|  AGENT-BASED                                                     |
|  +----------+     +----------+     +----------+                  |
|  | Admin    |---->| PAM      |---->| Target   |                  |
|  |          |     | Server   |     | + Agent  |                  |
|  +----------+     +----------+     +----------+                  |
|                        |                 |                       |
|                        +--> Agent manages session locally        |
|                                                                  |
|  AGENTLESS                                                       |
|  +----------+     +----------+     +----------+                  |
|  | Admin    |---->| PAM      |---->| Target   |                  |
|  |          |     | Server   |     | (native  |                  |
|  +----------+     +----+-----+     |  mgmt)   |                  |
|                        |           +----------+                  |
|                        |                                         |
|                        +--> Remote management via SSH/WinRM/API  |
|                                                                  |
|  GATEWAY-BASED                                                   |
|  +----------+     +----------+     +----------+                  |
|  | Admin    |---->| PAM      |---->| Target   |                  |
|  |          |     | Gateway  |     |          |                  |
|  +----------+     +----+-----+     +----------+                  |
|                        |                                         |
|                        +--> All sessions route through gateway   |
|                        +--> Credentials never reach admin        |
|                                                                  |
+------------------------------------------------------------------+

Figure 6: PAM architecture patterns showing agent-based, agentless, and gateway-based approaches

Hybrid architectures combine patterns for different target system types. Gateway-based access for high-sensitivity servers, agentless management for cloud resources via native APIs, and agent-based control for specialised applications each address different requirements. Most enterprise PAM deployments use hybrid approaches to cover diverse target environments.

Implementation Considerations

PAM implementation complexity and resource requirements vary substantially by organisational context. A pragmatic approach prioritises controls based on risk and available capacity.

For organisations with minimal IT capacity, PAM implementation begins with fundamentals that require no specialised tooling. Separate administrative accounts for each administrator prevent credential exposure through routine activities. A password manager (Bitwarden, 1Password, or the self-hosted Vaultwarden) provides basic vaulting with access controls and audit logging. Documenting which accounts exist, who owns them, and what credentials they use creates the inventory foundation. These steps require policy enforcement and discipline rather than significant technology investment.

The next tier introduces just-in-time access for critical accounts. Cloud-native JIT capabilities (Azure PIM, AWS IAM) provide this for cloud resources at no additional cost. For on-premises Active Directory, PowerShell scripts can add and remove group membership on a schedule, providing basic JIT. These approaches lack the workflow and approval features of full PAM solutions but significantly reduce standing privilege exposure.

For organisations with established IT functions, full PAM platform deployment provides comprehensive coverage. Solution selection depends on environment composition (cloud-heavy versus on-premises-heavy), integration requirements (existing identity systems, SIEM), and budget. Open source options reduce licensing costs but require more implementation effort. Managed services reduce operational burden but increase ongoing costs and may present data residency considerations.

Session recording adds accountability for high-sensitivity access. Full session recording requires substantial storage and review capacity. A phased approach records only the most critical systems initially (domain controllers, production databases, security infrastructure), expanding coverage as operational capacity develops.

Organisational Context	Recommended Approach	Estimated Effort
Single IT person, limited budget	Separate admin accounts, password manager vaulting, documented inventory	2-4 weeks part-time
Small IT team, mixed environment	Above plus cloud-native JIT, scripted on-premises JIT for critical systems	1-2 months
Established IT, compliance requirements	Full PAM platform, session recording for critical systems, formal access reviews	3-6 months initial deployment
Large or federated organisation	Enterprise PAM with multi-region deployment, integration with SIEM and IdP, comprehensive session recording	6-12 months programme

Technology Options

PAM solutions range from open source tools requiring self-hosting and operational investment to fully managed commercial services. The selection depends on functional requirements, operational capacity, budget, and data residency considerations.

Open source and self-hosted options provide full control over data and implementation but require deployment and maintenance capacity.

HashiCorp Vault provides secrets management with dynamic credentials, credential rotation, and API-driven access. It excels at application secrets management and integrates well with cloud platforms and container orchestration. Vault does not provide session recording or interactive session management natively; those capabilities require complementary tools. Vault is open source (Mozilla Public License 2.0), with commercial enterprise features available.

Teleport provides secure access to infrastructure (SSH, Kubernetes, databases, web applications) through a gateway-based architecture. Session recording, access requests with approval workflows, and certificate-based authentication replace traditional credential management. Teleport is open source (Apache 2.0), with commercial enterprise features.

Boundary from HashiCorp provides identity-based access to resources without exposing network addresses or requiring VPN. It focuses on access brokering rather than credential vaulting, complementing Vault for secrets management. Boundary is open source (Mozilla Public License 2.0).

For password vaulting specifically, Passbolt (AGPL) and Vaultwarden (a community implementation compatible with Bitwarden clients, GPL) provide team password management with sharing, access controls, and audit logging. These serve as entry-level PAM components for organisations beginning their privileged access journey.

Commercial options provide integrated capabilities with reduced operational overhead.

CyberArk Privileged Access Manager provides comprehensive PAM with credential vaulting, session recording, JIT access, and extensive integrations. It suits large enterprises with complex requirements and budget for both licensing and operational staff.

Delinea (formerly Thycotic and Centrify) Secret Server and Privilege Manager provide credential vaulting and endpoint privilege management. The product line suits mid-market organisations seeking PAM without CyberArk’s complexity.

BeyondTrust provides PAM alongside endpoint privilege management, addressing both privileged account security and reducing standing privilege on workstations.

For cloud-native organisations, cloud platform capabilities may suffice. Azure Privileged Identity Management provides JIT access, approval workflows, and access reviews for Azure AD and Azure resources. AWS Identity Center provides similar capabilities for AWS. These native options integrate seamlessly with their respective platforms but do not extend to other platforms or on-premises systems.

Data residency for PAM

PAM systems store credentials and session recordings, both highly sensitive data categories. Commercial SaaS PAM offerings may store this data in regions that do not align with organisational data residency requirements. Self-hosted options (open source or commercial on-premises) provide control over data location. Evaluate data residency implications before selecting a PAM platform, particularly for organisations subject to data protection regulations or operating in contexts where cloud provider data access presents risk.