TTechclick ⚡ XP 0% All lessons
BeyondTrust · EPM · Windows & MacInteractive · L1 / L2 / L3

Endpoint Privilege Management (Windows/Mac): — Remove Admin Rights Without the Riots

Give every employee local admin and you have given every malware sample local admin too. This lesson shows how BeyondTrust EPM strips admin rights from thousands of Windows and Mac endpoints without a helpdesk riot — by elevating individual applications, never people.

📅 2026-06-10 · ⏱ 13 min · 3 live demos · 4 infographics · 🏷 10-Q assessment + AI Tutor inline

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Why kill local admin

Ransomware, LSASS dumps, persistence — admin users feed all three.

2

The Avecto model

Workstyles, rules, groups, messages — tokens, not passwords.

3

QuickStart + first rule

Day-1 baseline, then one real installer rule end-to-end.

4

TAP, Power Rules & Mac

Stop Office spawning cmd, script edge cases, deploy via PM Cloud.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. A standard user double-clicks an installer that needs admin rights. With EPM in place, what actually gets elevated?

Answered in Why kill local admin.

2. Your CISO orders local admin removed from 5,000 laptops by Friday. What breaks first on Monday?

Answered in QuickStart + first rule.

3. A user opens an invoice attachment and Word silently tries to spawn cmd.exe. What should a well-configured endpoint do?

Answered in The Avecto model.

Most engineers think…

Most engineers think EPM works by quietly adding the user to the local Administrators group for a few minutes and pulling them back out — "temporary admin", basically.

Wrong — and interviewers probe exactly this. The user's account never changes. The agent launches that one process with a modified access token that carries admin rights. There is no admin password on the box to phish, no UAC credential prompt to keylog, and nothing for mimikatz to scrape — because no admin account was ever used. Elevation lives and dies with the process.

① Local admin is malware's best friend — and the riot problem

Here is the uncomfortable maths of endpoint security: malware almost never needs an exploit to become powerful. When Aditya at TCS opens a poisoned invoice, the payload runs as a child of his session and inherits his access token. If Aditya sits in the local Administrators group, the malware is an administrator the instant it starts. No zero-day, no privilege escalation trick — just inheritance.

What does admin-grade malware actually do? Three things you will meet again in every incident report. One: ransomware encrypts everything it can reach and deletes the Volume Shadow Copies so there is nothing to roll back to — shadow-copy deletion needs admin. Two: it reads the memory of LSASS and walks away with every cached credential on the box, including the domain admin who RDP-ed in last Tuesday. Three: it installs a service, a driver or an HKLM run key — admin-only locations — so it survives reboot. Remove admin from the user, and all three doors slam shut at once.

Figure 1 — Same payload, two blast radii — admin user vs standard user + EPM
Two panels compare the same phishing payload. Left, red: Aditya is a local admin, so the malware inherits an admin token and can encrypt files and delete shadow copies, dump LSASS for cached credentials, and install a service for persistence. Right, green: Aditya is a standard user with the EPM agent, so the malware inherits a standard token and all three actions fail, while his approved installer still gets an elevated application token through policy. Same phishing payload — two very different blast radii Aditya = local ADMIN invoice.exe runs inherits ADMIN token encrypt every file + delete shadow copies dump LSASS memory → every cached cred install service/driver → survives reboot one click = domain-wide incident Aditya = STANDARD user + EPM agent invoice.exe runs inherits STANDARD token encrypt system-wide ✗ read LSASS ✗ install service ✗ no admin token to inherit approved node installer → policy match → THAT process gets an elevated application token ✓ — the user stays standard work continues, malware starves de-admin the HUMAN, elevate the APPLICATION Malware never exploits anything here — it just inherits. Change what it inherits. untrusted/attackertrusted/vaultedpolicy/decisionkey insightallowed/audited
Left (red): the payload inherits Aditya's admin token and gets encryption, LSASS and persistence for free. Right (green): standard user — all three fail, while his legitimate installer still elevates through policy. Nothing was exploited; only the inheritance changed.
👉 So far: malware inherits the user's rights, so an admin user means admin malware — three free wins for the attacker. Next: why simply deleting admin rights starts a riot.

So why hasn't every company just removed admin rights years ago? Because the morning after, the riot starts. Installers fail. Developers cannot register a debugger or run their build tools. That 2014-era legacy app that insists on writing to C:\Program Files and HKLM crashes. Printer and VPN client updates die. The helpdesk queue triples, a VP screams, and within two weeks IT quietly hands admin back "temporarily" — forever. Every PAM engineer in India has watched this movie.

The fix is to change the unit of trust. Think of a wedding hall: the standard guest never gets the owner's master keys, but the caterer's van gets a gate pass for one delivery. BeyondTrust Endpoint Privilege Management (EPM) — the product the field still calls Avecto Defendpoint — elevates per application, never per user. The human stays a standard user for life; the approved installer, and only it, runs with an elevated token. Capability stays, attack surface goes.

Pause & Predict

Predict: the SAME phishing payload detonates on (a) a standard-user laptop and (b) a local-admin laptop. List what it can do in each case before reading on. Type your guess.

Answer: On (b) it inherits admin: encrypt files AND delete shadow copies, dump LSASS for every cached credential, install a service/driver for persistence. On (a) it can only touch the user's own files and profile — no shadow-copy deletion, no LSASS read, no machine-wide persistence. Same code, same click; the only variable is the token it inherited. That delta is the entire business case for EPM.
Quick check · Q1 of 10

Aditya at TCS opens a malicious invoice attachment; his account is in local Administrators. Why does the ransomware get admin power without using any exploit?

Correct: c. Child processes inherit the parent session's access token, so the payload starts with every right Aditya has. No brute force or exploit is involved (a), Windows does not auto-elevate downloads (b), and nothing here grants SYSTEM (d). This inheritance is exactly why removing admin from the human starves the malware.
MISTAKE — de-admin without an elevation plan

Symptom: two weeks after a "remove all local admin" project, the exception list has 800 names and is growing. Cause: admin rights were deleted with no per-application elevation path, so every blocked installer became a ticket and every ticket became an exception. Fix: deploy the EPM agent in audit mode FIRST, learn what genuinely needs elevation, then remove admin with rules already in place. Least privilege is a migration, not a deletion.

② The Avecto model — Workstyles, rules, groups and the token trick

EPM is an agent plus a policy. The agent on Windows is literally named Avecto Defendpoint Service — the acquisition heritage leaks straight into services.msc — and its cloud check-in runs through the IC3Adapter. Endpoint configuration lives under HKLM\SOFTWARE\Avecto\Privilege Guard Client. Knowing these three strings is half of EPM troubleshooting.

The policy has four building blocks. A Workstyle is the container, targeted by Filters (Account, Computer, or WMI). An Application Group bundles application definitions — the what. An Application Rule binds a group to an action — Allow, Elevate, Audit, or Block — plus the token treatment, an end-user Message, and an audit event. In the Policy Editor you will live at Windows > Workstyles > [Workstyle name].

The four words you will use in every EPM conversation

Tap each card — this vocabulary carries the whole lesson and most interview questions.

🗂️
Workstyle
tap to flip

The container: rules + messages + TAP + filters, aimed at a user/computer population. Evaluated top-down; first match takes the app. So: order is policy.

📦
Application Group
tap to flip

A reusable bundle of app definitions matched by publisher, hash, path, command line, parent. So: define once, reuse in many rules.

⚖️
Application Rule
tap to flip

Group + action (Allow/Elevate/Audit/Block) + token change + message + audit. So: this line is where elevation actually happens.

💬
Message
tap to flip

The dialog the user sees: reason capture, authentication, challenge/response, or a branded block. So: messages are your riot insurance.

Now the part that separates EPM from every "make me admin" hack: elevation happens at the application token. When a rule says Elevate, the agent launches that one process with a modified token carrying admin rights. The user typed no admin password — none exists for them — and they never see a UAC credential prompt, because EPM intercepts the elevation request and answers it with policy instead. The same trick runs in reverse for people who must stay admin: a drop-rights rule launches browsers and email with a reduced token, so even an admin reads mail at standard privilege.

👉 So far: Workstyle = container, Application Group = what, Application Rule = action + token + message, and the token — not the user — is what gets elevated. Next: how the agent picks WHICH rule.
Figure 2 — One launch through the agent — Workstyle list, then rule list
Flow of one application launch through the EPM agent. The agent walks the ordered Workstyle list: All Users does not match the rule set, High Flexibility matches the developer account filter and processing stops there. Inside that Workstyle the Application Rules run top down: the blocklist rule does not match, the Dev Installers rule matches on publisher certificate, and the action panel elevates the process token, shows the authentication and reason message, and raises an audit event. One launch through the agent — first match wins, twice karthik double-clicks node-v20-x64.msi EPM agent intercepts Avecto Defendpoint Service WORKSTYLE LIST (ordered, top-down) 1 · All Users filters match everyone — but no rule here matches this app → keep walking 2 · High Flexibility — account filter: IN-Developers ✓ MATCH processing STOPS here — Workstyles below never see this app 3 · Medium Flexibility · 4 · Low Flexibility — skipped (never evaluated) APPLICATION RULES inside it (also top-down) Block - Blocklisted Apps no match → next rule Add Admin – Dev Installers Publisher = OpenJS Foundation ✓ ACTION PANEL • Action: Elevate • admin added to the PROCESS token — user stays standard • Message: Authentication & Reason • Event raised → reporting installer runs elevated ✓ no admin password typed, nothing for a keylogger ⚠ Mis-order either list and the wrong rule eats every app — the classic EPM bug. untrusted/attackertrusted/vaultedpolicy/decisionkey insightallowed/audited
Follow the launch top to bottom: the agent walks the ordered Workstyle list and stops at the first whose filters match, then walks that Workstyle's Application Rules and stops at the first matching rule. Two ordered lists, two first-match-wins.

Pause & Predict

Predict: an application matches rules in BOTH the "All Users" Workstyle and the "High Flexibility" Workstyle below it. Which one acts, and what happens to the other? Type your guess.

Answer: Workstyles are evaluated in list order and the FIRST Workstyle that matches the application wins — "All Users" acts and "High Flexibility" never even sees the app. Nothing merges. The same first-match logic repeats inside Application Rules. This is why a block rule placed in the top Workstyle reliably beats a developer elevation rule below it — and why every weird EPM behaviour audit starts with checking list order.

How does an Application Group recognise an app? The matching criteria you will actually use: publisher certificate, file hash, file/folder path — plus refinements like product name, command line and parent process. Here is the judgement call that shows up in interviews: publisher beats path. A path rule ("elevate anything in C:\Installers") is one rename away from elevating malware. A hash rule is cryptographically exact but dies on every vendor update. A publisher rule — "signed by OpenJS Foundation" — survives updates and cannot be faked by renaming, because Authenticode signatures are verified, not guessed.

PowerShell (any endpoint) — harvest the publisher string for your Application Group
PS C:\> Get-AuthenticodeSignature 'C:\Installers\node-v20.11.1-x64.msi' |
>>   Format-List SignerCertificate, Status
# The CN= subject below is exactly the publisher value your app definition matches on.
Expected output
SignerCertificate : [Subject]
                      CN=OpenJS Foundation, O=OpenJS Foundation,
                      S=California, C=US
Status            : Valid
Figure 3 — Publisher vs hash vs path — pick the matching criterion deliberately
Three-column comparison of application matching criteria. Publisher certificate matching is cryptographically verified, survives app updates and is the production default. File hash matching is the strictest but breaks on every update, so it suits unsigned one-off binaries. Path matching is the weakest because any malware renamed into the allowed path inherits the rule, so it is only acceptable with extra checks like a Trusted Owner. How should the rule recognise the app? Publisher vs hash vs path Publisher certificate matches: who SIGNED the binary CN=OpenJS Foundation + survives every version update + cryptographically verified — renaming a file cannot fake it − needs a signed binary − trusts EVERYTHING that vendor signs — scope it VERDICT: production default — pair with product/command line File hash matches: this EXACT byte-for-byte file SHA-256: 9f86d08… + strictest possible match + works for unsigned binaries − breaks on EVERY update — monthly re-hashing toil − silent rule rot at scale VERDICT: unsigned one-offs and frozen legacy tools only File / folder path matches: WHERE the file sits C:\Installers\*.msi + zero maintenance + works for anything − SPOOFABLE: rename malware into the path → it inherits the elevation rule VERDICT: only user-unwritable paths + Trusted Owner checks Rule of thumb: publisher first · hash for the unsigned stragglers · path never alone
Read each column: what it matches, its strength (green +), its weakness (red −) and the verdict. Publisher is the production default; hash covers unsigned one-offs; path alone is an elevation hole waiting for a rename.
Quick check · Q2 of 10

Two Workstyles could both apply to Sneha's app launch — "All Users" (position 1) and "High Flexibility" (position 2). Which rules actually process the application?

Correct: a. Workstyles are evaluated in list order and processing stops at the first match for that application — there is no merging (b), no specificity scoring (c) and no recency rule (d). The identical first-match logic applies inside Application Rules too, which is why rule ORDER is the first thing to audit when EPM behaves strangely.

③ QuickStart day-1 baseline + one real rule end-to-end

Never start from a blank policy. BeyondTrust ships a QuickStart policy for Windows with four Workstyles already wired: All Users (everyone — the blocklist and safety net), High Flexibility (developers: signed apps allowed, unknown apps after a confirmation), Medium Flexibility (unknown apps elevate only after the user gives a reason) and Low Flexibility (fixed-task staff — unknown apps blocked with a support-desk message). It also ships named Application Groups — (Default) Any Application, Add Admin – General (Business Apps), Block - Blocklisted Apps, Passive - All Users Functions & Apps — and ready-made messages like Allow Message (Authentication & Reason) and Block Message.

Figure 4 — QuickStart ladder — map roles to flexibility tiers, then edit five things
The QuickStart for Windows template as a ladder. All Users applies to everyone with the blocklist and baseline protections. High Flexibility serves developers: signed applications are allowed and unknown applications run after confirmation. Medium Flexibility makes office users give a reason before unknown applications elevate. Low Flexibility is for fixed-task staff and points them to the support desk. A side checklist lists the minimum customization: authorization groups, branded messages, workstyle assignment, blocklist population, and challenge response shared keys. QuickStart for Windows — four Workstyles, one decision: who gets which? 1 · All Users everyone, always first: Block - Blocklisted Apps · passive baseline · the safety net 2 · High Flexibility — developers signed apps allowed · unknown apps run after a confirmation step · fewest prompts 3 · Medium Flexibility — office / power users unknown apps elevate only AFTER the user types a reason — friction with an exit 4 · Low Flexibility — fixed-task staff (counters, kiosks) most restrictive tier: unknown apps blocked, message points the user to the support desk ⚠ list order matters — All Users sits on top by design; first match wins Before go-live: minimum edits ☐ set authorization users/groups ☐ brand every message (logo, text) ☐ assign users → flexibility tiers ☐ populate Block - Blocklisted Apps ☐ set Challenge/Response shared key (≥15 chars) — or helpdesk can never answer the 8-digit code A wrong tier = riots (too strict) or holes (too loose). Map roles, not individuals, to tiers. Start from QuickStart, customise the 5 boxes, pilot on IT first — never from a blank policy
The four shipped Workstyles top-down, plus the minimum customization checklist before go-live. Note the trap in the last checkbox: Challenge/Response messages without a shared key strand your users at an 8-digit prompt nobody can answer.

QuickStart is a starting point, not a finish line. The vendor's own minimum-edit list: set the authorization users/groups, brand every message, assign users to flexibility Workstyles, populate the blocklist, and configure the Challenge/Response shared keys. That last one is the most-skipped: the key is set at Policy Editor → Messages → Challenge/Response Keys → Set Key (use ≥15 mixed characters). Think of it as Aadhaar-OTP-by-phone: the screen shows an 8-digit challenge, the user calls the helpdesk, the helpdesk computes the 8-digit response from the shared key — a fresh challenge every display, so yesterday's code is useless. It even works with the laptop offline.

Pause & Predict

Predict: you deploy QuickStart with Challenge/Response messages enabled but never visit Messages → Challenge/Response Keys. What do users and the helpdesk experience? Type your guess.

Answer: Users hit the 8-digit challenge prompt as designed — but the helpdesk can NEVER produce a valid response, because the response is computed from the shared key that was never set. Every elevation that routes through that message dead-ends, tickets pile up, and the rollout gets blamed. Fix: Set Key (≥15 chars) before go-live and share it only with authorizers. This is gotcha #1 in real QuickStart deployments.

One real rule, end to end: Karthik's Node.js installer

Scenario: Karthik, a developer at Wipro (laptop 10.20.34.57), must run the Node.js installer every month. He is a standard user in the IN-Developers AD group. Here is the rule a senior admin builds — every step, no skipping. Step 1 — identify the app properly: run Get-AuthenticodeSignature against the MSI (you saw this in section ②) and copy the publisher subject, CN=OpenJS Foundation. Step 2 — make the WHAT: in the Policy Editor create an Application Group Add Admin – Dev Installers (Wipro) and add an MSI definition matching that publisher — optionally tightened with a product-name check. No path matching, no hash churn.

Step 3 — bind the rule: in Windows > Workstyles > High Flexibility, add an Application Rule: target the new group, action Elevate (the process token gets admin rights added), end-user message Allow Message (Authentication & Reason) — Karthik re-authenticates and types why — and auditing on, so the event lands in reporting with his reason attached. Step 4 — order it: drag the rule above any rule that uses (Default) Any Application; first match wins, and the catch-all must stay the last resort. Step 5 — save, deploy to the pilot group, and make Karthik install Node while you watch the event arrive.

🖥️ This is the screen where the rule comes together — Policy Editor → Windows → Workstyles → High Flexibility → Application Rules. (Recreated for clarity — your console matches this.)
epm.beyondtrustcloud.com · Policy Editor › High Flexibility
1
Target Application Group
Add Admin – Dev Installers (Wipro)
2
Action
Elevate
3
End User Message
Allow Message (Authentication & Reason)
4
Raise an Event (auditing)
On
Rule position
Above '(Default) Any Application' rules
Save

▶ One double-click through the EPM agent

Watch Karthik's installer travel from launch to elevated token — then see how a lazy path-matched rule turns the same flow into an attacker's elevator. Press Play for the healthy path, then Break it to see the failure.

① Launchkarthik (standard user) double-clicks node-v20-x64.msi — no admin account exists on this laptop
② Matchagent walks Workstyles → High Flexibility → rule matches publisher CN=OpenJS Foundation
③ MessageAllow Message (Authentication & Reason) → karthik re-authenticates + types why
④ Tokenprocess launched with admin rights added to ITS token → installs · audit event raised
Press Play to step through the healthy path. Then press Break it.
👉 So far: QuickStart gives four tiers + named groups + messages; a real rule = publisher-matched group → Elevate + reason message + audit, ordered above the catch-all. Next: the right-click path — on-demand elevation.

What about apps you never predicted? That is on-demand elevation: On-Demand Application Rules hook the right-click menu and can override the native Run as administrator entry — same label, but the click now lands in EPM, which answers with your message (reason + authentication + audit) instead of a UAC credential prompt. Done right, on-demand elevation targets a defined Application Group with a reason-capture message — never (Default) Any Application with a silent allow, which would be self-service admin with extra steps.

Sneha at Infosys faces this

Pilot laptop 10.20.34.81: right-click → Run as administrator on the test installer shows the NATIVE Windows UAC password prompt instead of the branded EPM dialog. Auto-elevation rules and blocks on the same machine work fine.

Likely cause

Fresh agent install with no reboot — the on-demand shell-integration hook only registers after a restart (a known fresh-install behaviour on EPM Windows 24.x), so the right-click path still belongs to Windows while everything else already follows policy.

Diagnosis

Confirm both endpoint services are Running and policy has arrived, then check the machine's last reboot time against the agent install time. The on-demand rule itself is present and enabled — the context-menu hook just is not registered yet.

Policy Editor > Windows > Workstyles > High Flexibility > On-Demand Application Rules (rule present + enabled)
Fix

Reboot the laptop and re-test. Then bake a mandatory restart into the agent deployment package (SCCM/Intune) so no pilot user ever tests on-demand elevation pre-reboot.

Verify

Right-click → Run as administrator now opens the EPM Allow Message (Authentication & Reason); the elevation event appears in reporting with Sneha's reason text and the publisher of the installer.

Quick check · Q3 of 10

Priya at ICICI rolled out QuickStart. Users hit an 8-digit challenge prompt when elevating, but the helpdesk cannot generate any working response code. What was missed?

Correct: d. Responses are computed from the shared key; if Set Key was never done, no valid response can exist — exactly the documented QuickStart trap. Challenge/Response deliberately works offline (a is backwards), there is no 60-second typing window (b), and Workstyle assignment would change WHICH message appears, not break code generation (c).

④ Beyond elevation — TAP, Power Rules, PM Cloud deploy and the Mac side

Elevation control is half of EPM; the other half is application control. The same rule machinery blocks what should never run (Block - Blocklisted Apps), allows-without-elevating the everyday estate, and — before any of that — can run in audit-only passive mode so you discover what your fleet actually launches before you enforce anything. Smart teams run passive for two to four weeks and let the event data write the policy for them.

Then there is the feature that wins security-team hearts: Trusted Application Protection (TAP). Word, Excel, Outlook, Adobe Reader and the browsers are VIPs who meet strangers all day — every document and webpage is untrusted input. TAP is their bodyguard: the VIP app keeps running, but when a macro makes Word spawn cmd.exe or PowerShell, TAP frisks the child process — no trusted publisher or Trusted Owner, no entry. Untrusted DLL loads get the same treatment. Two shipped flavours: High Security validates all child processes; High Flexibility validates only immediate children, so more installer chains survive.

Quick check · Q4 of 10

Meera's user at Flipkart opens a poisoned .docx and the macro tries to launch cmd.exe. With TAP enabled, what happens?

Correct: b. TAP's whole design is to let the trusted VIP app live while blocking its untrusted children and DLL loads — so Word survives, cmd.exe dies, and reporting captures the parent-child pair. It never kills the parent app (a), never asks for admin credentials (c), and covers child processes AND DLLs, not DLLs alone (d).

Meera at Flipkart faces this

After enabling the TAP High Security template, users report downloaded installers 'die silently' — double-click, nothing. A line-of-business add-in installer launched from an Outlook attachment also fails, with no block message anyone recognises.

Likely cause

High Security TAP validates EVERY process in the chain spawned from protected apps (Outlook, browsers). The vendor's installer chain includes an unsigned helper executable, so TAP kills it mid-chain — silently from the user's point of view.

Diagnosis

Pull the TAP block events in reporting: each names the protected parent (outlook.exe, chrome.exe) and the exact child binary that failed validation — the unsigned helper shows up immediately.

Policy Editor > Windows > Workstyles > [Workstyle] > Trusted Application Protection (template: High Security vs High Flexibility)
Fix

Switch the pilot population to the High Flexibility TAP template (validates immediate children only), or keep High Security and add the vendor's publisher certificate / Trusted Owner so the chain passes validation.

Verify

Re-run the same download — the installer completes. Then prove TAP still works: a macro test-doc spawning cmd.exe from Word is still blocked and logged.

When yes/no rules are not clever enough, Power Rules are the escape hatch: a PowerShell script (3.0 or later) attached via Run a Rule Script changes the rule's outcome at run time. Real uses: elevate only if a valid change ticket exists, only inside a maintenance window, or only after an API reputation check. You develop against the PRTestHarness module, which stubs the agent with mock data, and ship with the PRInterface module on the endpoint. Encrypted JSON settings files (UTF-8) carry credentials safely alongside the script.

PowerShell — confirm the Power Rules toolkit (PRInterface module) on a dev box
PS C:\> Get-Command -Module PRInterface | Select-Object -First 6 -ExpandProperty Name
Expected output
ConvertTo-PRHashTable
Get-PRChallengeCode
Get-PREnvironmentVariable
Get-PRFileHash
Get-PRScriptSettings
Get-PRVariable
👉 So far: passive discovery → allow/block lists → TAP for Office/browser children → Power Rules for run-time logic. Next: actually shipping policy from PM Cloud, and the Mac story.

Shipping the policy: in the PM Cloud console the left-menu Policies page owns the lifecycle. Create Policy (from the QuickStart template or an uploaded XML) → Edit & Lock Policy → make your changes across the editor sections (Workstyles, Application Groups, Content Groups, Messages, Custom Tokens, Utilities) → Save & Unlock, which mints a new revision. Nothing has reached an endpoint yet. Deployment is the separate, deliberate step: Assign Policy to Groups → pick the revision → pick computer group(s) → Assign Policy. Agents pull it on their next IC3Adapter check-in. Upload Revision offers Merge Policy or Overwrite Policy — read twice before clicking, one of them replaces everything.

🖥️ The deploy screen — PM Cloud → Policies → ⋮ menu → Assign Policy to Groups. A revision does nothing until this step. (Recreated for clarity — your console matches this.)
epm.beyondtrustcloud.com · Policies
1
Policy
WIPRO-EPM-Baseline
2
Policy action
Assign Policy to Groups
3
Revision
Revision 12 (latest)
4
Computer Group
IN-Developers (1,240 computers)
Other actions
Edit & Lock Policy · Upload Revision · Compare Policies
Assign Policy

Pause & Predict

Predict: you just clicked Save & Unlock on your edited policy in PM Cloud. Has anything changed on the 1,240 developer laptops yet? Type your guess.

Answer: No. Save & Unlock only creates a new REVISION in the console. Endpoints change only after Assign Policy to Groups pins that revision to their computer group, and each agent pulls it on its next IC3Adapter check-in. This two-step design is a feature: you can build and diff revisions (Compare Policies) safely, then deploy deliberately — and roll back by assigning the previous revision.
VERIFY — endpoint-side health in 60 seconds

Policy 'not arriving' is services or precedence 90% of the time, not the console. Check, in order: both services running (Avecto Defendpoint Service + BeyondTrust Privilege Management Cloud Adapter/IC3Adapter), the registry key HKLM\SOFTWARE\Avecto\Privilege Guard Client present, and — in multi-policy GPO setups — remember policies apply in alphanumeric order, so a forgotten pilot named AAA-Test silently beats Corp-Baseline. Rename or retire test policies; do not debug ghosts.

PowerShell (endpoint) — the 60-second health check
PS C:\> Get-Service -DisplayName 'Avecto Defendpoint Service',
>>   'BeyondTrust Privilege Management Cloud Adapter*' | Select-Object Status, DisplayName
PS C:\> reg query "HKLM\SOFTWARE\Avecto\Privilege Guard Client"
Expected output
 Status DisplayName
 ------ -----------
Running Avecto Defendpoint Service
Running BeyondTrust Privilege Management Cloud Adapter

HKEY_LOCAL_MACHINE\SOFTWARE\Avecto\Privilege Guard Client

Reporting closes the loop: every elevation, block and TAP event carries the user, machine, application name/path/publisher/hash, the action taken, the matching rule and any justification text the user typed — and hash checks can be enriched with VirusTotal lookups. This is the data that turns week-one passive mode into week-four policy, and the evidence trail your auditor will ask for. One hygiene note from the advisory desk: the agent itself is software — BeyondTrust's BT25-05 advisory covers CVE-2025-2297, a privilege-elevation flaw in EPM for Windows itself (CVSS 4.0 7.2 per the vendor advisory), fixed in 25.4.270.0. An out-of-date least-privilege agent is an irony nobody needs; patch it like any other security product.

And the Macs in the corner?

The Mac story rhymes with Windows but speaks macOS. There is no UAC; the pain points are the installer authorization prompt ("enter an administrator's name and password") and sudo in Terminal. EPM for Mac lets a standard user run approved installers and system-preference changes through policy-driven authorization — reason capture and audit included, no admin credentials typed — and brings sudo under policy control instead of handing out admin accounts. Policy is authored in the same Policy Editor under macOS Workstyles and deployed from the same PM Cloud console, so one mental model covers the whole desk fleet. The agent ships via Jamf/Intune the same way SCCM carries the Windows MSI.

Figure 5 — Pocket card — policy anatomy, endpoint checks, deploy chain
Three-column cheat sheet. Column one shows the policy tree: ordered Workstyles containing Application Rules, On-Demand Application Rules, Trusted Application Protection, General Rules and Filters, fed by Application Groups whose match priority is publisher then hash then path, with actions Allow, Elevate, Audit, Block. Column two lists the QuickStart messages, the challenge response facts, and the endpoint health checks: two services, the Avecto registry key, and the reboot rule for on-demand rules. Column three shows the PM Cloud deploy chain from Create Policy through Edit and Lock, Save and Unlock, to Assign Policy to Groups, plus Mac notes and Power Rules. EPM Windows/Mac — pocket card POLICY TREE Policy → Workstyles (ordered!) ├ Application Rules (top-down) ├ On-Demand App Rules (right-click) ├ Trusted Application Protection ├ General Rules (Windows) └ Filters: Account · Computer · WMI Application Groups (the WHAT) match: Publisher > Hash > Path + product · command line · parent Rule actions Allow · Elevate · Audit · Block Token trick elevate the PROCESS token — user stays standard, no UAC password prompt, no admin cred ⚠ first match wins — twice: Workstyle list AND rule list. Keep (Default) Any Application at the BOTTOM, always. MESSAGES & ENDPOINT QuickStart messages Allow (Authentication & Reason) Allow (Select Reason) · (Yes / No) Allow (Support Desk) · Block Msg Challenge / Response (offline OK) 8-digit codes · unique per display shared key ≥15 chars · set at: Messages > Challenge/Response Keys > Set Key Endpoint health (check in order) 1 · Avecto Defendpoint Service 2 · BT PM Cloud Adapter (IC3) 3 · HKLM\SOFTWARE\Avecto\ Privilege Guard Client ⚠ fresh install + no reboot = right-click elevation shows native UAC. Reboot before you test. Multi-policy GPO tie-break: alphanumeric order — AAA-Test wins PM CLOUD DEPLOY + MAC Deploy chain (nothing ships early) Policies → Create Policy → Edit & Lock Policy → edit → Save & Unlock (= new revision) → Assign Policy to Groups ✓ Upload Revision: Merge / Overwrite Power Rules (the escape hatch) PowerShell 3.0+ · PRInterface script changes the rule outcome PRTestHarness = offline dev/debug macOS in one breath standard users run approved installers — no admin creds typed sudo control · same Policy Editor (macOS Workstyles) TAP: Office/browsers stay running; their UNTRUSTED child processes and DLLs get blocked Patch the agent too — BT25-05 (CVE-2025-2297) fixed in 25.4.270.0
Screenshot this one. Left: the policy tree and the first-match-wins warning. Middle: QuickStart messages, Challenge/Response facts and the endpoint health checklist. Right: the PM Cloud deploy chain, Power Rules, TAP in one breath and the Mac summary.
🎮 Hands-on: BeyondTrust PAM Essentials room📘 PRA Auditing & Hardening
👉 Wrap-up: discover passively → QuickStart tiers → publisher-matched elevation rules with reason + audit → TAP on the VIP apps → deliberate revision-based deploys — that is endpoint least privilege without the riots.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from BeyondTrust docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Which two Windows services must be running for an EPM endpoint to enforce policy and pull updates from PM Cloud?

Correct: b. The enforcement agent still carries its heritage name — Avecto Defendpoint Service — and the IC3Adapter handles PM Cloud check-in/policy pull; these two are the documented minimum. Defender/WinRM (a) are unrelated, BeyondInsight/Password Safe agents (c) belong to the vault product line, and 'Privilege Guard Client' (d) is a registry path, not a service.
Q6 · Apply

Karthik's team updates Node.js every month. Which matching criterion keeps the elevation rule working across versions WITHOUT monthly edits — and why?

Correct: c. A publisher match validates the cryptographic signature, so every properly signed new version passes with zero rule edits. Hash (a) breaks on every release — monthly toil. A Downloads-folder path (b) is user-writable, so renamed malware would inherit elevation. Product name alone (d) is metadata an attacker can copy; use it only as a refinement on top of publisher.
Q7 · Apply

You install the EPM agent on a pilot laptop and immediately test right-click → Run as administrator. The NATIVE Windows UAC prompt appears instead of the EPM message, though block rules already work. What is the first fix?

Correct: a. This is the documented fresh-install behaviour: most policy enforcement starts immediately, but the right-click on-demand hook needs a restart to register — so reboot, then re-test. Reinstalling (b) repeats the same state, disabling UAC (c) weakens the platform EPM builds on, and re-adding admin (d) defeats the entire project.
Q8 · Analyze

After Priya edits the policy, previously-blocked apps run and elevations stop prompting. Event data shows nearly every application matching ONE rule. What most likely happened?

Correct: d. Application Rules stop at the first match; a catch-all group dragged to the top matches every launch, so the specific block/elevate rules underneath never evaluate — which exactly matches 'one rule matches everything' in the events. A crashed agent (a) would not produce rule-match events, licensing (b) does not flip rules to Allow, and TAP (c) adds child-process blocking rather than overriding rule order.
Q9 · Analyze

Two EPM policies reach the same machine via GPO: an old pilot named 'AAA-Test' and the new 'Corp-Baseline'. Users keep getting pilot-era prompts. Why?

Correct: b. Multi-policy precedence is alphanumeric — a name starting 'AAA' silently outranks 'Corp', and since Workstyles are first-match-wins, the pilot's rules answer first. There is no newest-wins rule (a), GPO can deliver multiple policies (c), and there is no pilot-priority flag (d). The operational fix: retire or rename test policies the day the pilot ends.
Q10 · Evaluate

Infosys must remove local admin from 5,000 laptops in one quarter. Which rollout plan earns the FEWEST riots and the MOST security?

Correct: c. Discovery-first means the rules exist BEFORE rights disappear, role-mapped tiers keep developers productive, and on-demand + Challenge/Response handle the unpredicted cases — security up, tickets down. Overnight removal (a) is the classic riot; permanent dev admins (b) leaves the highest-risk population exposed; a shared admin password (d) recreates the credential problem PAM exists to kill.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: Your CISO asks: if we take local admin away, how will engineers install anything? Give the two-line EPM answer. Then compare to the expert version.

Expert version: We are not removing the capability, we are moving it: the EPM agent elevates approved applications at the process-token level, so an engineer's installer runs with admin rights while the engineer stays a standard user — with a reason captured and an audit event for every elevation. Unknown apps still have an exit: on-demand elevation or a challenge/response code from the helpdesk, so work never stops, but no human holds an admin password that ransomware can inherit.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Workstyle
EPM policy container (rules + messages + TAP + filters) targeted at users/computers; first matching Workstyle in the list wins.
Application Group
Reusable bundle of application definitions — the WHAT a rule acts on — matched by publisher, hash, path, command line or parent.
Application Rule
Binds an Application Group to an action (Allow/Elevate/Audit/Block) plus token change, end-user message and audit event.
On-Demand Application Rule
Rule fired from the right-click menu; can override the native 'Run as administrator' entry with EPM's policy flow.
Access token
Kernel object listing a process's identity and privileges; EPM elevates by launching the process with a modified token.
Avecto Defendpoint
Heritage name of EPM for Windows/Mac — still the literal name of the endpoint service and registry path.
IC3Adapter
BeyondTrust Privilege Management Cloud Adapter — the endpoint service that checks in to PM Cloud and pulls policy revisions.
QuickStart policy
Vendor starter policy: All Users + High/Medium/Low Flexibility Workstyles, named groups and ready-made messages.
Challenge/Response
Offline approval: 8-digit challenge on screen, helpdesk computes the 8-digit response from a shared key (≥15 chars, set in Messages).
Trusted Application Protection (TAP)
Enhanced Security layer that lets Office/Adobe/browsers run but blocks their untrusted child processes and DLL loads.
Power Rules
PowerShell (3.0+) scripts on an Application Rule that change its outcome at run time via the PRInterface module.
PM Cloud
The EPM SaaS console: Policies → Create/Edit & Lock → Save & Unlock (revision) → Assign Policy to Groups → agents pull via IC3Adapter.

📚 Sources

  1. BeyondTrust EPM Windows/Mac docs — Workstyles: components, evaluation order, filters. docs.beyondtrust.com/epm-wm/docs/workstyles
  2. BeyondTrust EPM docs — QuickStart for Windows template (Workstyles, Application Groups, Messages, customization checklist). docs.beyondtrust.com/epm-wm/docs/gpo-quickstart-templates
  3. BeyondTrust EPM docs — Policies page in PM Cloud (Create Policy, Edit & Lock, Assign Policy to Groups, revisions). docs.beyondtrust.com/epm-wm/docs/policies
  4. BeyondTrust EPM docs — On-Demand Application Rules (right-click integration, Run-as-administrator override). beyondtrust.com/docs/privilege-management/windows/admin/windows-policies/workstyles/application-rules/on-demand-app-rules.htm
  5. BeyondTrust EPM docs — Messages & Challenge/Response keys (8-digit codes, Set Key, ≥15-char shared key). docs.beyondtrust.com/epm-wm/docs/policy-messages
  6. BeyondTrust blog — Trusted Application Protection (Office/Adobe/browser child-process and DLL control). beyondtrust.com/blog/entry/trusted-application-protection
  7. BeyondTrust EPM docs — Power Rules & core scripting (PRInterface cmdlets, PRTestHarness, PowerShell 3.0+). docs.beyondtrust.com/epm-wm/docs/epm-for-windows-core-scripting
  8. BeyondTrust Beekeepers community — fresh-install on-demand rules trigger native UAC until reboot; minimum services + Avecto registry key. beekeepers.beyondtrust.com (EPM Windows threads 5826, 5652)
  9. Security Scientist — 12 Q&A on Privilege Management for Windows & Mac (de-elevation, deployment via SCCM/Intune/JAMF, VirusTotal enrichment). securityscientist.net/blog/12-questions-and-answers-about-beyondtrust-privilege-management-for-windows-and-mac/
  10. Microsoft Learn — Configuring additional LSA protection (why LSASS credential dumping needs admin). learn.microsoft.com/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

What's next?

Windows and Mac are tamed — but your Linux servers still have engineers typing 'sudo su -' like it's 2009. Next lesson: pbrun, centralized policy and replayable terminal sessions with Privilege Management for Unix/Linux, plus AD Bridge to give Linux boxes an Aadhaar-style single identity.