Removing local admin rights from staff computers without breaking work

Reference article · 6 min read

Local administrator rights on a staff workstation are the difference between a phishing click that installs a nuisance and one that installs a persistent foothold. When the person clicking is already an administrator, the malicious code inherits that power immediately. It can disable security tooling, load a driver, create a hidden account, and reach credentials cached on the machine. Removing standing admin rights is one of the few endpoint changes that reduces risk across a wide range of attacks without buying anything new, and it maps directly to the least privilege expectations in common control frameworks such as the NIST SP 800-53 access control family and the CIS Controls.

It is also the change most likely to generate calls to the front office. Somewhere in the agency there is a field inspector who installs a plotter driver at a job site, a GIS analyst who runs a niche executable a vendor emailed over, and a public works supervisor who has had admin since the machine was imaged under a prior administration. A project that treats these people as compliance problems will stall. A project that plans for them before the first account changes usually finishes.

Inventory who has rights and what they do with them

Pull local administrator group membership across every managed endpoint before deciding any policy. Endpoint management platforms report this, and in smaller environments a scripted collection will do. Expect the list to be longer than IT believes, and to include stale accounts, vendor service accounts, and entire departments granted access years ago for a reason nobody wrote down.

Then find out what the rights are used for. Elevation telemetry beats a survey: enable logging for privileged operations and software installs, watch for several weeks, and sort the results into three groups. Most accounts will not have used admin rights for anything. A middle group installs software that could be packaged and pushed centrally. A genuinely small group does something that needs elevation on the spot. Those groups get three different treatments, and their relative sizes tell you how much tooling you actually need to buy.

Randomize the built-in local administrator password first

Do this before removing anyone's rights, because it fixes a separate and serious problem: one shared local administrator password baked into an image and reused across the fleet. If a single workstation is compromised, that password lets an attacker move sideways to every machine that shares it.

Microsoft's Local Administrator Password Solution, available as Windows LAPS in supported Windows versions and managed through Active Directory or Microsoft Entra ID, sets a unique random password per machine, rotates it on a schedule, and stores it where only authorized staff can retrieve it. Several endpoint management and privileged access products offer equivalent rotation, including for macOS local admin accounts through MDM. Confirm current platform requirements against vendor documentation, since supported versions and feature sets change.

Whatever you use, document who may retrieve a password, whether retrieval is logged and reviewed, and whether the password rotates automatically after use. A break-glass credential nobody audits is only marginally better than a shared one.

Give the legitimate cases a real path

• Package and deploy. Most requests for admin are really requests to install one approved application. A self-service portal backed by your endpoint management tool removes the request entirely.
• Handle drivers deliberately. Printer and plotter drivers are the classic field case. Stage approved driver packages in the machine driver store ahead of time and configure print policy so approved devices install for standard users. Recent Windows versions restrict nonadministrator driver installation by default for security reasons, so design around that behavior rather than reverting it.
• Use endpoint privilege management. These tools elevate a specific application, installer, or control panel action under rule, without making the user an administrator. Scope rules to named executables and publishers, not to folders users can write to.
• Pair with allowlisting. Application control technologies such as Windows Defender Application Control or AppLocker, or third party equivalents, limit what can execute at all. Start in audit mode and read the logs before enforcing.
• Separate admin accounts for IT. Staff who truly need administrative access should use a distinct named account that never reads email or browses the web.

Write an exception process that expires

Exceptions are not failure. Undocumented, permanent exceptions are. Require each request to name the person, the specific machine, the specific application, and the business reason, with approval from both the department head and the security lead. Set a fixed expiration measured in weeks or a quarter, not indefinitely, and let the expiration actually take effect so renewal is a decision rather than a default. Track exceptions in the ticketing system you already use, run a standing report, and tell approvers what the current count looks like. Where an exception persists, treat it as a backlog item for packaging or privilege elevation rules.

Sequence the rollout so the service desk survives

Start with IT. Nothing damages credibility faster than exempting the team imposing the change. Move next to departments with uniform software and few specialized devices, then to mixed departments, and put field, engineering, GIS, public safety, and lab environments last, after you have learned what breaks.

Pilot each wave with a small group, notify users a week ahead in plain language that says what will change and how to get help, and staff a temporary fast lane in the service desk for elevation requests during the wave. Publish how long that lane will stay open. Hold a wave rather than pushing through it when ticket volume spikes, and fix the underlying packaging gap before continuing.

What to ask vendors and put in the contract

• Does the application require administrative rights at runtime, or only during installation? Ask for the specific files, registry keys, and services it writes.
• Is a silent, per-machine installer available for deployment through standard endpoint management tools?
• Are executables and installers signed by a verifiable publisher, so allowlisting and elevation rules can reference the signature?
• Does support require a shared local administrator credential, and will they work with a rotated, per-machine password instead?

In new agreements and renewals, require that the software operate correctly for standard users, that the vendor provide a deployable package, and that the vendor give advance notice when an update changes privilege requirements. Confirm any procurement language with your counsel and purchasing office.

HQT works with state and local agencies on endpoint security and enterprise IT engineering, including least privilege and endpoint management design.

Frequently asked questions