Removing local admin rights is one of the most effective ways to harden endpoints. The key to success isn't the technology, it's the order: first learn what users need, and only then remove the rights.
In this guide we walk through the process we use at OnCloud with Admin By Request:
- A pilot on up to 25 endpoints, on the free plan.
- A full rollout in learning mode, and building pre-approvals.
- Removing rights in stages, and handling the common issues.
- Moving the support desk to work without standing admin rights.
Stage 1: Pilot
Before you commit, test the solution on a small group. Admin By Request has a Free Plan limited to 25 endpoints, but it includes every feature and has no time limit. It's an easy way to run a real pilot, on your organization's own tenant and under real working conditions.
Connect your identity provider. The first step in the new tenant is to connect it to your identity provider, usually Entra ID or Okta. This enables MFA for portal sign-in and lets you build policies by user group. We recommend building policies by user group.
Run in learning mode. Install the agent on the pilot endpoints, but don't remove admin rights yet. The system logs every action users run with admin rights. That log is the basis for pre-approvals: the software, OS tools and actions users need, so they won't have to submit a request for them.
The approval channel. At this stage you also set up how requests reach approvers: a message in Slack or Teams, the Admin By Request mobile app, or a connection to your ticketing system.
What to test in the pilot. Focus on the applications unique to your organization, such as industry-specific software or legacy systems. Common applications like browsers or Office almost never need testing.
Stage 2: Full rollout and pre-approvals
Once the pilot is done and licenses are purchased, deploy the agent to every endpoint, again in learning mode. Let the system collect data for one to two weeks, and build the pre-approvals before removing anyone's rights.
This is the most important stage of the project. The more accurate the pre-approvals, the fewer users will notice the change. These are the ways to pre-approve an application:
| Method | What it approves | When to use it |
|---|---|---|
| Digital certificate | Every application from that vendor | A vendor the organization fully trusts |
| Certificate and application name | A specific application from a vendor | Most cases: precise, and doesn't break on version updates |
| Checksum | A specific file in a specific version | Software without a digital signature |
| Location | A file in a specific folder, on a file server or on the computer | The organization's internal tools |
You can also set specific applications to always run with admin rights, without the user having to ask.
Tray Tools on Windows. OS tools such as adding a printer, Control Panel or network adapter settings go into Tray Tools. From there users run them with admin rights, with no request and no call to support.
Stage 3: Removing rights in stages
Remove rights gradually, group by group, not across the whole organization at once. The system supports this, and if a group runs into a problem, you can easily give its rights back.
Two issues you'll run into in almost every deployment:
- An application that doesn't request admin rights properly. Some applications don't work cleanly with Windows UAC, so they don't ask for elevation when they need it. The fix is simple: right-click and Run as administrator. Just show users how, or set the application to always run with admin rights.
- An OS tool that pops up a UAC prompt. A user who opens a Windows tool and gets a UAC prompt asking for an admin password is launching it from the wrong place. The right place to run such tools is Tray Tools, which runs them with admin rights.
Stage 4: The support desk without standing rights
Once admin rights are removed from every user, one gap remains: the support staff. In most organizations their accounts have standing admin rights on every endpoint. An account like that is a favorite target for attackers.
The Support Assist feature closes it. Support staff no longer need standing admin rights. When a technician connects to an endpoint, they enter support mode, and the endpoint temporarily switches from the user's policy to the technician's, which lets them run whatever they need. When they're done, the endpoint returns to its normal policy.
This is also why many organizations deploy the system on endpoints where users already have no admin rights: to make support work more efficient, and to let users occasionally run what they need without opening a ticket.
Securing the system itself
A system that decides who gets admin rights needs to be protected itself. These are the settings we recommend:
- Connect it to your SIEM. Every admin-rights request, approval and session is sent to your security monitoring, so the security team sees them alongside every other event in the organization.
- Separate roles in the portal. Define two kinds of portal users: administrators with full rights to settings and policies, and support desk staff who can only approve requests.
- Emergency access (Break Glass). Support staff can generate a temporary local admin account for an endpoint, for when it's offline and can't reach the portal.
Summary
A successful EPM deployment rests on the right order: a pilot on your unique applications, a learning period, accurate pre-approvals, removing rights in stages, and finally moving the support desk off standing rights. Done this way, most users don't notice that anything changed.
At OnCloud we support every stage, from the pilot to the support desk handover. Want to start with a pilot?
Book a technical demo