Measure how often anyone genuinely elevates before you take local admin rights away. A report already does this for you.
Turn on the unmanaged elevation report and you get a record of every time somebody reached for Run as administrator, gathered while nothing has changed and nobody has lost anything. After that, standard users can still run the handful of things that genuinely need elevation, through an isolated virtual account that never joins 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.
The documented deployment step reads: enable auditing, create rules, monitor. Following that order is the entire difference between a program that survives and one reversed inside a fortnight.
- Switch on unmanaged elevation reporting while every user still holds the rights they have today. Spend a few weeks doing nothing but collecting evidence of what people genuinely elevate, and in most organizations the resulting list is far shorter than anybody forecast.
- Write rules for whatever appears repeatedly and is legitimate. Publisher certificate matching, argument constraints and child process controls are what keep those rules narrow enough to be worth having, instead of a broad permission that quietly recreates the problem you set out to solve.
- Configure the default elevation response and put support approved behind it as a catch-all, so anything unforeseen becomes a request somebody handles rather than a blocked employee with nowhere to turn. That is what prevents the wave of complaints on the first morning.
- Removal of local administrator rights comes last, and it happens in waves. Since the rules were built from observed behavior rather than guesswork, the first population you move is the one you already hold evidence for.
Eight facts that shape how this gets deployed.
The unmanaged elevation report, which precedes every other step
Reporting on unmanaged elevations captures every file elevation happening without Endpoint Privilege Management involved, including a user with administrative rights invoking Run as administrator. Switch it on before taking anything away from anybody and you learn precisely what would break, which turns a contested policy debate into a list of applications.
An isolated virtual account rather than administrators group membership
Most elevation types run through a virtual account kept isolated from the signed-in user's account, and neither of those accounts is added to the local administrators group. The whole product rests on that property: administrative capability arrives for the duration of the task without any account acquiring standing administrative membership.
User confirmed, which is where most rules should start
A right-click option to run with elevated access, with the administrator free to demand extra validation through an authentication prompt, a business justification, or both together. You end up with a record of what was elevated and why, nobody waits on an approval queue, and during a rollout it generates more useful evidence than any other type.
Support approved, for the cases that warrant a person
The user raises a request to run something with elevated permissions, an administrator approves it, and the user is told they can retry the elevation on their device. This is the right instrument for the long tail of unusual asks, and it removes any need to anticipate every legitimate scenario with a rule written in advance.
Automatic, with an explicit warning attached
These rules elevate without asking the user anything, which suits a well-understood case such as an approved installer. Microsoft attaches a pointed caution: broad rules in this category can affect the organization's security posture across the board. Automatic belongs in narrow, deliberate use rather than as a default setting.
Elevate as current user, and why to avoid it where you can
Here the elevated process runs under the signed-in user's own account instead of the virtual account, which preserves compatibility with tools that depend on the user profile, and Windows Authentication can force reauthentication first. The documented trade is a broader attack surface and weaker isolation from user data, with the advice being to reserve it for cases where virtual account elevation actually breaks the application.
Rules that can be specific enough to be safe
Rules can key on file attributes, and they can go considerably further: child process controls that govern what an elevated application may launch, argument support that permits only particular parameters, file hash matching and publisher certificate matching. A rule anchored to a publisher certificate with argument constraints is a different species from one that trusts anything named setup.exe.
Deny rules, which are the part people forget exists
A deny rule names a file that Endpoint Privilege Management will not allow to run in an elevated context under any circumstances. It is the counterweight to your allow rules, keeping known or unwanted files away from elevation entirely, and it belongs in the build from the start rather than arriving after something has already run.
Four safeguards that keep this off the list of projects people remember badly.
We audit before we remove anything
The documented deployment sequence opens with enabling auditing, and we follow it. Unmanaged elevation reporting runs while everybody still holds their rights, so rules get written against what people actually elevate rather than against anybody's assumptions. The real list is usually short, specific, and a good deal less alarming than the argument that preceded it.
We prefer the virtual account and say why
Most elevation types run through a virtual account isolated from the user's own, with neither account joining the local administrators group. Elevate as current user surrenders exactly that. The guidance is to reach for it only where virtual account elevation genuinely breaks an application, and to scope it tightly, and we hold that line instead of using it to make awkward cases disappear.
We write rules specific enough to be worth having
Matching on a file name hands back most of what you just removed. Publisher certificates, file hashes, argument constraints and child process controls are what turn a rule into an actual control. Writing them takes longer, and that extra time is the whole difference between least privilege and an administrator right in a different shape.
We give people a route before we close the old one
Support approved requests, a named approver and an agreed response time, all working before a single right is withdrawn. These programs never get reversed because the technology failed; they get reversed because a senior person hit a wall at an inconvenient moment with nowhere to go. Standing that route up first removes the failure mode entirely.
Six US situations where standing administrator rights are the real exposure.
A regulated firm asked about least privilege
Banks, lenders, insurers, advisers and anyone covered by NYDFS Part 500 face examination on whether users operate with least privilege, and GLBA and FTC Safeguards Rule assessments pose the same question. This answers with a working control and a log of every elevation, rather than with a policy statement that the membership of the local administrators group immediately contradicts.
A company running entirely on admin rights because of two programs
Far and away the most common situation we walk into. A couple of programs need elevation, solving it properly never reached the top of anyone's list, and the entire company runs as administrator as a result. Two rules matched on publisher certificate close an exposure that has been open for a decade, in an afternoon of configuration.
Engineering or design teams with specialist software
Computer-aided design, engineering and production tools regularly demand elevation for licensing, drivers or plug-ins, and the people using them are technical enough to have won the argument for administrator rights long ago. User confirmed elevation with justification gives them what the work requires and gives you a record of it, which is a better result on both sides of the table.
Education, where shared devices meet varied software
Teaching staff install whatever a lesson calls for, lab machines carry specialist tooling, and the fleet is large. Support approved elevation with a named approver absorbs that variety without either handing out rights broadly or turning the IT team into the reason a class cannot run.
After a ransomware incident or a near miss
When malware executed and held administrative rights instantly because the user did, the exposure is obvious in hindsight and the appetite for change runs high for a short while. Funding is easiest to find in that window, and the audit phase supplies the evidence to proceed without a fight. It is also the change an insurance carrier is most likely to ask about at renewal.
An organization preparing for SOC 2 or NIST 800-171
Privileged access on endpoints comes under scrutiny in both, and CMMC assessments inherit the same expectation. Elevations logged with detailed metadata, deny rules keeping specific files away from elevation, and reporting that separates managed from unmanaged elevation is precisely the evidence those reviews ask for, generated as a by-product of the control simply operating.
How local administrator rights are actually handled in US organizations.
| 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 |
How common this is in practice | Rare | Common | Common in smaller businesses |
Which type to use, and what each one costs you.
Type
User confirmed
- Behavior and where it belongs
- Right-click to run elevated, optionally with authentication and justification. The backbone of most builds.
Type
Support approved
- Behavior and where it belongs
- Request, approval, retry. The safety net for whatever you failed to anticipate.
Type
Automatic
- Behavior and where it belongs
- Elevates silently. Narrow, well-understood cases only, since broad rules here affect security posture.
Type
Elevate as current user
- Behavior and where it belongs
- Runs under the user's own account. Reserved for applications the virtual account breaks. Wider attack surface.
Type
Deny
- Behavior and where it belongs
- Refuses elevation to a named file outright. Build these with the allow rules, not after them.
Type
Default elevation response
- Behavior and where it belongs
- Set in the elevation settings policy, and applied wherever no specific rule matches.
Five steps, and the audit phase is the longest one.
- 1
License, and confirm the platform scope
The capability has to be licensed in the tenant before any policy can be used, and it arrives through Intune Plan 2, the Intune Suite or select Microsoft 365 bundles. Since it applies to Windows, scope covers your Windows fleet, and any Apple or Android hardware is a separate conversation to have honestly at the outset.
- 2
Deploy the client and enable auditing, changing nothing
Assigning an elevation settings policy installs the client on its own. Unmanaged elevation reporting then runs for a few weeks while every user keeps the rights they already hold, producing an evidence base describing what the fleet actually elevates rather than what anybody believes it elevates.
- 3
Write rules from the evidence
Rules for whatever recurs and is legitimate, keyed to publisher certificate or file hash wherever possible, with argument constraints and child process controls added where they buy real safety. Deny rules for anything that should never reach an elevated context, authored in the same pass rather than retrofitted.
- 4
Set the default response and the approval route
The default elevation response inside the settings policy, plus support approved standing behind it as the catch-all, with a named approver and an agreed turnaround. This is the safety net that keeps the first unanticipated case from becoming the reason the whole program halts.
- 5
Remove rights in waves, then keep the rules current
Beginning with the population whose behavior you understand best, then widening outward. Afterward the managed elevation reports show what is really happening, and the rule set needs periodic upkeep as applications change, which is a modest recurring task rather than a second project.
What organizations ask about Endpoint Privilege Management.
Fifteen questions worth answering first.
Where you are now
- How many users have local administrator rights?Invariably more than the official answer.
- Do you know how often they actually elevate?The unmanaged elevation report settles it.
- Which applications genuinely need elevation?Evidence, not opinion.
- Have you licensed EPM in the tenant?Required before the policies can be used.
- Are the devices Windows?This capability applies to Windows.
Rule design
- Can you match on publisher certificate?Considerably safer than matching a file name.
- Do you need argument constraints?Permit only particular parameters to elevate.
- Should child processes be controlled?Otherwise an elevated app can launch 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?Built alongside, never bolted on later.
Operations
- Who approves support approved requests?And inside what response time.
- What is the default elevation response?It catches everything no rule matches.
- How will you remove rights, all at once or in waves?Waves, in every deployment we have run.
- Who reviews the managed elevation reports?They describe what is happening now.
- How are new applications handled?Rules need upkeep as software changes.
The pages around this one.
Intune Suite and advanced capabilities
Where this capability is licensed from, alongside the other advanced capabilities and the trial terms attached to them.
Microsoft Intune
The platform underneath it, covering enrollment, configuration profiles and the wider device estate.
Endpoint security
The broader endpoint picture, and why removing standing administrative rights caps the damage everything else can do.
Pull the unmanaged elevation report before the argument about administrator rights starts.
It records what people genuinely elevate across the whole fleet, while nothing has changed and nobody has lost a thing. In most organizations that list is short enough to end the debate and turn it into a configuration task.
Related Services
Explore more solutions that work great with this service
Microsoft Entra Privileged Identity Management
Privileged Identity Management deployment for US organizations:
Learn morePrivileged Access Audit
Privileged access audits for US organizations: enumeration of every
Learn moreMicrosoft Intune
Device management and endpoint security
Learn moreEndpoint Security
Endpoint security for US businesses using Microsoft Defender for
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn more