Nobody plans to give the whole company local admin. It accumulates. A developer needs to install tooling, so IT grants admin "for now." A sales laptop needs a printer driver at an airport, and the ticket queue is long, so admin it is. A department buys software whose installer demands elevation, and the fastest fix is a group policy that makes everyone in the department an administrator of their own machine.
Each decision is small and defensible. The sum is an environment where hundreds of laptops are privileged systems — and almost nobody is tracking them that way.
Why it compounds so quietly
Local admin does not feel like privileged access because it is scoped to one machine. But the risk model is blunt: anything that runs as the user runs with the user's rights. When that user is a local administrator, so is every malicious attachment they open, every trojaned installer they download, every script a phishing page convinces them to run.
With admin rights, malware is no longer a guest on the machine — it can disable security tooling, install drivers, dump credentials from memory, establish persistence that survives reboots, and use the machine as a trusted base to reach whatever the user can reach. Ransomware operators in particular depend on this: encryption at scale, shadow-copy deletion, and lateral movement all get dramatically easier when the first compromised account is an administrator of its own endpoint.
There is a second, slower cost. Machines where users can install anything drift: unsanctioned software, disabled agents, configuration nobody can reason about. Every audit becomes archaeology.
The uncomfortable reframe is this: a laptop with local admin is not "an endpoint with a convenience enabled." It is a privileged system, and your fleet is full of them.
Why "just remove admin" fails
The obvious answer — revoke local admin everywhere — has been tried by nearly every security team, and it fails the same way each time. The legitimate needs that caused the sprawl do not disappear when the rights do. Developers still need to install and debug. Field staff still hit driver prompts with no IT in sight. Line-of-business apps still demand elevation for updates.
If removal is not paired with a fast, legitimate path to elevation, one of two things happens. Either the helpdesk drowns in elevation tickets and the business revolts, or exceptions multiply until the "temporary" admin group quietly repopulates itself. Blanket removal without an elevation path is not a policy; it is a countdown to rollback.
The modern model: elevate the task, not the user
Endpoint privilege management (EPM) resolves the tension by changing what gets elevated. The user stays a standard user — permanently. When a specific application genuinely needs elevation, that application runs elevated, just-in-time, under policy. In practice:
Just-in-time elevation per application, with accountability. A user who needs to install an approved tool requests elevation for that installer. Policy decides: some applications elevate silently, some require a business justification the user types in, some require an approver to say yes. Every elevation is logged — which user, which binary, which justification, when. Admin rights become an event with a record, not a standing condition.
Allow and block by what the binary is, not what it is named. Rules match applications by hash, signature, and publisher — not by file name, which any malware can copy. A signed installer from a trusted publisher can be allowed broadly; an unsigned executable from a downloads folder never elevates, no matter what it calls itself.
Conditional rules that understand context. Modern EPM policy is command-line and parent-process aware. The same binary can be legitimate or hostile depending on how it was started: a shell launched by a developer from a terminal is normal work; a shell spawned by a spreadsheet or a document reader is a classic sign of a malicious macro, and policy can block that specific combination outright. Context-aware rules let you be permissive where work happens and strict where attacks happen.
Offline-safe policy. Laptops live on planes and in hotel Wi-Fi dead zones. Elevation policy has to be enforced by the agent on the machine, with cached rules that work — and stay restrictive — when the endpoint cannot reach anything. A control that lapses offline is a control attackers will simply wait out.
Rotate what remains. Even in a well-run fleet, a built-in local administrator account remains on each machine for recovery. Those accounts must not share one password across the fleet — that is a skeleton key. LAPS-style rotation gives every machine a unique, regularly rotated local admin password, vaulted and retrievable one machine at a time, with an audit record of who retrieved it.
Linux is joining the story
This used to be a Windows conversation. It no longer is. Developer and production Linux machines have their own version of the same problem — broad sudo rights granted once and never reviewed, shared root passwords, sudoers files that drift per machine. The same model applies: centrally managed policy at the PAM/sudo level, deciding which users may elevate which commands on which machines, with every elevation logged centrally instead of in scattered local files. Least privilege on the endpoint is one discipline across both operating systems, not two separate projects.
Local admin sprawl is quiet precisely because nothing bad happens on the day you grant it. The day something bad does happen, it is the difference between an incident on one machine and an incident everywhere. If you are ready to make standard-user the default without making work harder, see how Monopam EPM handles just-in-time elevation and application control, and how the Linux identity agent brings the same policy to your Linux fleet.
