Privileged Access Management Architecture (Part 1): Introduction & Capabilities

Introduction

You're a security, solution, domain, or program architect who's just been handed a PAM project. Now what? This series answers that question based on my experience. I'll walk through how to structure PAM capabilities, define functional requirements, document the current state, build a reference architecture, run vendor selection, capture key decisions, and produce the solution architecture and design for your chosen PAM platform.

Business and Technical Capability Models

Capability models are useful for two reasons: they describe what the market offers, and they expose gaps in what you have today. The capabilities themselves become the categories under which you write functional requirements. Working through them forces you to understand how vendors differ.

The exact domains, subdomains, and capability layers will vary by company and by model. Some organisations maintain business capability models that map onto technical capability models. What matters is that you list all PAM capabilities along with their associated Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs), so you can see where your current capabilities are strong and, more importantly, where the gaps lie.

PAM sits within workforce identity, which sits within the IAM subdomain of the broader security domain. In practice, this means PAM's capabilities live alongside IGA, authentication, authorisation, and ITDR.

IAM Subdomain of the Security Domain

Below is a shortened workforce identity capability model that sits inside the IAM subdomain. The layering is flexible — for example, you might treat "vaulting credentials" as part of "privileged session brokering" by adding another L3 layer. The SBBs listed are illustrative; substitute your own.

A note on placement: CIEM and ITDR are shown here as L2 capabilities under PAM in line with how the current market bundles them. In a stricter capability model they often sit as peers of PAM under the IAM subdomain, because ITDR covers identity infrastructure broadly (AD, IdP, federation — not just privileged accounts) and CIEM applies to all cloud IAM identities regardless of whether they're privileged. Apply whichever view matches how your organisation governs these disciplines.

Basic PAM Capabilities

The basic PAM capabilities — commonly grouped as PASM (Privileged Account and Session Management), PEDM (Privilege Elevation and Delegation Management) and RPAM (Remote Privileged Access Management) — are:

• Vaulting Credentials. Password safe functionality that allows privileged users to check out credentials from a vault. Credentials can be rotated automatically after use or on a schedule. Includes SSH key management, application-to-application password management (AAPM), and break-glass workflows. Examples: CyberArk Privileged Access Manager, Delinea Secret Server, BeyondTrust Password Safe, One Identity Safeguard.

• Privileged Session Brokering. Allows privileged users to log into a target system without entering — or even knowing — the credential. The PAM solution acts as a broker between the user and the target, using the vaulted credential to authenticate on the user's behalf. The credential never touches the user's endpoint. Examples: CyberArk PSM, BeyondTrust PRA, Delinea Privileged Behavior Analytics + Connection Manager, Teleport, HashiCorp Boundary.

• Privileged Account Discovery. Continuously discovers privileged accounts across directories, OSes, cloud control planes, databases, network devices, SaaS apps and CI/CD systems, classifies their risk, and onboards them into managed control. Discovery is the prerequisite for everything else — you can't vault or rotate what you don't know exists. Examples: CyberArk DNA, BeyondTrust Discovery, Delinea Account Lifecycle Manager.

• Privileged Session Recording and Monitoring. Records and monitors privileged sessions, either via screenshots or full session recording to a secure store. Modern implementations add OCR/command extraction for searchable forensics and the ability to terminate sessions in real time. Examples: CyberArk PSM, BeyondTrust PRA, Delinea Connection Manager.

• Privilege Elevation and Delegation Management (PEDM). Allows privileged users to run specific commands or applications with elevated rights without granting full administrator access to the host. Where vaulting is "all or nothing" admin via a shared account, PEDM gives a non-admin user just the specific elevated permission needed, on their own account, for a specific task. Typically implemented through an agent that intercepts and authorises elevation requests. Examples: BeyondTrust Privilege Management for Windows/Mac/Unix-Linux, CyberArk Endpoint Privilege Manager, Delinea Privilege Manager.

• Remote Privileged Access / VPNless (RPAM). A newer category that replaces the legacy "VPN plus jump host" pattern with identity-based, brokered, agentless, browser-rendered access for employees, third parties, vendors and OT operators. Sessions never place the user on the corporate network.

  RPAM is where PAM meets Zero Trust Architecture. NIST SP 800-207's tenets — per-session access decisions, dynamic policy evaluation, no implicit trust based on network location — map directly onto how RPAM brokers privileged sessions. ZTNA gives identity-aware application access; RPAM is the privileged superset that adds credential injection, session recording, per-session MFA and command control to that ZTNA pattern. If you're already pursuing a Zero Trust roadmap, RPAM is usually the easiest part of PAM to justify because it retires inbound firewall rules, removes the VPN attack surface for admin paths, and produces audit-ready session evidence in one go. Examples: BeyondTrust Privileged Remote Access, CyberArk Secure Browser, Zscaler PRA, Delinea Remote Access Service, Cyolo, StrongDM, Teleport.

Assessing Your Current State

A common reason PAM projects stall is that the team can't articulate what's already in place. Before going to market, run your current tooling against the basic capabilities list above and be honest about coverage. The patterns I see most often:

• A password manager treated as a vault. Tools like LastPass, 1Password Business or KeePass solve credential storage for humans but lack session brokering, account discovery, session recording and credential rotation against target systems. They're a useful stopgap, not a PAM solution.
• An IdP's privileged-role feature treated as PAM. Most enterprise IdPs offer some form of time-bound privileged role assignment for their own platform — typically for cloud admin roles in the same vendor's stack. These cover one slice of just-in-time access but rarely vault credentials, broker sessions, discover accounts, record sessions, or extend to anything outside the vendor's own ecosystem (Windows/Linux servers, databases, network devices, OT, third-party SaaS).
• Bespoke scripts and a shared spreadsheet. Still surprisingly common for service accounts and infrastructure credentials. The discovery, rotation and audit gaps are usually the easiest part of the business case.

Document each existing tool against each L2 capability and mark coverage as full, partial or none. The gaps you find are the foundation of your functional requirements in Part 2.

Advanced PAM Capabilities

• Just-in-Time Access (JIT) and Zero Standing Privilege (ZSP). JIT grants privileged permissions only when needed, for a bounded duration, with automatic revocation. ZSP is the end-state where no identity holds permanent privileged rights — every elevation is provisioned on demand and torn down immediately. Three implementation patterns dominate: broker accounts with vaulted credentials, ephemeral accounts created on the fly, and temporary elevation of an existing identity. This is the architectural shift driving most of the PAM market right now.
• Cloud Infrastructure Entitlement Management (CIEM). Discovers, normalises and right-sizes the tens of thousands of fine-grained permissions across AWS, Azure and GCP for both human and machine identities. Tackles the explosion of cloud IAM that traditional PAM tools struggle to model. Industry research consistently finds that the vast majority of cloud entitlements granted to accounts are never exercised, which is the core problem CIEM exists to solve.
• Privileged User Behaviour Analytics (PUBA). Applies behavioural analytics to privileged sessions to detect anomalies — unusual access times, commands, or data volumes — that may indicate compromise or insider threat. The bridge between PAM (preventive control) and ITDR (detection and response).
• Identity Threat Detection and Response (ITDR). Monitors identity infrastructure — AD, your IdP, the PAM solution itself, federation — for attack patterns such as Golden Ticket, DCSync, AS-REP roast, OAuth consent abuse and MFA fatigue, and automates response. Increasingly viewed as a peer of PAM rather than an add-on.
• Secrets Management. Stores and rotates non-human credentials: API keys, service account passwords, certificates, and tokens used by applications and pipelines. Heavily overlaps with developer tooling and CI/CD, and has its own scale and SLA profile distinct from human-PAM. The smart move is usually a separate workstream owned jointly with platform engineering.

Market Trends Shaping PAM in 2026

The capability set above is stable enough to plan against, but the centre of gravity in the PAM market is shifting fast. A few trends worth understanding before you make architectural commitments:

From vault-centric to identity-centric PAM. For two decades, PAM has meant "vault the password and broker the session." That pattern is being replaced by JIT and ZSP, where the credential either doesn't exist when it isn't being used, or exists only as a short-lived token issued at the moment of access. If you're scoping a programme today, treat the vault as a stepping stone rather than the destination — and sequence vault adoption with an explicit path to JIT for at least your Tier 0 accounts.

Machine identities are the new privileged users. Industry research consistently puts the ratio of non-human to human identities in modern environments at somewhere between 40:1 and 50:1. Service accounts, workloads, CI/CD pipelines, OAuth apps and now AI agents collectively hold far more privilege than your administrators do, and they're rarely governed with the same rigour. Treat machine identity as a peer programme to human PAM, not a sub-capability — the ownership, lifecycle, recertification and right-sizing problems are the same, but the scale, SLA and developer-experience constraints are very different.

Secretless authentication is replacing rotation. Workload identity federation via OIDC — for example, a CI/CD job exchanging a signed JWT for short-lived cloud credentials — is becoming the default for pipeline access. Equivalent patterns exist across the major cloud and data platforms. Where you used to rotate long-lived keys, you increasingly don't issue them at all. Public research on secrets sprawl consistently finds that the majority of leaked credentials remain valid years after exposure, which is the empirical case for going secretless rather than relying on rotation discipline.

Zero Trust is reshaping privileged remote access. As covered in the RPAM bullet above, the privileged VPN is on its way out. Organisations on a ZTA journey can usually justify RPAM faster than other PAM capabilities because the VPN-replacement business case is well understood and the audit benefits are immediate. Where a generalist ZTNA solution is already in place, the RPAM question becomes whether to extend it to privileged paths or layer dedicated RPAM tooling on top — most regulated organisations end up doing the latter for credential injection, session recording and command control.

Convergence with IGA, CIEM and ITDR. The framing is shifting from "PAM market" to "identity security platform," with PAM as one capability inside a broader stack alongside IGA, CIEM and ITDR. For an architect, the practical question is whether to consume converged platforms or best-of-breed point solutions integrated via APIs — there's no single right answer, but the convergence trend means the boundary between PAM and adjacent disciplines will keep moving. Plan your capability model to accommodate that, and avoid hard architectural seams between PAM and the disciplines it's converging with.

Vendor consolidation is reshaping the buy. The PAM market has seen unusually heavy M&A activity over the past two years, with several leading vendors absorbing or being absorbed by larger security and infrastructure players. If you're going to market in the next 12–18 months, expect roadmap, naming and pricing shifts from at least some of the incumbents. Build integration risk into your vendor selection criteria, and weight roadmap stability alongside current capability coverage.

Regulation is a tailwind. In Europe, NIS2 (transposition deadline October 2024) and DORA (applicable January 2025) both require privileged access controls, MFA, session monitoring and audit trails. The SEC cyber-disclosure rules turn material incidents into board-level events on a four-business-day clock. None of these mandate a specific PAM product, but all of them make the privileged-access control set very hard to argue down.

Underpinning Capabilities for PAM

PAM isn't an isolated solution. You're building on top of existing IAM architecture, so it's worth understanding how that architecture will shape — and be shaped by — your PAM solution:

• IGA. Drives the lifecycle of privileged accounts and their entitlements. Your IGA solution should be the system of record for who is entitled to what privileged access, with PAM enforcing it.
• SSO. Privileged users authenticate to the PAM solution via your enterprise IdP. This keeps the privileged authentication experience consistent and ensures MFA, conditional access, and session policies all apply.
• MFA. Step-up authentication for privileged actions is a baseline expectation. Decide whether MFA is enforced by the IdP at SSO time, by the PAM solution at session brokering time, or both.
• Device compliance during SSO. Privileged access from a non-compliant or unmanaged endpoint undermines every other control on this list. Your IdP's conditional access policies should evaluate device posture — managed status, disk encryption, OS patch level, EDR health, jailbreak/root detection — as part of the SSO decision flow for privileged sessions. In practice this means the PAM solution sits behind conditional access policies that are strictly tighter than the workforce baseline: typically requiring a managed device, phishing-resistant MFA, and a compliant posture signal before the IdP will issue a token usable against the PAM application.
• MDM / MAM. Mobile device management and mobile application management are often treated as workforce-productivity concerns, but they become a PAM dependency in two specific cases. First, some PAM solutions (CyberArk's mobile app being the most common example) use a managed mobile device for offline or out-of-band credential retrieval and approval workflows — in which case the mobile estate becomes part of your privileged path and needs the same posture and compliance controls as administrative workstations. Second, where administrators legitimately need privileged access from mobile devices, MAM application-protection policies (containerisation, copy/paste restrictions, conditional launch based on device posture) become the control that keeps credentials and session content from leaking into personal apps. Decide early whether mobile is a supported privileged-access channel; if it is, the MDM/MAM controls need designing in, not bolted on.
• SIEM. PAM produces some of the most security-relevant telemetry in the estate. Session logs, vault access events, and elevation requests all need to flow to your SIEM for correlation, alerting, and forensic use.

References