Policy overhaul
Policies rebuilt around the applications and admin tasks the IT team manages, with an application allowlist and blocklist in place.
Local admin removed from a retailer's laptops, without the help-desk flood
Most laptops still let the person using them install anything and change anything, because taking admin rights away usually means a help desk buried in requests. A US specialty retailer asked our engineers to remove those rights without that happening. This is how it was done: policies rebuilt around real tasks, every elevation raised and approved in ServiceNow, and every event sent to the team that watches.
Standing local admin removedEvery elevation ticketedAlerts in the existing pipelineCyberArk EPM
Close-out: endpoint privilegeApplied IAM
- Policy set rebuilt around real tasksPolicy overhaul
- Every elevation raised and approved in ServiceNowJust-in-time
- Events sent to the existing detection pipelineAlerts
- Standing administrator rights withdrawnLocal admin
- EPM on CyberArk's shared platform tenantMigration
Five pieces of work, delivered together.
The starting point
Everyone was an administrator on their own machine
Before the project, users held standing administrator rights on their endpoints. Software could be installed outside the IT team's control, and any malware a user ran inherited full administrative privilege along with it. The endpoint privilege policies that did exist were broad catch-all rules, not rules written for the applications and tasks people actually needed.
The brief was to take those rights away without leaving people stuck, which is why it became five pieces of work, delivered together.
What was delivered
Five pieces of work, all in production
Just-in-time elevation
Elevation requests raised, approved and logged as ServiceNow tickets.
Alert integration
EPM alerts routed into the detection pipeline the security team already runs.
Local admin removed
Standing administrator rights withdrawn from endpoints.
Platform migration
EPM moved onto CyberArk's shared Identity Security Platform tenant.
Policy overhaul
Elevation granted to the task, not the person
- Rebuilt around real work. The policy set was rewritten around the applications and administrative tasks the IT team manages, replacing broad catch-all rules.
- The task is elevated, not the account. A user running an approved task gets the rights that task needs. Their account stays standard.
- Known-good and known-bad kept apart. An application allowlist and blocklist sit alongside the elevation rules.
- Staged by group. Policies are applied by endpoint group, so a change rolls out in controlled stages rather than to everyone at once.
Elevation policy, as deliveredApplied IAM
- Approved taskElevated by policy
- Known-good applicationAllowlist
- Known-bad applicationBlocklist
- The user account itselfStays standard
Just-in-time elevation
Every elevation is a ServiceNow ticket with an expiry
Anything a policy does not already cover goes through one route, and it is the route the IT team already works in.
1User requests elevationEPM prompt on the endpoint
request
2ServiceNow ticket raisedRequest captured with context
ticket
3Approval appliedThe approver's decision
decision
4Elevation grantedRights expire with the request
rights
5Action loggedTicket and EPM record retained
Privilege lasts only as long as the approved request, so no account carries elevation between tasks. Every grant leaves a ticket record for audit.
Alert integration
Endpoint events go where the security team already looks
EPM elevation, block and threat events now flow into the retailer's existing log pipeline, which routes, filters and enriches them before they reach the security operations tooling for detection and review.
The alerts leave EPM in a format that pipeline already consumes, so nobody has a separate console to watch. Elevation and block events are correlated with the rest of the security telemetry, and the event history is kept outside EPM for investigation and reporting.
01EPMElevation, block and threat events
events
02Log pipelineRouting, filtering and enrichment
enriched
03Security operations toolingDetection and review
Local admin removed
What changed on the endpoint
BeforeStanding admin
Users held standing administrator rights on their endpoints.
- Software could be installed outside the IT team's control
- Malware a user ran inherited full administrative privilege
AfterStandard accounts
Users operate as standard accounts.
- Approved tasks elevate through policy or a ticketed request
- Malware runs without administrative privilege
Platform migration
EPM now runs on CyberArk's shared platform
Endpoint privilege moved off its standalone console and onto the Identity Security Platform tenant, where it shares identity and audit services with the rest of the platform.
- One console. The tenant is activated, and EPM is reached through the single platform console alongside the other services on it.
- Shared identity administration. Users and roles are assigned through the platform's identity administration, not an EPM-only set.
- API access moved with it. API authentication now runs through Identity Administration, with service account support.
- MFA on the console. Console access is secured with multi-factor authentication.
Handover
What the retailer's team now runs
Ongoing operation of the platform has transferred to the retailer.
Policy administration
Policy sets, elevation rules and endpoint group membership.
ServiceNow workflow
Elevation request intake, approval routing and closure.
Alert routing
Alert forwarding and the downstream detection rules.
Documentation
Configuration records and operating procedures, delivered.
What comes next
Three recommended next steps
Per-department policies
Replace the IT-wide policy set with policies written per department: profile elevation demand by department, draft and pilot departmental policy sets, then roll out while keeping the shared allowlist.
Agent upgrade automation
Keep EPM agents current without manual intervention: define upgrade rings and a schedule, automate distribution and reporting, and track version compliance centrally.
Restrict internet downloads
Let downloaded software run only when it comes from a known publisher: baseline the publishers already in use, block unsigned and unknown-publisher installers, and route exceptions through the ticketed request flow.
Repeatable?
Where this applies
Anywhere users still hold local admin because taking it away felt too disruptive. The pattern is the one used here: policies written for real tasks, a ticketed route for everything else, and events sent to the people who watch. The same engineers delivered the PAM platform work for this retailer. For what EPM does on its own, see the CyberArk modules; for how an engagement runs, PAM implementation; and for the sector, identity security for retail.
Find out who still has admin on their own machine
A free audit is 30 minutes with a certified engineer on your own environment, with the findings in writing. No cost, no obligation.