Just-in-time admin rights means nobody on a workstation is a local administrator by default. When a person needs elevated access, they ask for it, someone approves it, and the access expires on its own after a fixed window. The alternative, standing local admin, is the state many companies are in: a share of staff, often IT and developers, sit in the local Administrators group permanently. That standing privilege is what ransomware, credential theft and careless installs all depend on. This guide explains why standing admin persists, how to remove it without a flood of tickets, and what a working just-in-time model looks like on real endpoints.
Why standing local admin is the problem
A local administrator can do anything on that machine: disable the security agent, install any software, read any file, dump credentials from memory and change the configuration that your other controls rely on. That is what the role is for.
The trouble is who holds it. In many estates the local Administrators group contains:
- Users who needed to install one printer driver in 2019 and were never removed.
- Developers who asked once and were told "fine, but be careful".
- Help desk accounts that are admin on every machine in the building.
- The build image's local account, with the same password on every laptop.
Every one of those is a path for an attacker. A phishing link opened by a standing admin runs with admin rights. Malware that lands on an admin session can turn off defenses before anyone sees it. Microsoft's own guidance for Windows is to keep the number of local administrators as small as possible and to use dedicated accounts for administrative work (see Microsoft Learn on local accounts). CISA's cross-sector performance goals likewise call for separating user and privileged accounts and for least privilege on endpoints (CISA CPG).
The second problem is auditability. With standing admins, "who installed this tool on this laptop last Tuesday" has no reliable answer. The privilege was always there, so nothing was requested, logged or approved.
What just-in-time admin rights actually means
The phrase gets used loosely, so it is worth being precise. A just-in-time (JIT) model has four parts:
- No standing membership. The local Administrators group holds only a managed break-glass account. Human users are standard users.
- A request path. When a user needs elevation, they ask through a channel that records who asked, on which device, and why.
- An approval decision. Someone, or a rule, grants the request. The grant is specific: this user, this device, this duration, and ideally this application.
- Automatic expiry. The access is removed when the window closes without anyone remembering to do it. Expiry is the whole point. A grant that has to be manually revoked becomes standing admin again within a month.
A related technique is often grouped under the same heading: running a single named application elevated while the user stays a standard user. It is narrower and safer. The user never gets an admin shell, only one program, say a legacy accounting client that writes to Program Files, running elevated. For a large share of "I need admin" tickets, that is the right answer.
How companies usually remove local admin
Most rollouts follow a familiar path, and most stall at the same point.
Phase one: inventory. Pull the local Administrators group from every machine. The numbers are usually worse than expected because of nested domain groups.
Phase two: remove and brace. Strip the membership by Group Policy or a script. The help desk gets tickets for a few weeks: printer drivers, VPN clients, developer tools, that one plugin finance needs.
Phase three: the quiet re-grant. This is where the effort usually dies. Each ticket is solved by adding the person back "temporarily". Nobody removes them again. Six months later the group looks like it did before.
Phase three is a tooling failure, not a discipline failure. Without an expiring grant and a way to elevate one application, the help desk has two options: "say no" and "make them admin". They will make them admin.
A working rollout replaces that binary with three outcomes for every request:
| Request | Right answer | Standing admin needed? |
|---|---|---|
| Install approved software | Deploy it from the console, verified | No |
| Run one app that insists on admin | Elevate that one application by policy | No |
| Genuine admin task (driver, diagnostics) | Time-limited grant, approved, expires | No |
| Emergency on an offline device | Break-glass local account, password escrowed and rotated | No |
Notice that none of the rows ends with permanent membership.
What good looks like
A mature setup has a few recognizable properties.
The default is standard user, including for IT. Administrators use a separate privileged account for admin work and a standard account for email and browsing. The browser never runs as admin.
Requests take minutes, not days. If approval takes a day, people route around it. A request raised from the device and approved from a console within minutes keeps users inside the process.
Grants are short and scoped. One hour is a common default: long enough to install a driver and reboot, short enough that a forgotten grant does little harm. The best grant is "this application elevated for this user on this device". The worst is "admin everywhere".
Everything is on record. Who asked, who approved, when it expired. The auditor will ask for it, and so will the incident review.
It pairs with application control. Removing admin rights stops a user from installing arbitrary software through the normal path. Application control with default deny stops unapproved executables from running at all, admin or not. The two cover each other's gaps. See application control with default deny for the other half.
It pairs with device control. A standard user cannot disable USB restrictions, but a local admin can. Removing admin makes USB device control policy enforceable rather than advisory.
Common objections
"Developers cannot work as standard users." Much development tooling installs per user. For the tools that do not, deploy them from the console or elevate the single installer. A developer who truly needs admin on a build machine should have a grant on that machine, not on the laptop with email on it.
"The help desk will drown." Only if the sole tool is an on/off switch. It will not if every ticket can be closed by deploying the software, elevating the application by policy, or granting one hour from the console.
"Our security agent needs admin." A properly built endpoint agent runs as a system service. It does not need the user to be an administrator, and a standard user should not be able to stop it.
Practical checklist
- Export the local Administrators group from every endpoint and keep the baseline.
- Classify every member: human user, service account, nested domain group, imaging artifact.
- Give IT staff separate standard accounts for daily use; admin accounts are for admin work only.
- Put a managed break-glass local account on every device with a unique, escrowed, rotated password.
- Define the standard grant: duration (start with one hour), who can approve, what is logged.
- Identify the applications that "need admin" and decide for each: deploy it properly, elevate that one app, or retire it.
- Pilot on the IT team first; they generate the most admin requests and find the gaps fastest.
- Remove membership in rings: IT, then a pilot department, then everyone.
- Measure requests per week per hundred devices; a falling number means the elevation and deployment paths are absorbing demand.
- Report on any device that still has a non-managed member in the Administrators group. Treat it as drift and fix it.
- Review the approval log monthly for the same person requesting the same thing repeatedly. That is an application that should be elevated by policy or deployed.
- Pair the change with default-deny application control and a patch process so "I need admin to update X" disappears as a ticket category. See patch management rings.
How Tracemark does it
Tracemark's Endpoint Control product handles the two halves of this problem from one console and one agent.
Time-limited access requests. A user raises an access request. An administrator approves it from the console for a limited time, for example one hour. When the hour ends, the access expires on its own. Nothing has to be remembered or revoked by hand, and the approval is a console change, so it lands in the admin trail with who, what and when.
Run one application elevated, without local admin. For the applications that insist on administrative rights, a policy names the application and the agent runs that one application elevated while the user stays a standard user. The user does not get an admin shell or admin membership, only the named program.
Application control with default deny. Windows Defender Application Control rules are managed from the console so that nothing unapproved runs, whether or not the session is elevated. This closes the gap that removing admin rights alone leaves open.
Device control that a user cannot undo. USB storage is denied by default and trusted by serial number, with Bluetooth, wireless and removable disks each under their own rule. Because users are no longer local admins, those rules hold.
The surrounding management. Software deployment with verified install and uninstall takes the "I need admin to install this" ticket out of the queue. Patch management in rings takes "I need admin to update this" out as well. Hardening fixes risky settings in one press and re-fixes them when they drift.
Every change in the console lands in the admin trail with who, what and when, and role-based access means each role sees only what it can use.
Frequently asked questions
Is just-in-time admin the same as removing local admin rights?
No. Removing local admin rights is the first step. Just-in-time admin is what makes the removal stick: a request path, an approval, and automatic expiry so that temporary grants do not become permanent again.
How long should a temporary admin grant last?
Start with one hour. It covers a driver install and a reboot. If users regularly need longer, that usually points to an application that should be deployed centrally or elevated by policy instead of granted as full admin.
Do users need admin rights to install software?
Not if software is deployed from a management console that runs the installer as a system service. For software that cannot be packaged, elevating that one installer by policy is safer than making the user an administrator.
What about the local admin account built into the image?
Keep one managed break-glass account per device, give it a unique password that is escrowed and rotated, and log every use. Remove every other local account from the Administrators group. The shared imaging password on every laptop is one of the first things an attacker looks for.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca