PAM vs PIM: Scope, Sessions and When You Need Both

Teams that switch on a cloud role elevation feature often believe they have "done PAM", and teams that own a PAM suite often believe their cloud admin roles are covered, and both are usually wrong in different places. Privileged access management (PAM) and privileged identity management (PIM) overlap, but they put the control point in different places: PIM governs whether a privileged role assignment exists and when it is active, while PAM governs how privileged accounts, credentials and sessions are used across servers, databases, network devices and endpoints. This guide compares the two as scopes of control: coverage, threat model, failure modes, fit by estate and how to combine them. It answers the questions buyers and architects keep asking, such as whether Microsoft Entra PIM is a PAM solution and whether you still need PAM if you have PIM. It is written for identity architects, PAM owners and cloud platform teams. The architecture of vaulting against just-in-time elevation is covered separately in Credential Vaulting vs Just-in-Time Elevation; this page is about scope and coverage.

Key takeaways

• PIM controls the role, PAM controls the use. PIM decides whether a privileged role assignment is live right now; PAM decides how a privileged account or credential is reached, used, recorded and rotated.
• Cloud PIM features stop at their own platform. Microsoft Entra PIM covers Entra roles, Azure resource roles and PIM for Groups; Google Cloud Privileged Access Manager covers IAM roles in Google Cloud. Both are scoped to their own platform roles, so SSH sessions to Linux hosts and database passwords sit with PAM.
• PAM suites rarely own cloud control plane roles well by themselves. A vault can hold the password of a cloud admin account, but an eligible assignment that does not exist until activated removes more risk than a permanent assignment behind a vault.
• Permanent roles are the shared failure. A PIM deployment full of permanent active assignments and a PAM vault full of standing domain admin accounts give an attacker the same thing: privilege that is always on.
• Most organisations need both, split by estate. PIM for directory and cloud roles, PAM for accounts that must exist permanently and for sessions that must be brokered, with one approval policy, one break-glass process and one audit view.

What PAM and PIM mean

The two acronyms are used loosely, and much of the confusion comes from PIM having two meanings.

PIM as a discipline

In the general sense, privileged identity management is the governance of privileged identities and their role assignments: who is entitled to an administrative role, whether that entitlement is permanent or time-bound, who approves it, and when it is reviewed. NIST defines a privileged account as "a system account with the authorizations of a privileged user"; PIM in this sense is about keeping the set of such authorisations small, owned and temporary. It sits close to identity governance: the object it manages is the assignment.

PIM as a product name

Microsoft uses the name for a specific service. Microsoft describes Privileged Identity Management as "a service in Microsoft Entra ID that enables you to manage, control, and monitor access to important resources", covering Microsoft Entra ID, Azure and other Microsoft Online Services such as Microsoft 365 and Intune. When people search "is Entra PIM a PAM solution", this is the PIM they mean. Configuration depth for that service lives in the Privileged Identity Management (PIM) Guide.

PAM as a programme and a product category

Privileged access management is the wider discipline of controlling privileged access wherever it happens. The NCSC lists "Use privileged access management" as one of five principles of secure system administration, alongside protecting administration interfaces, tiering and logging. In product terms, PAM suites typically combine a credential vault with rotation, session brokering and recording, endpoint privilege management, remote and vendor access, and increasingly just-in-time elevation of their own. The object PAM manages is the credential and the session. See the Privileged Access Management Guide.

Side-by-side comparison

Cloud-native role elevation features

Platforms are listed alphabetically. Each section describes what the provider documents; deeper configuration lives in the linked guides.

AWS

AWS describes temporary elevated access, also called just-in-time access, as "a way to request, approve, and track the use of a permission to perform a specific task during a specified time", supplementing IAM Identity Center permission sets and MFA. As of November 2026 the AWS documentation describes this capability through validated AWS Security Competency partner solutions that integrate with IAM Identity Center, and recommends setting up emergency access to the console for business continuity. See the AWS IAM Identity Center Guide.

Availability: the elevation workflow comes from the chosen integrated solution, which has its own licensing.

Google Cloud

Google Cloud Privileged Access Manager provides "just-in-time temporary privilege elevation for select principals". An administrator creates an entitlement that names the principals who may request, the roles to grant (optionally narrowed with IAM Conditions), the maximum grant duration, whether justification is required, and optional approvers and people to notify. A grant revokes the roles automatically when its duration ends, and events go to Cloud Audit Logs. Entitlements can be set at organisation, folder or project level and accept all identity types, including workload identity federation and agent identities. Entitlements use predefined, custom or the current basic Admin, Writer and Reader roles, so plan to replace legacy Owner, Editor and Viewer grants. See the Google Cloud Privileged Access Manager Guide.

Availability: Google's documentation states that multi-level approvals, scope customisation and some other features need the Security Command Center Enterprise or Premium tier, and that several features are in preview.

Microsoft Entra

Microsoft Entra PIM offers just-in-time access, time-bound assignments with start and end dates, approval to activate, MFA on activation, justification, activation notifications, access reviews and downloadable audit history, and it prevents removal of the last active Global Administrator and Privileged Role Administrator assignments. It covers Microsoft Entra roles, Azure resource roles and PIM for Groups. Microsoft's deployment plan advises keeping "zero permanently active assignments for roles other than your emergency access accounts", and notes that service principals can be given time-limited active assignments rather than eligible ones. See the Privileged Identity Management (PIM) Guide and the Entra ID Privileged Roles Guide.

Availability: Microsoft states that PIM requires licences under Microsoft Entra ID Governance licensing.

Threat model, failure modes and a worked scenario for each option

PIM

Threat model. PIM assumes the attacker will compromise an administrator's everyday identity, through phishing, token theft or password reuse, and aims to make that identity worthless for privileged work until a further, stronger check is passed. Relevant techniques include ATT&CK T1078.004 Valid Accounts: Cloud Accounts and T1098.003 Account Manipulation: Additional Cloud Roles, where an attacker adds a role to persist.

Failure modes. Permanent active assignments left in place "for now"; activation settings too weak (MFA satisfied by a session that is hours old, eight-hour maximum durations for every role); assignments made directly in the platform outside the PIM workflow; the role that administers PIM itself held permanently; and a habit of activating at the start of each day, which turns JIT into standing access with extra clicks.

Controls. Eligible assignments by default, per-role activation policy (short duration, fresh phishing-resistant authentication, justification, approval for the highest tiers), alerts on assignments made outside the workflow, access reviews of eligibility, and two monitored emergency accounts.

Decision criteria. Lead with PIM where privilege lives in directory and cloud roles and administrators sign in with their own named identity.

Worked scenario. A cloud engineer needs Owner on a production subscription to repair a failed deployment. With PIM the engineer is eligible, activates for one hour after a passkey prompt and a ticket reference, the change is made, and the role lapses. A phishing kit that captured the engineer's session yesterday holds no Owner rights today.

PAM

Threat model. PAM assumes privileged accounts that must exist permanently (local administrator, root, database owner, network device admin, application service accounts) and whose credentials are shared, long-lived or embedded. The attacker aims to find those credentials in files, scripts, memory or password stores, or to ride an administrator's session.

Failure modes. Accounts discovered but never onboarded; vaulted passwords that are never rotated; users who check out a credential and paste it elsewhere; standing domain admin accounts that are vaulted but still always privileged; session recordings no one reviews; and the PAM platform itself becoming a single high-value target. See the Top 10 PAM Mistakes.

Controls. Discovery and onboarding, rotation on schedule and after checkout, credential injection so users never see the secret, session brokering with recording and termination, endpoint privilege management for local admin rights, and hardening of the PAM service as tier zero.

Decision criteria. Lead with PAM where privilege lives in accounts on hosts, databases and devices, where shared or third-party access is common, or where regulators expect session evidence.

Worked scenario. A database vendor needs to patch an on-premises cluster. Through PAM the vendor opens a brokered session from the PAM portal, the DBA account password is injected and never displayed, the session is recorded, and the password is rotated when the session closes. PIM has no role to elevate here: the account is local to the database.

Choosing: decision guidance

The question is rarely PAM or PIM. It is which estate each one owns and where the seams are.

• Is Entra PIM a PAM solution? It is a PAM capability for the Microsoft cloud control plane: just-in-time role elevation with approval and audit. Credential vaulting and session brokering for servers sit with PAM tooling, so it is one part of a PAM programme rather than the whole.
• Do I need PAM if I have PIM? If every privileged action happens through roles in one identity provider and cloud, PIM plus strong authentication and admin workstations may be enough for now. Once you have local administrator, root, database, network device or vendor access, you need credential and session controls as well.
• Do I need PIM if I have PAM? Usually yes for cloud roles. Vaulting the password of a permanent Global Administrator still leaves a permanent Global Administrator.
• Small organisations: start with the platform's native role elevation and a hardened break-glass process; add a vault when shared or local admin credentials appear. See PAM for Small Businesses.
• Large organisations: expect both, and decide early which system is the source of truth for approvals and audit so two workflows do not drift apart.

How they work together

The strongest pattern layers the two so each covers the other's blind spot:

• Identity first: administrators sign in with their own named identity, phishing-resistant MFA and, for top tiers, from a privileged access workstation (see the Privileged Access Workstations Guide).
• Roles on demand: PIM activates the cloud or directory role needed for the task, for a bounded time.
• Credentials brokered: where the task reaches a host, database or device, the PAM platform brokers the session and injects the account credential, then rotates it.
• Shared approval logic: one ticket reference and one risk tier drive both the PIM activation and the PAM checkout, so reviewers see a single request.
• One audit view: PIM activation logs, cloud audit logs and PAM session logs land in the same SIEM, keyed to the same person.

Where to place non-human identities is a real seam. Service principals and workload roles do not activate through a human workflow, so neither tool alone fixes standing machine privilege. Prefer workload identity federation and scoped roles; see Service Accounts vs Workload Identities.

How to implement: a phased approach

1. Inventory privilege by estate. List every directory and cloud role assignment with its type (permanent, eligible, active) and every privileged account on hosts, databases and devices. Tag each with the control that should own it: PIM, PAM or both.
2. Establish break-glass first. Create and test two emergency accounts, vault their credentials with split knowledge, and alert on every sign-in. See the Break-Glass Account Guide.
3. Convert cloud roles to eligible. Start with the highest-impact roles (tenant and organisation administrators, role administrators, subscription and project owners). Pilot with one team first.
4. Tighten activation policy per tier. Short maximum durations, fresh phishing-resistant authentication, justification and ticket for all, approval for the top tier. Keep the role that administers the elevation service itself eligible and approved.
5. Onboard persistent accounts to PAM. Vault and rotate local administrator, root, database and network accounts; turn on brokering and recording for production and vendor access first.
6. Join the workflows. Use one request reference across PIM activations and PAM checkouts, and feed both logs into the SIEM.
7. Review and remove. Run quarterly access reviews of eligibility and safe membership, and delete assignments not activated in 90 days.
8. Rollback. If activation friction blocks operations, lengthen the activation duration for the affected role or add approvers rather than reverting to permanent assignments; break-glass covers genuine lockout.

Detection and measurement

What to monitor:

• Role assignments created outside the elevation workflow; Microsoft rates its "Roles are being assigned outside of Privileged Identity Management" alert High.
• New assignments to the top roles at any time, including those made through the workflow, and any change to activation policy.
• Break-glass sign-ins, which should be rare and always explained.
• PAM checkouts without a matching session, credentials used outside a brokered session, and failed rotations.
• Stale privileged accounts; Microsoft's "Potential stale accounts in a privileged role" alert flags accounts with no sign-in for a configurable 1 to 365 days.

For board-level reporting, see PAM KPIs and KRIs to Report to the Board.

Common failure patterns

• Standing top-tier roles: an attacker with one administrator account can create another top-tier administrator and stop depending on the first. In the Stryker Intune wiper attack, a compromised administrator account was used to create a new Global Administrator before devices were wiped; the lessons include removing standing access, JIT elevation with approval and alerting on every new Global Administrator assignment.
• Eligible in name, permanent in practice: assignments converted to eligible but with maximum durations so long and checks so light that administrators activate once a day.
• Vaulting a permanent cloud admin and calling it done: the password is protected, but the always-on role remains, along with any session or token issued to it.
• Assuming PIM covers servers: cloud role elevation leaves local administrator, root and database accounts untouched, and these are where lateral movement usually happens.
• Two approval systems that disagree: a PAM checkout and a PIM activation approved by different people with different criteria, so neither audit trail tells the whole story.
• Unprotected control of the control: the role that administers PIM, or the PAM platform administrators, held permanently and outside the same controls. See Securing the PAM Vault Itself.

Framework mapping

Practitioner checklist

• Write a one-page scope statement saying which privileged roles and accounts PIM owns, which PAM owns and which need both.
• Reduce permanent active assignments to privileged cloud and directory roles to emergency access accounts only.
• Set activation policy per role tier: short duration, fresh phishing-resistant MFA, justification, approval for the top tier.
• Alert on assignments made outside the elevation workflow and on every new top-tier assignment.
• Vault and rotate every local administrator, root, database and network device account, and broker production and vendor sessions.
• Use one request reference and one SIEM view across PIM activations and PAM sessions.
• Protect the administrators of PIM and of the PAM platform with the same or stronger controls than the roles they govern.
• Test break-glass accounts quarterly and alert on every use.
• Remove eligibility not used in 90 days at each access review.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Glossary, privileged account
• NCSC: Secure system administration, use privileged access management
• CIS: Control 6 Access Control Management
• AWS: Temporary elevated access in IAM Identity Center
• Google Cloud: Privileged Access Manager overview
• Microsoft Learn: What is Microsoft Entra Privileged Identity Management
• Microsoft Learn: Plan a Privileged Identity Management deployment

Related NHI Mgmt Group resources: Privileged Access Management Guide · Privileged Identity Management (PIM) Guide · JIT Access Guide · Privileged Session Management Guide · PAM Buyer's Guide