Before removing local admin rights, find out how often anybody actually elevates. There is a report for that.
Endpoint Privilege Management reports unmanaged elevations, meaning every time somebody used Run as administrator without it, before you change anything. Then it lets standard users run the specific things that genuinely need elevation, through an isolated virtual account that is never added to the local administrators group.
- WindowsThe supported platform
- Five typesAutomatic, user confirmed, current user, approved, deny
- Virtual accountIsolated, and not a local administrator
- exe, msi, ps1The file types it elevates
Audit first, then rules, then removal. Not the other way round.
Microsoft describes the deployment step as enable auditing, create rules, and monitor. That sequence is the whole difference between a project that lands and one that gets reversed in the second week.
- Enable the unmanaged elevation reporting while everybody still has their administrator rights. For a few weeks you simply collect evidence of what people are actually elevating, which in most organisations turns out to be a much shorter list than anyone predicted.
- Build rules for the things that appear repeatedly and are legitimate. Publisher certificate matching, argument constraints and child process controls make those rules specific enough to be safe rather than a broad permission that undoes the point of the exercise.
- Set the default elevation response and add support approved as the catch-all, so that anything you did not anticipate becomes a request somebody handles rather than a blocked user with no route forward. That is what prevents the flood of complaints on day one.
- Only then remove local administrator rights, and do it in waves. Because the rules were written from observed behaviour rather than from a guess, the population that gets moved first is the one you already have evidence for.
Eight things about Endpoint Privilege Management that decide how you deploy it.
The unmanaged elevation report, which comes before any change
Microsoft provides reporting on unmanaged elevations, meaning all file elevations happening without Endpoint Privilege Management, such as when a user with administrative rights uses the Windows Run as administrator action. Turning that on before removing anybody rights tells you exactly what would break, which converts the whole project from an argument into a list.
A virtual account, not membership of the administrators group
For most elevation types the service uses a virtual account isolated from the logged-on user account, and Microsoft states plainly that neither of these accounts is added to the local administrators group. That is the security property the whole product rests on: the elevated process runs with administrative capability without any account gaining standing administrative membership.
User confirmed, which is where most rules should start
Users get a right-click context menu option to run with elevated access, and administrators can require extra validation through an authentication prompt, a business justification, or both. That combination gives you a record of what was elevated and why, without anybody waiting for approval, and it is the type that produces the most useful data during a rollout.
Support approved, for the cases that warrant a person
The user submits a request to run an application with elevated permissions, an administrator approves it, and the user is notified they can retry the elevation on the device. This is the right type for the long tail of unusual requests, and it means you do not have to write a rule in advance for every possible legitimate need.
Automatic, with an explicit warning attached
Automatic rules elevate applications without any input from the user, which is right for well-understood cases such as an approved installer. Microsoft attaches a specific caution: broad rules in this category can have widespread impact on the security posture of the organisation. Automatic is the type to use narrowly and deliberately, not the default.
Elevate as current user, and why to avoid it where you can
This type runs the elevated process under the signed-in user own account rather than the virtual account, preserving compatibility with tools that depend on the user profile, and it supports Windows Authentication requiring reauthentication before elevation. Microsoft states it introduces a broader attack surface and reduces isolation from user data, and advises using it only where virtual account elevation causes application failures.
Rules that can be specific enough to be safe
Rules can be built on file name, path and other attributes, with child process controls governing what an elevated application can spawn, argument support allowing only certain parameters, file hash matching, and publisher certificate matching. A rule based on publisher certificate plus argument constraints is a materially different thing from a rule that says any file called setup.exe.
Deny rules, which are the part people forget exists
A deny rule identifies a file that Endpoint Privilege Management blocks from running in an elevated context. Microsoft frames it as ensuring known or potentially malicious files cannot run elevated. It is the complement to the allow rules and it is worth building alongside them rather than as an afterthought once something has already run.
Four things that stop this becoming the project everybody remembers badly.
We audit before we remove anything
Microsoft own deployment guidance starts with enabling auditing. We run the unmanaged elevation reporting while everybody still has their rights, so the rules are written from what people actually elevate rather than from what anybody assumed. In most organisations the real list is short, specific and much less alarming than the debate that preceded it.
We prefer the virtual account and say why
Most elevation types use a virtual account isolated from the user account, and neither account is added to the local administrators group. Elevate as current user gives that up. Microsoft advises using it only where virtual account elevation causes application failures and scoping it tightly, and we hold that line rather than reaching for it whenever something is awkward.
We write rules specific enough to be worth having
A rule matching a file name is close to giving the right back. Publisher certificate matching, file hash matching, argument constraints and child process controls are what make a rule a genuine control. Writing them takes longer and it is the difference between least privilege and a differently shaped administrator right.
We give people a route before we close the old one
Support approved requests, a defined approver and an agreed response time, all working before rights are removed. The reason these projects get reversed is never the technology, it is a senior person blocked at an inconvenient moment with no way forward. Having the route in place first removes that failure mode entirely.
Six UAE situations where standing administrator rights are the real exposure.
A regulated firm asked about least privilege
Banks, finance companies, insurers and DIFC or ADGM entities are examined on whether users run with least privilege. Endpoint Privilege Management answers it with a working control and detailed logging of every elevation, rather than a policy statement contradicted by the actual membership of the local administrators group.
An organisation where everybody has admin because of two applications
The most common situation we find. Two pieces of software need elevation, nobody wanted to solve it properly, and so the whole company runs as administrator. Rules for those two applications, matched on publisher certificate, resolve a decade-old exposure in an afternoon of configuration.
Engineering or design teams with specialist software
Computer-aided design, engineering and production software frequently needs elevation for licensing, drivers or plug-ins, and the users are technical enough to have argued successfully for administrator rights. User confirmed elevation with justification gives them what they need and gives you a record, which is a better outcome for both sides.
Education, where shared devices meet varied software
Teaching staff install what a lesson requires, laboratory machines run specialist tools, and the estate is large. Support approved elevation with a defined approver handles the variety without either granting rights broadly or making the IT team the obstacle to teaching.
After a ransomware incident or a near miss
Where malware ran and had administrative rights immediately because the user did, the exposure is obvious in retrospect and the appetite for change is briefly high. This is the moment when the project is easiest to fund, and the audit phase gives you the evidence to do it without a fight.
An organisation preparing for ISO 27001 or SOC 2
Both examine privileged access on endpoints. Every elevation being logged with detailed metadata, deny rules preventing specific files from elevating, and reporting distinguishing managed from unmanaged elevation is exactly the evidence those examinations ask for, produced as a by-product of the control operating normally.
How local administrator rights are actually handled in UAE organisations.
| Feature | EPM deployed | Admin rights for some | Admin rights for everybody |
|---|---|---|---|
Users run as standard users | Yes | Partly | No |
Elevation possible where genuinely needed | Yes | Yes | Yes |
Every elevation logged with metadata | Yes | No | No |
Elevation isolated from the user account | Yes | No | No |
Specific applications can be blocked from elevating | Yes | No | No |
Approval possible for unusual requests | Yes | Not applicable | Not applicable |
Malware inherits administrative rights on execution | No | For some users | Yes |
Evidence available for an auditor | Strong | Weak | None |
Helpdesk burden from blocked installs | Managed | Moderate | None, and that is the problem |
Frequency in the UAE market | Rare | Common | Common in SMEs |
Which type to use, and what each one costs you.
| Type | Behaviour and where it belongs | |
|---|---|---|
| User confirmed | Right-click run with elevated access, optionally with authentication and justification. The backbone of most configurations. | |
| Support approved | User requests, administrator approves, user retries. The catch-all for what you did not anticipate. | |
| Automatic | Elevates with no user input. Narrow, well-understood cases only. Microsoft warns broad rules here affect security posture. | |
| Elevate as current user | Runs under the user own account. Only where virtual account elevation breaks the application. Broader attack surface. | |
| Deny | Blocks a file from running elevated at all. Build these alongside the allow rules, not afterwards. | |
| Default elevation response | Configured in the elevation settings policy, applying where no specific rule matches. |
Five steps, and the audit phase is the longest one.
- 1
Licence, and confirm the platform scope
Endpoint Privilege Management must be licensed in the tenant before policies can be used, and it comes through Intune Plan 2, the Intune Suite or select Microsoft 365 bundles. Microsoft states it applies to Windows, so the scope is your Windows estate and any Apple or Android devices are a separate conversation.
- 2
Deploy the client and enable auditing, changing nothing
The client installs automatically when an elevation settings policy is assigned. Reporting on unmanaged elevations then runs while everybody still holds their rights, for a few weeks, producing the evidence of what is actually being elevated across the estate rather than what anybody believes.
- 3
Write rules from the evidence
For the applications that appear repeatedly and are legitimate, matched on publisher certificate or file hash where possible, with argument constraints and child process controls where they add safety. Deny rules for anything that should never run elevated, built at the same time rather than later.
- 4
Set the default response and the approval route
The default elevation response in the settings policy, plus support approved as the catch-all with a named approver and an agreed response time. This is the safety net that prevents the first unanticipated case becoming the reason the project stops.
- 5
Remove rights in waves, then keep the rules current
Starting with the population you have the clearest evidence for, then widening. Afterwards the managed elevation reports show what is happening and the rules need maintaining as applications change, which is a small ongoing task rather than a project.
What organisations ask about Endpoint Privilege Management.
Fifteen questions worth answering first.
Where you are now
- How many users have local administrator rights?Usually more than anybody states.
- Do you know how often they actually elevate?The unmanaged elevation report answers this.
- Which applications genuinely need elevation?Evidence, not opinion.
- Have you licensed EPM in the tenant?Required before policies can be used.
- Are the devices Windows?Microsoft states EPM applies to Windows.
Rule design
- Can you match on publisher certificate?Considerably safer than matching on file name.
- Do you need argument constraints?Allow only certain parameters to be elevated.
- Should child processes be controlled?Otherwise an elevated app can spawn anything.
- Do any applications need the user profile?The only justification for elevate as current user.
- What deny rules do you want from the start?Build them alongside, not afterwards.
Operations
- Who approves support approved requests?And within what timeframe.
- What is the default elevation response?It applies where no rule matches.
- How will you remove rights, all at once or in waves?Waves, in every case we have run.
- Who reviews the managed elevation reports?They show what is actually happening now.
- How are new applications handled?Rules need maintaining as software changes.
The pages around this one.
Intune Suite and advanced capabilities
Where this capability is licensed from, alongside the other seven, and the trial terms that apply to each.
Microsoft Intune
The platform this runs on, covering enrolment, configuration profiles and the wider device management estate.
Endpoint security
The wider endpoint picture, and why removing standing administrative rights is the control that limits everything else.
Get the unmanaged elevation report before you argue about administrator rights.
It shows what people actually elevate, across the whole estate, while nothing has changed and nobody has lost anything. In most organisations the real list is short enough that the conversation stops being a debate and becomes a configuration task.
Related Services
Explore more solutions that work great with this service
Intune Remote Help
Remote support scoped by role, with both parties authenticated
Intune Suite
Eight advanced capabilities, and one trial each per tenant
Microsoft Intune
Device management and endpoint security
Endpoint Security
Defender for Endpoint and Intune managed
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you
Privileged Identity Management
Just-in-time admin access, approval, and audit history you can download
ISO 27001 Certification UAE
The 2022 edition, and whether you should certify at all
MDM Solutions Dubai
Device management across Windows, Apple and Android