PEDM / EPM
PEDM (Privileged Elevation and Delegation Management) and EPM (Endpoint Privilege Management) are the area of PAM that removes standing administrator rights on workstations and servers and elevates them only for specific applications or commands.
What is PEDM / EPM?
PEDM (Privileged Elevation and Delegation Management) and EPM (Endpoint Privilege Management) are two names for the same area of security: managing elevated privileges directly on workstations and servers. Instead of giving users and administrators standing administrator or root rights, the organisation lets them work with standard accounts and elevates privileges only for specific applications, commands or tasks.
The name EPM appears more often in the context of workstations (removing local administrator rights), while PEDM is used more broadly, including for Linux, Unix and Windows servers. In both cases the aim is to put the principle of least privilege into practice where users actually work.
PEDM / EPM definition
PEDM / EPM is a set of mechanisms that removes standing administrative rights from user accounts and replaces them with controlled, precise elevation: for a designated program, command or time window, according to rules and — where needed — after approval. Every elevation is logged.
It is one of the areas of Privileged Access Management (PAM), alongside storing credentials in a password vault and managing privileged sessions through an intermediary gateway.
Why standing administrator rights are a problem
An account with local administrator rights can install any software, disable endpoint protection, change security settings and read credentials stored on the system. If an attacker takes over such an account — through phishing, a malicious attachment or a browser vulnerability — they inherit all of these capabilities. From there, lateral movement to other systems becomes easier.
On servers the problem looks similar: administrators who constantly work as root or as members of the domain administrators group mean that every mistake and every compromised account has maximum reach.
How PEDM / EPM works
Removing standing privileges
The starting point is removing user accounts from local administrator groups and limiting work as root. The user works with a standard account all day.
Elevation rules for applications and commands
Instead of full rights, the administrator defines rules: this installer, this diagnostic tool or this maintenance command may run with elevated privileges — but nothing beyond them. Rules identify applications by path, publisher signature or file hash, and commands by their full text and arguments.
On-demand elevation with approval
When a user needs something the rules do not cover, they submit a request with a justification. The approver accepts or rejects it, and the elevation applies for a set time or for a single action. This is the same pattern as just-in-time access, applied at the level of the workstation and the server.
Application control
Many PEDM / EPM solutions combine privilege management with application control: they block unknown programs from running or require additional approval for them.
Logging
Every elevation, request, approval and denial goes into a log that can be forwarded to a SIEM system and used in audits.
Example: a command with elevated privileges on Linux
An application administrator needs to restart a service on a production Linux server. In a model without PEDM, they have full root access — they can restart the service, but they can also change any system file.
In a PEDM model, their account has no root rights. A rule allows them to run, via sudo, only the restart command for that one service. When they need more, such as a change to system configuration, they submit a request with a justification. Once it is approved, they receive elevation for a set time, and every command run during that time is logged. When the time runs out, the privileges expire on their own.
On a Windows workstation it looks similar: an accountant has no administrator rights, but an approved electronic signature application installs and updates with elevated privileges based on a rule, without involving the IT department.
PEDM and the other areas of PAM
- A password vault protects privileged account credentials and issues them for the duration of a task.
- Session management controls and records administrative connections that pass through a gateway — see privileged session recording.
- PEDM / EPM limits what a user can do on a workstation or server under their own account, without reaching for an administrator account.
These areas complement each other. The vault and the gateway solve the problem of shared administrative accounts and remote access; PEDM solves the problem of excessive privileges assigned to named accounts.
Benefits
- Smaller attack surface — a compromised user account without standing administrator rights gives an attacker far fewer options.
- Least privilege in practice — elevated privileges are tied to actions, not to people.
- Fewer IT tickets — repetitive tasks that require privileges are handled by rules rather than manual administrator intervention.
- Accountability — every elevation has an author, a reason and a time.
- Support for Zero Trust — the absence of standing privileges is one of the pillars of the Zero Trust model.
Limitations and challenges
- An observation phase is essential — removing privileges without knowing which applications need them ends in a wave of tickets and pressure to restore the old state.
- Rule maintenance — rules have to be updated as software changes; overly broad rules (for example, allowing any shell with elevated privileges) defeat the whole mechanism.
- Exceptions for administrators — IT teams need broader rights; these cases are better handled through time-limited access and recorded sessions than through permanent exceptions.
- Diverse systems — Windows and macOS workstations and Linux and Unix servers need different mechanisms, which are best covered by a common policy.
Summary
PEDM / EPM moves the principle of least privilege from policy documents onto workstations and servers: users work with standard accounts and receive elevated privileges only for specific actions, for a set time and with a log entry. Within a PAM programme, it complements the password vault and privileged session management.
Related Terms
- Privileged Access Management - managing privileged access
- Least Privilege - the principle of least privilege
- Just-in-Time Access - temporary access on demand
- Privileged Access - the level of access to administrative operations
- Zero Trust - a security model based on continuous verification
Explore Our Services
Want to reduce administrators’ standing privileges in your organisation? Explore:
- PAM Implementation - design, deployment and operation of privileged access control
Frequently asked questions
+ What do PEDM and EPM stand for?
PEDM stands for Privileged Elevation and Delegation Management. EPM stands for Endpoint Privilege Management. Both terms describe the same area: users and administrators work with standard accounts and receive elevated rights only for designated applications, commands or tasks. EPM more often refers to workstations, while PEDM also covers servers.
+ How is PEDM different from a password vault?
A password vault protects privileged account credentials and issues them for the duration of a task. PEDM works differently: instead of giving someone the password to an administrator account, it lets them perform a specific action with elevated rights under their own user account. Both mechanisms are part of PAM and often work together.
+ Won't removing local administrator rights bring users' work to a halt?
Not if the rollout starts with observation. First, record which applications and actions actually require elevated rights, then create rules that allow them without full administrator rights, and only at the end remove standing privileges. Rare cases are handled by an elevation request with approval.
+ Does PEDM only apply to Windows?
No. On Windows and macOS workstations it usually means removing local administrator rights and running selected programs with elevated rights. On Linux and Unix servers the same goal is achieved by controlling who can run which commands as root, for example through precise sudo rules with approval and logging of the commands executed.