Least-privilege projects assume one person per device. Almost every estate contains machines that break the assumption: the kiosk at reception, the PC in the lab, the terminal on the production line, the laptop that three people share across a shift rota. Elevation on shared devices rarely appears in the project plan, and the machines end up carrying the exception nobody wanted to write.
The Shared Administrator Account Problem
The exception usually takes the same form. Somebody creates a shared local administrator account “for the shared ones,” the credential circulates among the people who need it, and the machine drops out of the privilege model entirely. The devices with the most users end up with the loosest rights.
Why Elevation on Shared Devices Looks Hard
The difficulty feels structural. If a policy attaches to a person, and the machine has no single person, then the policy has nothing to attach to. That reasoning holds only as long as you treat the device as the unit of control.
Meanwhile the shared machine collects every property you would rather avoid. A shared credential sits outside every joiner and leaver process, so nobody revokes it when the people who knew it move on. Shared devices also sit in the open — a reception desk, a workshop bench, a corridor — where anyone can reach a keyboard that holds standing administrative rights. And when an incident touches one of these machines, the audit trail names the shared account rather than a person, which turns a five-minute question into an investigation.
None of that follows from sharing hardware. It follows from a workaround.
The Machine Is Not the Unit of Control
Identity is. When people sign in with Entra ID authentication, the person at the keyboard brings their own elevation scope with them, and the machine stops being the thing that decides.
CapaOne Privilege Manager, part of the CapaOne Endpoint Management Platform, defines who can elevate what, where, and under which constraints — per user, group, device, or application. On a shared device, that first dimension does the work. The lab technician who signs in at eight and the service desk technician who signs in at four hold different scopes on the same hardware, because the policy follows the account rather than the asset tag.
This is a different question from the one most privilege projects ask. A separate post covers privilege creep after a role change, where elevation drifts as someone’s job changes over time. Here the axis is space rather than time: the same person, several machines, and several people on each of them.
Two design points matter more on shared devices than anywhere else.
Configure the Settings per User
Avoid relying on a single device-wide elevation scope. Combine the device context with user- or group-based policies, so different people hold different rights on the same endpoint. That combination is the requirement the whole approach rests on, and it is also what makes the model work: the moment the settings distinguish between users, the shared machine behaves like any other endpoint in your privilege model.
Deny Rules Earn Their Keep Here
Deny rules cover shells and unsigned installers. On a single-user laptop that protection is prudent. On a machine in a public corridor they are the difference between a scoped elevation and a general-purpose administrative console standing unattended.
What Shared Devices Still Need From You
Three practical considerations survive the change, and none of them argues against the model.
Shared devices often sit on weaker networks — a production terminal on a congested segment, a kiosk on guest Wi-Fi. Decide deliberately how these machines should behave when the connection drops, rather than letting them inherit the setting you chose for laptops. Physical exposure deserves a shorter elevation window than you would set on a laptop that lives in someone’s bag. And the servers behind these workstations belong in the same conversation: Privilege Manager runs on Windows client and Windows Server, so the file server the lab PC talks to falls under the same model rather than a separate one.
Privilege Manager works with Microsoft Intune, or entirely without it. The platform stands on its own and authenticates against Entra ID either way.
Shared Device Privilege Checklist
Work through this once per site, then once more after any change to who uses the machines.
- Identify the shared endpoints. Kiosks, lab machines, production terminals, and workstations on a shift rota. Count them before you plan anything.
- Find the shared administrator credentials. Look for local accounts that more than one person signs in with, and for passwords that live in a drawer or a note.
- Scope elevation by user or Entra ID group. Decide which people need which rights, and let group membership carry the decision instead of a per-machine rule.
- Add the device context on top. Shared machines can hold their own conditions alongside the identity scope — the two work together rather than replacing each other.
- Pre-approve only what the work needs. Pre-approval works by executable name or app path, so keep the list to the tasks people actually run on that machine.
- Set deny rules for high-risk tools. Shells and unsigned installers belong on that list, and each documented exception should name the work that requires it.
- Shorten the elevation window. A machine in a public corridor deserves a tighter duration than a laptop that lives in someone’s bag.
- Confirm an event traces to a person. Run one elevation, pull the log, and check that it names the individual rather than a shared account. If it does not, nothing else on this list matters.
What You Get Back
The shared administrator credential disappears, and with it the account that no offboarding process ever touched.
The audit record changes character. Every elevation event carries the same set of fields — user, endpoint, executable name and app path, time, duration, outcome — and the whole record exports to CSV. On a shared device those fields answer the question that actually matters after an incident: not which machine, but which person.
And the exception list gets shorter. Shared devices stop being the category you handle separately, which means removing standing local admin becomes a decision you can make for the whole estate rather than for most of it.
Where to Start
Count the machines in your estate that more than one person signs in to, and check how many of them still hold a local administrator account somebody created as a workaround. That number is usually higher than the team expects, and it is the clearest place to start, because each of those machines carries a credential outside every process you rely on everywhere else.
Book a demo of CapaOne Endpoint Management Platform to see policy design for shared devices, or start a free trial and test the model on one shared endpoint.