Modern PAM vs Traditional PAM: How to Decide What Replaces Your Vault

Many organisations are now asking whether to renew, extend or replace a PAM suite that was designed for human administrators logging on to servers, while most of their privilege has moved into cloud roles, pipelines and service identities. Traditional PAM is the vault-and-session model: privileged accounts exist permanently, their passwords and keys sit in an encrypted vault, and people reach targets through a recorded gateway. Modern PAM is the model built around removing privilege between uses: just-in-time (JIT) grants, zero standing privilege (ZSP), short-lived credentials and coverage for machines and AI agents. This guide treats the choice as a programme and replacement decision, not a feature list: threat model, coverage of non-human identities (NHIs), failure modes, a worked migration scenario and a decision checklist. It is for PAM owners, identity architects and security leaders. How a vault and a JIT grant work as mechanisms is covered in the Credential Vaulting vs Just-in-Time Elevation guide; this page does not repeat it.

Key takeaways

• The two models protect different things. Traditional PAM protects the secret and watches the session; modern PAM removes the privilege itself between uses and issues credentials that expire on their own.
• Machines decide the outcome. Service accounts, CI/CD identities, workloads and agents call APIs and have no interactive session to broker, so a programme that only records human sessions leaves most privileged activity outside PAM.
• Replacement is rarely total. Accounts that must exist permanently (local administrators, network devices, legacy applications, break-glass) still need a vault and rotation; the question is how much of the estate can move to JIT and federation.
• Both concentrate risk. A vault holds the keys to most privileged accounts; a JIT broker or identity provider can grant any role it governs. Either one is tier zero and needs its own controls.
• Measure standing privilege, not product coverage. The best evidence of progress is fewer permanent privileged assignments and fewer long-lived secrets, for people and machines, not the number of accounts onboarded to a vault.

The short answer

Choose by where your privilege lives. If most privileged work happens on Windows and Linux servers, databases, hypervisors and network devices reached interactively by administrators, the vault-and-session model still does most of the work and should be kept and tightened. If most privilege is held in cloud IAM roles, Kubernetes, SaaS admin roles, pipelines and service identities, a vault with session recording covers a shrinking slice, and the programme should lead with JIT grants, workload identity federation and short-lived credentials. Most estates have both, so the realistic decision is a target split with a migration path, not a like-for-like swap of one product for another.

Microsoft's privileged access strategy says a PIM or PAM solution alone is not sufficient: limit privileged actions to a few authorised pathways, then protect and monitor them. Treat the choice as a question about which pathways you allow.

What each model is

Traditional PAM: vault and session

The privileged account is permanent. A discovery job finds administrator, root and service accounts; the vault takes custody of their passwords and SSH keys; a rotation engine changes them on a schedule or after use; and administrators check them out or, better, connect through a session broker that injects the credential so they never see it. The broker records video, keystrokes or commands, and can end a session live. Approval workflows sit on checkout. NIST SP 800-53 AC-6(9) asks organisations to log the use of privileged functions, and session recording meets it for interactive work. Architecturally: a vault cluster, session gateways near the targets and connectors using a reconcile account.

Modern PAM: remove the privilege, shorten the credential

The privilege is not permanent. A person or workload is eligible for a role and activates it for a bounded time, with MFA, justification or approval, after which it is removed automatically. NCSC describes this as using a standing credential only to request access, then receiving a temporary credential that works for a short window, which limits the damage a stolen credential can do. NIST SP 800-53 AC-2(6), dynamic privilege management, expresses the same idea. For machines, modern PAM means credentials that are issued at runtime and expire: AWS temporary security credentials are generated dynamically when requested and cannot be reused once expired, GitHub Actions OIDC tokens are valid for a single job, and SPIFFE issues short-lived cryptographic identity documents (SVIDs) through a workload API. The architecture is a policy and approval service tied to the identity provider and cloud control planes, plus federation trust for workloads, with the platforms' own audit logs as the record. Platform detail is in the JIT Access Guide and the Workload Identity Federation Guide.

Where "extended PAM" fits

Suites marketed as extended or next-generation PAM usually add JIT elevation, cloud entitlement analysis, secrets management for applications and endpoint privilege management to a traditional vault. That is packaging, not a third model: judge each capability on whether it removes standing privilege or only protects it.

Side-by-side comparison

Threat model for each

Traditional PAM

• Defends well against: shared and unrotated passwords, administrators copying credentials to their laptops, unattributed sessions, and insiders acting without a recording. Rotation after checkout means a credential an administrator saw stops working.
• Weak against: standing privilege itself. A vaulted domain administrator account is still a domain administrator account every hour of the day, usable by anyone who reaches it around the gateway, through a hard-coded copy, or through the vault. Attackers use valid domain accounts (ATT&CK T1078.002) and credentials stored in files and scripts (T1552.001) precisely because these survive vaulting.
• Concentration risk: Microsoft's intermediaries guidance notes that PIM and PAM solutions typically store the credentials for most or all privileged roles in an organisation, often on premises or on IaaS virtual machines reachable by one compromised credential over VPN. It also warns that PAM does not reliably mitigate a compromised administrator device. See the PAM vault compromise playbook.

Modern PAM

• Defends well against: stolen credentials that would otherwise grant privilege indefinitely, dormant administrative assignments and long-lived machine keys.
• Weak against: an attacker who controls an eligible identity and can satisfy activation. If activation needs only the same MFA the attacker has already phished or fatigued, JIT adds a delay, not a barrier. Account manipulation (T1098), such as creating a new permanent administrator or adding eligibility, defeats the model unless those changes are themselves governed and alerted on.
• Concentration risk: the identity provider and the JIT broker can grant any role they govern. Microsoft notes that Entra PIM unlocks privileges already assigned to an account rather than storing credentials, which removes the credential theft path, but a poorly designed workflow can still allow escalation. In the cloud, abuse of cloud accounts (T1078.004) and application access tokens (T1550.001) moves the attack to the identity layer.

Coverage of machines and AI agents

This is usually where the replacement decision is won or lost. The OWASP Non-Human Identities Top 10 lists NHI5:2025 Overprivileged NHI and NHI7:2025 Long-Lived Secrets among the main risks. The table maps common machine privilege to the model that fits it.

Platform support is moving. As of November 2026 Microsoft documents that PIM roles can be assigned to service principals and managed identities, and Google Cloud Privileged Access Manager accepts workload identity federation and agent identities as principals and lets service accounts self-elevate. Agent-specific patterns are in the Credential Vaulting for AI Agents Guide; the agent design view of privilege is in the Agent Goal Hijacking vs Tool Misuse vs Privilege Compromise guide.

Failure modes

• Vaulted but still standing: every domain and cloud administrator account onboarded to the vault, none removed. Coverage reports look complete while the attack surface is unchanged.
• Gateway that can be skipped: targets accept privileged logons from anywhere, so recordings cover only administrators who chose the gateway. NIST SP 800-53 SC-7(15) asks for networked privileged access to go through a dedicated, managed interface.
• Copies outside the vault: scripts, pipeline variables and configuration files hold the same credentials the vault rotates, or the vault's own administrative credentials. In the Uber breach the attacker claimed to have found a PowerShell script with hard-coded administrator credentials on an internal share, a claim Uber did not confirm, and Uber rotated keys to many internal services afterwards.
• Permanent eligibility, rubber-stamp approval: JIT deployed with self-approval, long activation windows and eligibility for everyone in the team, so the model adds a click and no scrutiny.
• Federation with loose trust: a workload identity trust that accepts any branch or any repository in an organisation turns a short-lived token into an easy path for anyone who can edit a workflow.
• Break-glass forgotten in the redesign: moving all administration behind an identity provider without an emergency path that works when the provider or the broker is down. See the Break-Glass Account Guide.

Controls each model needs

Decision guidance

• Keep traditional PAM at the centre when: most privileged targets are on premises or on virtual machines reached by SSH, RDP or database clients; auditors or regulators expect session recordings; you run network devices, OT or appliances that cannot federate.
• Lead with modern PAM when: most administrative power is in cloud IAM, Kubernetes and SaaS roles; pipelines and workloads hold more privilege than people; the existing vault mostly stores cloud access keys that could be replaced by federation.
• Smaller organisations: the cloud platforms' own JIT features (such as Microsoft Entra PIM and Google Cloud Privileged Access Manager), a password vault for the remaining shared accounts and workload federation for pipelines may cover the need without a full suite. See the PAM vs PIM guide for where those features stop.
• Large and regulated organisations: expect to run both for years, with one approval policy, one break-glass process and one audit view.
• Before replacing a suite: count what the vault protects by category. Mostly cloud keys and service passwords means a redesign; mostly interactive admin accounts on targets that cannot federate means replacement changes little.

Buying criteria for each category are in the PAM Buyer's Guide and the Cloud PAM and Just in Time Access buyer's guide; the gateway architecture choice is in the Agent-Based vs Agentless PAM guide.

Worked scenario: a hybrid estate deciding at renewal

A financial services firm runs a self-hosted PAM suite with about 4,000 vaulted accounts and a renewal due in a year. An inventory by category finds roughly a third are cloud access keys and pipeline secrets, a third are Windows and Linux service accounts, a fifth are interactive administrator accounts on servers and databases, and the rest are network device and appliance accounts. Cloud administrators hold permanent owner roles in about 40 accounts and subscriptions, which the vault does not touch.

1. Cloud roles first: the team turns permanent cloud administrator assignments into eligible ones with the platforms' native JIT, maximum activation of a few hours, approval for owner-level roles and alerts on any permanent assignment. This removes more standing privilege than the whole vault did.
2. Pipeline keys next: pipelines move to OIDC federation with trust conditions on repository, branch and protected environment. The corresponding vaulted keys are disabled, watched for use for 30 days, then deleted.
3. Service accounts stay vaulted: rotation continues while owners move what they can to managed identities.
4. Interactive server access stays brokered: target firewalls now accept privileged logons only from the gateway.
5. Renewal decision: with half the vault emptied, the firm renews a smaller vault-and-session footprint and funds JIT and federation from the saving.

Migration path

1. Inventory by privilege, not by product: list every privileged human and machine identity, its permanent rights and where its credentials live, including copies outside the vault. The Privileged Access Management Guide lists the categories to include.
2. Classify each estate: can it federate, can it support time-bound role grants, or does it need a permanent account? That decides the model per estate.
3. Pilot JIT on one platform: start with the cloud directory or one cloud provider, in report mode if available, with a small group of administrators. Measure activation time and approval latency before widening.
4. Convert permanent to eligible in rings: lowest-risk teams first, then platform administrators, then the highest roles. Keep a named break-glass set permanent, monitored and tested.
5. Retire machine secrets as federation replaces them: disable before deleting, watch for failed authentication, and keep the old credential recoverable until the watch period ends.
6. Roll back safely: if JIT blocks critical work, lengthen the activation window rather than restoring permanent assignments, and log each exception with an owner and expiry.

Detection and measurement

• Monitor: privileged role assignments created outside the JIT workflow; changes to eligibility, approval policy and maximum durations; direct logons to targets that should only accept the gateway; use of disabled or retired machine credentials; vault administrative actions and bulk checkouts.
• Standing privilege count: permanent privileged assignments, human and machine, trended monthly. The target is the break-glass set and accounts with a documented reason.
• Long-lived machine secrets: number and share of privileged machine identities still using static keys or passwords rather than federation or short-lived tokens.
• Grant attribution: share of privileged actions in cloud audit logs that map to a JIT grant or a brokered session.
• Median activation duration and approval time: long durations show over-generous defaults; long approval times predict workarounds.

Board-level reporting on these measures is covered in PAM KPIs and KRIs to Report to the Board.

Framework mapping

Decision checklist

• Have you counted what the current vault protects by category (cloud keys, service accounts, interactive admin, devices)?
• How many privileged assignments, human and machine, are permanent today, and which platforms can make them eligible instead?
• Which estates cannot federate or support time-bound grants, and will therefore keep a vault and gateway?
• Does activation need a factor an attacker with the user's password and MFA prompt cannot satisfy, and is approval required for the highest roles?
• Are workload trust conditions bound to specific repositories, branches, environments or service accounts?
• Is there one break-glass process that works if the identity provider, the broker or the vault is unavailable?

Practitioner checklist

• Inventory privileged human and machine identities by permanent rights and credential location, including copies outside the vault.
• Convert permanent cloud and directory administrator assignments to eligible, time-bound assignments, keeping a small monitored break-glass set.
• Replace stored cloud keys in pipelines with OIDC or workload identity federation bound to tight claim conditions.
• Keep vaulting, rotation and brokered sessions for accounts that must stay permanent, and block direct privileged logons around the gateway.
• Require approval and a ticket for the highest roles, and a second person for business-critical workflows.
• Alert on privileged assignments created outside the JIT path and on any change to eligibility or approval policy.
• Give AI agents per-task, scoped and time-bound privilege, with human approval for high-impact tool calls.
• Treat the vault, the broker and the identity provider as tier zero and test their compromise playbooks.
• Report standing privilege and long-lived machine secrets monthly, and shrink the vault only after the replacement path is proven.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: SP 800-207 Zero Trust Architecture
• NCSC: Use privileged access management
• Microsoft: Developing a privileged access strategy
• Microsoft: Securing privileged access intermediaries
• Google Cloud: Privileged Access Manager overview
• AWS: Temporary security credentials in IAM
• OWASP: Non-Human Identities Top 10 2025

Related NHI Mgmt Group resources: Privileged Access Management Guide · Credential Vaulting vs Just-in-Time Elevation · JIT Access Guide · Cloud PAM and CIEM Guide · Workload Identity Federation Guide