Service desk elevation becomes an urgent question as soon as an organization removes local administrator rights, and it always takes the same form: what happens when someone genuinely needs to install something at half past four on a Friday. The honest answer in most organizations is that a technician types a shared local admin password, and everyone agrees not to think about it too hard.
The password is not the problem. It is a symptom of a missing mechanism — the ability to authorize one specific action on one specific machine for a short period, without handing anyone a set of keys.
Why the Shared Local Admin Password Survives Every Policy That Bans It
It survives because it works, and because the alternatives on offer are usually worse for the person doing the job.
The Scope Is the Whole Machine
A local administrator password grants everything on that machine, not the one thing the user needed. The technician who types it is not making a decision about a driver installation; they are granting unrestricted local control and hoping the situation stays as described.
It Records No Decision
A credential authorizes a person to act. It does not capture which action the technician approved, under which rule, or how long the elevated window should have lasted. Where the workflow goes further and adds the user to the local Administrators group, the privilege has no end date at all — it lasts until someone remembers to reverse it.
Attribution Stops at the Account
Some attribution usually exists — a managed credential logs each retrieval, and individual admin accounts identify the technician. What is missing is the chain: which person, on which device, requested which action, approved by whom, for how long, with what outcome. When something goes wrong three weeks later, the investigation starts from an account rather than a decision.
A credential that works on more than one machine is also worth something to an attacker who obtains it — the same reasoning that makes removing the local admin close the opening EDR killers rely on.
What About Windows LAPS?
It is the obvious objection, and it deserves a straight answer. Windows LAPS gives each device a unique local administrator password, rotates it on a schedule or after use, and restricts retrieval to authorized staff. That closes the reuse problem properly — one compromised machine no longer hands an attacker the rest of the fleet.
What it does not do is decide anything. Credential management and elevation approval solve different problems. If the service desk still retrieves a local admin password to close ordinary tickets, the credential is secure and the workflow has not moved — you have protected the key without reducing how often someone reaches for it.
What Service Desk Elevation Looks Like Instead
CapaOne Privilege Manager, part of the CapaOne Endpoint Management Platform, lets a supporter authorize a scoped, time-bound elevation without exposing local admin accounts to anyone. The technician approves an action rather than surrendering a credential.
Three things change in the daily work.
The action traces to a person. The record shows the user, the endpoint, the executable name and application path, the time, the duration, and the outcome. Compare that with a shared credential, where the log names an account that belongs to everyone and therefore to nobody.
Nothing lingers. The elevation expires on its own. Nobody has to remember to reverse anything, which matters because the step people forget is always the last one.
No credential changes hands. The supporter authorizes without exposing a local admin account, so there is no password to type in front of a user.
Watch Which Requests Keep Coming Back
The most useful thing about routing elevation through a supporter is not the control. It is the data.
A request that arrives once is an exception. The same request arriving every week is a policy gap wearing a costume — the task belongs in a rule, and each of those tickets existed only because it was not there. Reviewing recurring requests monthly is the cheapest policy tuning available, and it shrinks the queue rather than managing it.
Some categories disappear entirely rather than getting approved faster. Where routine installs and updates drive the volume, CapaOne Application Manager deploys them silently by policy, so the elevation request never arises in the first place. An approval you never have to give is better than a fast one.
The direction of travel is a service desk that grants fewer elevations over time, not one that grants them more efficiently. If the number is flat after three months, the policies are not learning from the queue.
For teams already running Microsoft Intune, CapaOne operates alongside existing compliance and configuration policies, and it works equally well as a complete platform on its own. Our endpoint privilege management overview sets out where supporter-authorized elevation fits in a wider endpoint strategy, and our post on just-in-time elevation in practice covers the decisions to make before the first policy goes live.
Try it against a real ticket — book a demo, or start a free trial and approve the first elevation yourself.