Entra PIM vs CyberArk vs Delinea: Choosing the Right PAM Tool

PIM and PAM: Two Distinct Scopes

Microsoft Entra Privileged Identity Management (PIM) and Privileged Access Management (PAM) solutions share the same acronym in budgeting conversations. They don't solve the same problem. Confusing the two exposes you to an audit finding with a contract already signed.

Entra PIM governs the activation of roles for identities hosted in the Microsoft cloud. Delinea Secret Server and CyberArk Privileged Access Manager govern credentials, wherever they are. That's the boundary.

Role Activation versus Credential Guardianship

Entra PIM holds no secrets. It switches an identity between eligible and active states — the account, password, and token lifecycle remain entirely within Entra ID.

A vault does the opposite: it owns the credential and lends it under supervision.

This distinction shapes the evaluation from the start. If your privileged accounts are Global Administrators, Intune Administrators, and Azure subscription owners, you're looking for a role governance solution. If they're root accounts on 400 RHEL servers, the sa account of a SQL cluster that hasn't been patched since an acquisition, or a Cisco enable password slipped into a rack door, no PIM configuration reaches them.

What Entra PIM Covers — And Where It Stops

The documented scope of Entra PIM covers Entra ID roles, Azure resource roles, and group membership or ownership via PIM for Groups. Within this scope, you get:

• Eligible assignments: the user must trigger explicit activation instead of having permanent access.
• Approval workflows: named approvers receive notification and can deny the request.
• Maximum activation duration configured per role, capped between 1 and 24 hours per role settings documentation.
• Access reviews and downloadable audit history on elevation events.

This is a real reduction in permanent privileges, with nothing to deploy. The project is entirely a configuration matter.

What Entra PIM Doesn't See

Entra PIM records that a user activated the Exchange Administrator role at 2:12 PM and that an approver validated the request. It records nothing of what that user did next. It has no visibility into:

• Active Directory Domain Services on-premises
• Local administrator accounts
• Linux sudo rules
• Database logins
• Application service accounts outside Entra ID
• Anything running in AWS or GCP

The usual answer is to add Azure Bastion session recording, which captures graphical RDP and SSH sessions to Azure VMs. This option works, but with significant constraints:

• It requires the Bastion Premium SKU.
• It covers only VMs in the bastion's virtual network or a directly peered network.
• It's not available via the native client.
• Entra ID authentication for portal RDP sessions cannot run simultaneously with graphical session recording.

Also note: Microsoft Entra Permissions Management, the cloud entitlements management product that coexisted with PIM, reached end of sale and retirement, with automatic customer migration at the cutover date. PIM itself is at the core of Entra ID Governance and doesn't follow this trajectory — but the history deserves to be known before building a strategy on an adjacent module.

Deployment Effort: The Sharpest Difference

Converting Admins in Entra PIM

Converting permanent admins to eligible assignments in Entra PIM is a scripting job against the Microsoft Graph PowerShell SDK. Nothing to build, nothing to push to an endpoint.

Log in as Privileged Role Administrator, consent to the RoleEligibilitySchedule.ReadWrite.Directory scope referenced in Graph permissions documentation, then issue a request per assignment to convert:

1$params = @{
2    Action           = "AdminAssign"
3    PrincipalId      = (Get-MgUser -UserId "dana@contoso.com").Id
4    RoleDefinitionId = (Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Exchange Administrator'").Id
5    DirectoryScopeId = "/"
6    Justification    = "Tier 1 messaging support, eligible only"
7    ScheduleInfo     = @{
8        StartDateTime = Get-Date
9        Expiration    = @{ Type = "AfterDuration"; Duration = "P180D" }
10    }
11}
12 
13New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

Four parameters condition the robustness of the conversion:

• Action: AdminAssign creates eligibility, AdminRemove revokes it — a single script covers both migration directions.
• DirectoryScopeId: / means entire tenant scope; point to an administrative unit if the role should cover only a region.
• Expiration.Type: accepts AfterDuration, AfterDateTime, or NoExpiration — the latter silently recreates the problem you're trying to solve.
• Duration: ISO 8601 format; P180D expires the eligibility itself after 180 days and forces a renewal conversation.

Plan for two additional passes. The activation policy — maximum duration, MFA enforcement, approvers, justification text — is a separate object that the rules mapping guide documents parameter by parameter. Verification constitutes the third pass: a successful request returns Provisioned status with 201 Created code. Read the schedule with Get-MgRoleManagementDirectoryRoleEligibilitySchedule filtered on the principal before removing the permanent assignment. The license must be assigned before eligibility; the permanent assignment comes out last. Reverse the order and you lock someone out of a role they still need. Plan for a few days of scripting and a change window.

Deploying a Vault: A Different Investment

Delinea and CyberArk both start with infrastructure to build before a single credential is vaulted. Delinea starts with distributed engines close to each site and a message queue, then only account discovery. CyberArk starts with a hardened Vault and a fleet of connectors sized to concurrent session count — Safe and platform design must be settled before onboarding begins, which is why statements of work mention certified engineers.

The reality: a few days versus several quarters. This gap alone justifies keeping the governance layer you already paid for, even after signing for a vault.

Delinea: Secret Server, Server Suite, and the Centrify Legacy

Delinea was born from the merger of Thycotic and Centrify, which explains why it delivers a credential vault and an Active Directory bridge designed by different teams for different customers. This genealogy explains both its strengths and its visible seams at implementation.

What Delinea Does Well

Secret Server is the vault. Its session recording model is a dual switch: global enablement for the instance, then per-secret enablement, as described in the session recording configuration guide. Both levels are accessible via the Secret Server REST API, allowing you to enable recording on an entire secret template without touching the console.

Recording follows the launcher — RDP, PuTTY, SSH, SQL Management Studio start the same way — but what each session produces depends on the component used:

• The protocol handler and Web Password Filler produce video.
• RDP/SSH proxies and ASRA produce keyboard data.
• Process metadata comes from ASRA only.
• The Secret Server Session Connector records nothing.

Server Suite is the other half, and the reason Delinea appears on shortlists with significant Linux environments. Its zones model joins Unix and Linux hosts to Active Directory by storing Unix attributes in AD — a root login becomes an AD identity with AD Group Policy and an AD audit trail. Hierarchical zones are those to design first: they carry inheritance and per-host overrides in a tree you control. Classic zones are a backward compatibility artifact from the Centrify era.

Where Delinea Shows Its Limits

Modularity is the recurring complaint, and it's founded. Vaulting, endpoint elevation, Unix identity consolidation, and DevOps secrets are four products, each with its own license line and its own admin console. At two dozen privileged systems, this is invisible. At two thousand, inter-module integration becomes a full-time job.

The recording pipeline has real operational requirements, documented straightforwardly by Delinea:

• The reference architecture strongly recommends RabbitMQ as the message bus rather than the built-in MemoryMQ.
• Keyboard search on RDP requires the Advanced Session-Recording Agent (ASRA) installed on the target, not just on the vault.
• The official caveats page advises against recording more sessions than you can encode.

CyberArk: Session Isolation and the Palo Alto Networks Variable

CyberArk is the platform the other two are compared against, and the reason is architectural. Its Privileged Session Manager (PSM) proxies the connection so the target credential never reaches the administrator's workstation.

How Session Isolation Actually Works

When a user starts a session, the PSM creates a shadow user on the proxy machine and connects to the target as that shadow user — preventing two simultaneous sessions from the same PSM server from interfering with each other. The PSM configuration reference also defines behavior when the Vault is unreachable and a recording cannot be uploaded — read that section before guaranteeing an auditor that recordings are systematic.

On the audit side, the Password Vault Web Access (PVWA) console gives auditors a single entry point to search for recordings by SQL command, SSH command or SCP, blocked command, keystroke, or Windows event, per the session monitoring documentation. Access is conditioned by the View Audit permission in the relevant Safe or membership in the Auditors group — exactly the separation of duties control an auditor will verify.

The Palo Alto Networks Variable

CyberArk is now a wholly owned subsidiary of Palo Alto Networks following an approximately $25 billion acquisition. The Identity Security Platform roadmap is therefore set within a much broader portfolio strategy, with bundling possibilities at renewal.

Session Recording Decides Your Audit Evidence

Every PAM evaluation eventually converges on an auditor question: show me what the administrator did. PCI DSS Requirement 10.2.1.2 requires audit logs capturing all actions by anyone with administrative access. "We logged the elevation request" is a different artifact from "we have the session."

What Each Platform Actually Costs

Total cost of ownership over three years is where these products differentiate most sharply — and nearly all the gap comes from something other than the license line.

If you already own Entra ID P2 or Entra ID Governance, the incremental software cost of Entra PIM is zero. Buying Delinea or CyberArk reimburses no part of that license. You're not choosing between them financially: you're deciding whether to add a vault on top of governance you already paid for.

The Coexistence Model Most Hybrid Environments Adopt

Here's the architecture most hybrid organizations eventually adopt — often by trial and error rather than by design.

Entra PIM governs cloud role elevation; a vault governs credentials. The demarcation line is neither "Microsoft versus the rest" nor "cloud versus on-prem." What decides ownership is the nature of the protected resource: a role assignment or a secret.

Entra PIM keeps the role side: directory roles, Azure resource roles, group membership managed by PIM. MFA and justification requirements apply at activation time.

The vault owns everything that is a stored secret: on-premises Tier 0 Active Directory accounts, Linux root, network device credentials, database logins, application-to-application secrets buried in config files written in 2017.

Both sides share the approval path. Route the ITSM ticket reference through both request paths so your reviewers work a single queue, not two unlinked queues — the second queue is where approvals wait four days.

Evaluation Grid: 10 Questions to Choose

Product verdicts age poorly. An evaluation framework doesn't. Answer these ten questions about your environment, tally the points, let the total guide the choice.

Scoring Method

Each question is worth 0, 1, or 2. A 0 points toward Entra PIM, a 1 toward Delinea, a 2 toward CyberArk. Skip questions that don't apply to your environment — a skipped question isn't a 0, and averaging would skew the result in PIM's favor.

1. Do you have privileged credentials outside Entra ID? 0 if all privilege lives in Entra ID and Azure. 1 as soon as on-prem AD, Linux, network, or databases hold privileged accounts. 2 if all four categories are present.

2. Does a regulator or customer contract require session video, not just elevation logs? 0 for elevation logs only. 1 for per-asset recording. 2 when the contract demands tamper-proof isolation and search.

3. How many Linux or Unix hosts carry privileged local accounts? 0 under about 100 hosts. 1 beyond 100 (AD bridging starts to pay for itself). 2 beyond 500 (per-host role control is no longer optional).

4. Do external vendors need privileged session access? 0 if no one outside your organization accesses privileged sessions. 1 for a few named vendors on known systems. 2 if external access brokering must be a standing capability.

5. Do you have dedicated PAM capacity, or will it be the fourth priority of someone? 0 if PAM is currently nobody's job. 1 if one security engineer can carry it half-time. 2 if you can fund a named PAM engineer for the deployment duration.

6. Are your privileged accounts under 500 or in the thousands? 0 under 500. 1 between 500 and a few thousand. 2 beyond: module fragmentation becomes a full-time job at that scale.

7. Do legacy applications embed credentials that break on rotation? 0 if rotation is safe everywhere. 1 for a short list of known exceptions. 2 if you can't name them all — each unknown adds weeks to a vault deployment.

8. Do you already pay for Entra ID P2 or Entra ID Governance? 0 if yes: the zero-cost governance layer belongs in your design regardless of which vault solution you pick. 1 if no and every control is a net expense.

9. Do machine identities, workloads, or AI agents hold privilege in your environment? 0 if human accounts comprise the entire problem. 1 if service accounts are the extent. 2 if non-human identities outnumber your head count and none of your shortlist has a concrete answer.

10. Can you tolerate a 6 to 18 month deployment, or do you need control this quarter? 0 if you need control this quarter. 1 for a six-month window. 2 if you can fund and staff the full eighteen months.

Sum the points and divide by the number of questions you answered. Below 0.5: the governance layer you already own covers your actual risk. Between 0.5 and 1.4: Delinea. Above 1.4: you have the complexity — and ideally the staffing — that CyberArk assumes.

The Two Limits That Annul the Average

An average is a recommendation, not a plan. Test it against two hard limits.

Staffing is the first limit. If question 5 scored 0, your answer is Entra PIM plus whatever you can personally operate, regardless of the arithmetic — a vault without staffing degrades to a read-only credential list within a year, and you keep paying for it.

Timeline is the second limit. If question 10 scored 0, a CyberArk-scale deployment is off the table for this fiscal cycle, even at an average of 1.8. The realistic decision: convert permanent admins to eligible assignments now, and reopen the vault decision at the next budget cycle.

Key Takeaways

• Entra PIM and PAM solutions don't replace each other: one governs roles, the others guard secrets. Most hybrid environments need both.
• Entra PIM is free if you already have Entra ID P2 or Entra ID Governance — convert your permanent Global Administrators to eligible assignments now, leaning on the official deployment plan.
• Delinea suits mid-sized security teams with significant Linux heritage and per-asset recording needs. Accept the modularity and choose your recording targets carefully.
• CyberArk targets environments where proof requirements are absolute and heritage extends to legacy and multi-cloud — provided you have the engineering capacity and negotiate renewal in light of Palo Alto Networks integration.
• The real hidden cost isn't the license: it's the person managing password rotation on applications that break on change. Budget that line before signing.
• Draw the demarcation line in writing in your access policy, especially for service accounts — the most common orphan in PIM + vault architectures.