Run As Admin
What is it?
Run As Admin (also known as App Elevation) is one of three controlled elevation paths in Admin By Request (ABR), and the most targeted of the three. When a standard user needs to install software, run a privileged tool, or launch an executable that requires administrator rights, Run As Admin gives that single process the privileges it needs - while the user's session token stays at standard user level throughout. Only the target process is elevated, and only for the duration of that process. Once the process exits, the elevation ends and no admin rights remain on the endpoint.
This is fundamentally different from simply having local admin rights. A user with local admin rights is always elevated - every process they launch can request admin privileges without any check, any log, or any approval. Run As Admin replaces that always-on privilege with a just-in-time model: elevation is requested, logged, optionally authenticated, optionally approved, and automatically revoked the moment the elevated process finishes.
Run As Admin is available on Windows, macOS, and Linux. The underlying mechanism differs by platform (ABR intercepts Windows UAC events, macOS installation actions, and Linux sudo commands respectively), but the result is the same: the process gets elevated, the event is audited, and the user's session remains standard.
What problem does it solve?
Before ABR is deployed, organisations typically face a binary choice:
-
either users have local admin rights - meaning they can elevate anything at any time, with no record of what was done and why
-
or users have no admin rights, and every elevation requires a helpdesk ticket or a shared admin account, which is slow, frustrating, and often results in people hoarding admin access anyway.
Run As Admin breaks this binary. Users can still elevate the specific applications they legitimately need, but each elevation requires going through ABR's workflow, which means:
-
The elevation is logged in the Auditlog, permanently, with the application details, file hash, certificate, timestamps, and the identity of the user.
-
Before elevation, the file is checked against a 30+ engine malware database (OPSWAT MetaDefender). Malicious files are blocked before execution.
-
If configured, users must provide written reasons for their elevation requests - creating a documentation trail of intent, not just activity.
-
If configured, an administrator must explicitly approve each request before elevation proceeds.
-
At no point does the user's session token receive admin rights. The elevation is strictly bounded to the one process they requested.
The practical result is that organizations can remove standing local admin rights from their users without creating a helpdesk bottleneck, because most legitimate elevation needs can be met through Run As Admin - with full auditability and, optionally, without any human approval step involved.