Privilege Manager › Introduction
Endpoint Security Least Privilege Zero Trust
01
Product Introduction
What is
Privilege Manager?
Privilege Manager is Delinea's endpoint privilege management solution. It gives organizations precise, policy-based control over what users and applications can do on every endpoint — without interrupting legitimate work.
74%
of breaches involve privilege abuse
Verizon DBIR 2024
80%
of critical CVEs mitigated by removing local admin
Microsoft Security Report
90%
reduction in attack surface via least-privilege enforcement
Delinea Platform Data
Core Capabilities
🛡️ What Privilege Manager Does
Privilege Manager sits as an agent on every managed endpoint — Windows, macOS, and Linux. When an application launches or requests elevated rights, the agent intercepts the request, evaluates it against your defined policies, and either grants, elevates, blocks, or prompts — all in real time, transparently to the end user.
✓ What It Enables
  • Remove local admin rights across the enterprise without productivity loss
  • Let approved apps self-elevate silently — users never see a UAC prompt
  • Block malware, unauthorized installers, and untrusted executables
  • Enforce policy-based exceptions for legitimate IT needs
  • Provide full audit trail for every privilege decision
✕ What It Prevents
  • Ransomware installing silently via local admin rights
  • Lateral movement using over-privileged endpoint accounts
  • Shadow IT and unauthorized application installations
  • Credential theft through privilege escalation exploits
  • Compliance violations from unchecked admin sprawl
Where It Fits

Privilege Manager is the endpoint layer of a least-privilege strategy. It works alongside PAM solutions like Secret Server (which protects privileged credentials in a vault) but operates at the process and application level rather than the credential level. Together they form a complete privileged access control surface.

ConcernPrivilege ManagerSecret Server
Protects…What applications can do on endpointsPrivileged credentials in a vault
Works at…Process / OS layer on every endpointCredential access layer
Key controlLeast-privilege enforcementJust-in-time credential access
AuditApplication & privilege decisions per endpointCredential checkouts, session recordings
💡
Key mindset shift: Traditional IT thinking is "give users what they ask for unless there's a reason not to." Privilege Manager inverts this: nothing gets elevated unless there's a policy that explicitly permits it.
02
Security Fundamentals
The Local Admin
Problem
Giving users local administrator rights on their workstations is one of the most common — and most dangerous — IT shortcuts in enterprise computing. Understanding why drives home why removing it is such a high-impact control.
The Attack Surface Local Admin Creates
// Attack Path Comparison
Scenario A: User Has Local Admin Rights
STEP 01
Phishing Email
User opens malicious attachment or clicks link
STEP 02
Payload Executes
Dropper runs silently — no UAC prompt needed
STEP 03
Persistence
Malware installs service, disables AV, opens backdoor
STEP 04
Lateral Move
Uses local admin hash to move across network
STEP 05
Full Compromise
Domain escalation, data exfil, ransomware deployment
Scenario B: Privilege Manager Enforced (No Local Admin)
STEP 01
Phishing Email
User opens malicious attachment or clicks link
STEP 02
Blocked
Payload requests elevation — no matching policy → blocked
STEP 03
Audit Log
Block event logged, SOC alerted, endpoint quarantined
——
Chain Broken
Attack cannot proceed without elevated rights
——
Contained
Blast radius limited to standard user context only
Why So Many Organizations Still Have Local Admin
⚠️ The Productivity Myth
The most common objection: "My users need local admin to do their jobs." In reality, fewer than 5% of typical application operations require true admin rights. The other 95% can be addressed by targeted elevation policies — apps that need elevation get it automatically, transparently, without a helpdesk ticket.
⚠️ The "Trusted Users" Fallacy
Granting local admin based on user trust ignores that credentials get stolen. An attacker who phishes a trusted developer now has a local admin session. Privilege Manager's policies are process-based, not identity-based alone — the application is also evaluated, not just who's asking.
The Business Case — By the Numbers
ControlImpactEvidence
Remove local admin rights HIGH Highest single-control ROI in endpoint security Eliminates the majority of malware install vectors immediately
Application allow-listing HIGH Blocks untrusted executables entirely NIST 800-53 AC-3, CIS Control 2 — both mandate this
Privilege elevation by policy MEDIUM Replaces helpdesk tickets for app installs Reduces helpdesk calls by 40–60% in typical deployments
Real-time audit logging COMPLIANCE Full audit trail per endpoint per event Required for SOX, PCI DSS, HIPAA endpoint controls
📌
CIS Critical Controls, Control #5: "Use of least privilege is required to restrict access rights for users, accounts, and computing processes to only those resources required to perform their function." Privilege Manager is the enforcement engine for this control at the endpoint layer.
03
Core Concepts
Four Concepts
That Drive Everything
Privilege Manager is built on four foundational concepts. Every policy you create, every exception you handle, and every audit event you investigate maps back to one of these. Click each card to expand.
🔓
Local Admin Removal
The starting point. Remove local administrator rights from all standard user accounts across the fleet.

Local admin removal is the foundational step. Before Privilege Manager can meaningfully protect an endpoint, the ambient privilege that makes attacks easy must be removed.

With Privilege Manager, this doesn't mean users suddenly can't do anything. The agent intercepts every action that would have required admin rights and evaluates it against policy — so legitimate apps still work, while malicious processes are stopped cold.

Tier 0 Control Attack Surface Zero Trust
⬆️
Application Elevation by Policy
Grant elevated rights to specific approved applications without giving users admin accounts.

Instead of giving a user admin rights so they can run one elevated app, you define a policy that elevates that specific application on demand — invisibly to the user, or with a justification prompt.

Policies target apps by: publisher certificate, file hash, path, command-line arguments, or combination filters. This means even if a malicious file is placed at the same path, it won't be elevated unless the hash matches.

Silent Elevation Prompted Elevation Hash-Verified
🚫
Application Blocking
Prevent specific applications, file types, or execution contexts from running entirely.

Blocking policies define what can never run, regardless of who is asking. This includes: known malicious executables, personal software on managed devices, any unsigned binary, or anything launched from a temp/download directory.

Blocks can be silent (policy-enforced, no user message) or notification-based (user sees a message explaining why the app was blocked and offering an escalation path).

Silent Block Notify & Block Allow-list
📋
Policy-Based Exception Handling
Define structured, auditable pathways for legitimate applications that need elevated rights.

Real enterprises have legitimate edge cases: a developer who genuinely needs to run a debugger with elevated rights, or a finance user who installs quarterly software. Exception handling gives these a structured, auditable path instead of a blanket admin account.

Exception types include: self-service justification prompts, manager approval workflows, temporary time-boxed elevation, and helpdesk-initiated one-time grants — all logged and reviewable.

Self-Service Approval Workflow Time-Boxed
How the Concepts Layer Together
// Policy Decision Flow for Every Application Launch
App Launch
Block List?
Check 1
Allow List?
Check 2
Elevation Policy?
Check 3
Default Policy
Fallback
If match → Block + log event
If match → Run at standard rights
If match → Elevate (silent or prompted)
Configurable: allow / block / prompt
04
Core Concepts
Application
Elevation
Elevation policies let specific, approved applications run with elevated rights — transparently to users — without the user holding a local admin account. This is the control that makes local admin removal palatable across the enterprise.
Elevation Modes
Silent Elevation
App launches with elevated rights automatically. User sees nothing different. Used for trusted, well-understood LOB applications where no justification is needed.
Prompted Elevation
User sees a Privilege Manager dialog asking for a business justification reason. Their selection is logged. The app then elevates. No admin password required.
Approval-Required
User submits a request; an approver (manager, IT) reviews it before elevation is granted. Full workflow in the PM console. Time-boxed grants supported.
The Elevation Dialog — What Users See
Privilege Manager — Elevation Request
🔧
Sysinternals Process Monitor
C:\Tools\Sysinternals\Procmon.exe · v3.95 · Signed: Microsoft
This application requires elevated privileges to run. Your IT policy allows elevation for approved tools. Please provide a business reason for using this application.
Cancel
Run Elevated
✓
User experience note: The user never types an admin password. They never call the helpdesk. The justification selection takes 3 seconds. This is the core UX promise of Privilege Manager — security without friction for legitimate work.
Defining an Elevation Policy — Key Fields
POLICY DEFINITION (PM CONSOLE) // Elevation Policy: IT Monitoring Tools Policy Name: Elevate Sysinternals Suite Applies to: Windows Workstations (All) Action: Elevate Application // Application Filters (ALL must match) Publisher: "Microsoft Corporation" (cert verified) File Name: procmon.exe | procexp.exe | autoruns.exe File Hash: SHA256: a3f9... [pinned version] // Elevation Behavior Mode: Prompted // Show justification dialog Justifications: ["Troubleshooting", "IT maintenance", "Evaluation"] Audit: Log to PM + SIEM + ServiceNow ticket Time limit: 4 hours // Process terminates after window
Elevation Policy Checklist
  • ✓
    Define application filters precisely — never elevate by path alonePaths can be hijacked; always combine with publisher cert or file hash
  • ✓
    Choose the least-disruptive mode: silent > prompted > approvalSilent for well-known trusted tools; prompted for anything users install themselves
  • ✓
    Set a time limit on any elevation where possibleTime-boxed elevation limits blast radius if the elevated session is compromised
  • ✓
    Enable audit logging to both PM console and your SIEMEvery elevation decision is a security event that belongs in your SOC pipeline
05
Core Concepts
Application
Blocking
Blocking policies define what can never run on a managed endpoint. Combined with elevation policies, they give you a complete application control surface — a positive model of what's allowed, with a deny wall around everything else.
Blocking Approaches
🚫 Deny-List Blocking
Block specific known-bad applications, file types, or categories. Examples: known ransomware hashes, unapproved remote access tools, cryptocurrency miners. Start here — low disruption, immediate impact.
🔒 Allow-List Control
Only allow explicitly approved applications to run. Everything not on the list is blocked. Most secure but requires careful scoping. Typically applied to high-risk segments (kiosks, point-of-sale, industrial workstations) before rolling org-wide.
Common Blocking Scenarios
ScenarioBlock TriggerUXRationale
Ransomware dropper (unsigned, from %TEMP%) Unsigned binary + launch path filter Silent Block Legitimate software is never unsigned in %TEMP%
Personal remote access (AnyDesk, TeamViewer personal) Publisher or product name filter Block + Message Shadow IT risk; corporate remote access tools available
Unapproved browser extensions with elevated permissions Child process filter (browser spawning installer) Silent Block Extension installers should not run with elevated context
Command-line tools from user context (PowerShell, cmd) Parent process + user-context filter Audit Only Useful for monitoring before enforcing blocks; staged rollout
DLL injection attempts Process behavior monitoring + injection flag Block + Alert SOC Legitimate software rarely injects into system processes
Block Notification — What Users See
🚫 Block + Notification Message

When a notification-mode block fires, Privilege Manager shows users a configurable message that can include: the name of the blocked application, the reason for the block, and — critically — an escalation path (ServiceNow link, email address, or self-service request button).

Block Message Template: "[App Name] is not authorized on this system. If you need this application for work, click 'Request Access' to submit an IT request. Reference: PM-BLOCK-{{event_id}}" Escalation Button: Opens ServiceNow intake form Event logged to: PM Console + Splunk + Email to manager
⚠️
Rollout strategy: Never start with allow-listing in a production environment. The recommended sequence is: (1) Audit-only mode — log everything, block nothing. (2) Block obvious bad actors (deny-list). (3) Enable elevation policies for known-good apps. (4) Tighten toward allow-list for high-risk segments only.
06
Platform Coverage
Windows · macOS
· Linux
Privilege Manager deploys a lightweight agent on each operating system and integrates with the OS privilege model natively. The policy logic is identical across platforms; the enforcement mechanisms adapt to each OS's security architecture.
⊞ Windows
macOS
🐧 Linux
⊞ Windows Endpoint Agent
The PM agent on Windows integrates with the Windows security subsystem and intercepts CreateProcess calls to evaluate privilege decisions before the OS grants them. It also filters UAC (User Account Control) prompts, replacing them with PM's own elevation dialog when a policy match exists.

Key Capabilities

  • UAC policy replacement — PM dialog replaces Windows UAC prompts
  • Token manipulation — elevates process token without user having admin account
  • Application hash verification — SHA256 matching before elevation
  • Publisher certificate trust — verify signing cert chain
  • Child process control — policies propagate to spawned processes
  • Group Policy integration — PM policies can be distributed via GPO

Supported Environments

  • Windows 10 / 11 (Home, Pro, Enterprise)
  • Windows Server 2016 / 2019 / 2022
  • Azure Virtual Desktop (AVD) sessions
  • Citrix / RDS published desktops
  • Domain-joined and non-domain (Azure AD joined)
  • SCCM / Intune / Tanium deployment support
AGENT DEPLOY · INTUNE POWERSHELL # Deploy PM agent via Intune (Win32 app package) Install-Package -Name "DelineaPMAgent" -Source "PM-Distribution-Share" # Silent install with tenant registration msiexec /i PMAgent.msi TENANT_URL="https://pm.delinea.app" REG_KEY="[KEY]" /qn
macOS Endpoint Agent
On macOS, the PM agent integrates with the Authorization Services framework and System Extension APIs. It can intercept sudo calls, installer package launches, and privilege escalation attempts via the AuthorizationExecuteWithPrivileges API — the primary mechanism macOS applications use to request elevated rights.

Key Capabilities

  • Authorization Services integration — intercepts all privilege escalation
  • sudo policy control — replace sudo password prompt with PM justification
  • PKG installer control — evaluate .pkg files before installation proceeds
  • Gatekeeper complement — PM adds policy layer on top of Gatekeeper
  • Apple Silicon + Intel — universal binary agent support
  • MDM-compatible — deploy via Jamf, Mosyle, Microsoft Intune

macOS-Specific Controls

  • Block or control .pkg and .dmg launches
  • Evaluate app bundles by code signing identity
  • Control Terminal / shell elevation per user/group
  • FileVault integration — encryption key custody awareness
  • macOS Sequoia / Sonoma / Ventura support
AGENT DEPLOY · JAMF PRO # Jamf policy script for PM macOS agent installer -pkg DelineaPMAgent.pkg -target / # Register agent with PM cloud tenant /Library/Application\ Support/Delinea/pmcagent \ --register --tenant "https://pm.delinea.app" --key "[REG_KEY]"
🐧 Linux Endpoint Agent
The Linux PM agent uses PAM (Pluggable Authentication Modules) and kernel-level hooks to intercept setuid calls, sudo requests, and privilege escalations. It replaces or augments the sudoers file with policy-driven rules managed centrally from the PM console.

Key Capabilities

  • PAM module integration — hooks into the Linux auth stack
  • Centralized sudo policy — replace /etc/sudoers with PM-managed rules
  • Setuid/setgid control — flag or block setuid binary execution
  • Audit daemon integration — feed events to auditd / SIEM
  • Namespace-aware — works within container host environments

Supported Distributions

  • RHEL / CentOS / Rocky / AlmaLinux 7, 8, 9
  • Ubuntu 20.04, 22.04, 24.04 LTS
  • Debian 11, 12
  • SUSE Enterprise Linux 15
  • Amazon Linux 2 / 2023
  • Oracle Linux 8, 9
AGENT DEPLOY · RPM / DEB # RHEL/CentOS rpm -ivh delinea-pm-agent-1.x.rpm systemctl enable --now delinea-pm # Ubuntu/Debian dpkg -i delinea-pm-agent_1.x.deb systemctl enable --now delinea-pm # Register with tenant pm-agent register --url "https://pm.delinea.app" --key "[REG_KEY]"
07
Policy Design
Exception
Handling
No policy is perfect on day one. Exception handling is the structured, auditable process for dealing with legitimate applications that fall outside current policies. Done well, it becomes the engine for continuously improving your policies.
⚠️
The exception anti-pattern: The worst response to an exception request is to temporarily grant the user a local admin account. This defeats the entire purpose of Privilege Manager. Every exception must be handled through PM's own mechanisms.
Exception Workflow
📋 The Exception Lifecycle
1
Block fires & user sees notification
PM blocks the app and displays the notification message with a "Request Access" button or ServiceNow link
2
User submits business justification
Structured form captures: application name, business need, urgency, approver. PM auto-populates application metadata (hash, publisher, path) from the block event.
3
IT / Security reviews the request
Approver verifies the application is legitimate, checks VirusTotal/reputation data PM provides, and decides: approve, deny, or escalate for deeper review.
4
One-time grant OR policy created
For a single user's one-off need: issue a time-boxed one-time elevation token. For a recurring need that affects multiple users: create a proper PM elevation policy so it never blocks again.
5
Policy library improves over time
Every reviewed exception is an opportunity to harden your policies. Track exception volume — high repeat-exception apps should be formalized into policies within 30 days.
Exception Types Reference
Exception TypeUse CaseAudit TrailExpiry
Self-Service JustificationUser provides reason, app elevates immediatelyJustification + timestamp + userSession only
One-Time Elevation TokenIT issues a time-limited token for a single runIssuer + recipient + token IDConfigurable (hours/days)
Approval WorkflowManager/IT approves before elevation grantedFull approval chain + timestampsConfigurable
Formalized PolicyRecurring legitimate need → becomes a real policyFull PM audit log foreverOngoing
Vendor Session ExceptionThird-party vendor needs temporary elevated accessVendor identity + access windowMust expire; no open-ended grants
Exception Governance Checklist
  • ✓
    Never grant local admin as an exception responseAll exceptions handled inside PM — no admin account workarounds
  • ✓
    All exceptions carry a defined expiry — no permanent one-time grantsOpen-ended exceptions accumulate into admin sprawl — always set an expiry
  • ✓
    Review exception queue weekly; formalize repeating patterns into policiesSet a KPI: zero recurring exceptions older than 30 days without a formal policy
  • ✓
    Vendor exceptions require manager sign-off and maximum 48-hour windowThird-party access is highest-risk; treat it accordingly
08
Knowledge Check
Test Your
Understanding
Five questions covering the key concepts from this training. Select an answer on each question to see the explanation. Your score is shown at the end.
QUESTION 01 / 05
Which Microsoft data point best summarizes the impact of removing local admin rights?
It reduces phishing success rates by 50%
It mitigates approximately 80% of critical Windows CVEs
It eliminates the need for antivirus software
It blocks 100% of ransomware attacks
✓ Correct. Microsoft's own security research has consistently shown that removing local admin rights mitigates around 80% of critical and high-severity CVEs — because the vast majority of exploits require elevated privilege to execute their payload or persist.
QUESTION 02 / 05
A developer needs to run Wireshark (a network capture tool) on their laptop. They've been given local admin in the past for this. What is the correct Privilege Manager approach?
Keep the local admin account — it's needed for legitimate tools
Block Wireshark entirely as a security risk
Create an elevation policy targeting Wireshark by publisher and hash, with a prompted justification dialog
Issue a permanent exception token for the developer
✓ Correct. This is a textbook elevation-by-policy scenario. Wireshark is legitimate software, but it needs elevated rights to capture network traffic. The right answer is a targeted elevation policy — publisher + hash verified, with a prompted justification so the use is logged. No admin account needed; no permanent exception.
QUESTION 03 / 05
When should you use Allow-List control (only approved apps can run) versus Deny-List blocking?
Always start with allow-listing — it's the most secure approach
Start with deny-listing known bad actors; apply allow-listing to high-risk, well-defined environments like kiosks or POS systems
Deny-listing is always sufficient — allow-listing is only for government use
They are equivalent; use whichever is easier to configure
✓ Correct. Jumping straight to allow-listing in a general enterprise environment causes massive disruption because you will initially block many legitimate applications. The proven approach: start with deny-listing obvious threats, build elevation policies for known-good apps, and layer in allow-listing only for controlled environments where you have a complete inventory of needed applications.
QUESTION 04 / 05
A user reports that Privilege Manager blocked an application they use for a quarterly reporting process. What is the correct exception response?
Temporarily re-enable local admin for that user's machine
Add the application to the global allow-list immediately
Issue a time-boxed one-time elevation token while reviewing; create a formal elevation policy if the app is verified legitimate
Tell the user to use a different application that isn't blocked
✓ Correct. The right sequence: (1) issue a one-time time-limited elevation token so the user can complete their work right now, (2) review the application — check publisher, hash, reputation — and (3) if it's verified legitimate, create a formal elevation policy. This handles the immediate need without giving admin access and without permanently bypassing controls until the review is done.
QUESTION 05 / 05
Which application filter combination provides the strongest security guarantee for an elevation policy?
File path alone (e.g., C:\Program Files\App\app.exe)
Application name (e.g., "Google Chrome")
Publisher certificate (code signing) + SHA256 file hash combined
File size + last modified date
✓ Correct. Path-based filters are the weakest — an attacker can place a malicious binary at the exact same path and get elevated. Name-based filters are similarly spoofable. Publisher cert + SHA256 hash is the gold standard: the cert verifies who signed it, and the hash ensures the exact binary you approved is what runs. Any modification to the file, even a single byte, produces a different hash and the elevation policy won't fire.
—
out of 5 correct