One local administrator password shared across every workstation means compromising one machine is compromising all of them. LAPS fixes that by setting a unique, rotating password on each device and storing it in the directory. The gap between having LAPS and having it deployed everywhere is where the risk lives, and the machines it misses are rarely the unimportant ones.
Why the shared password persists
It is created during the build process and inherited by every image afterwards. The NSA and CISA joint advisory on the top ten cybersecurity misconfigurations lists poor credential hygiene among the issues its assessment teams encounter most, and reused local administrator credentials are the clearest example on a Windows estate. Attackers value them because the password works everywhere without touching the domain, so lateral movement generates no unusual directory activity at all. Nothing is exploited. A valid credential is simply used on the next machine along.
See also: Mastering Index Technical Analysis for Consistent Profits in India
Checking coverage rather than configuration
You should measure deployment by counting machines with a recently rotated password stored, not by confirming that the policy exists. Query the directory for the password attribute and the expiry timestamp on every computer object, then compare the result against your full machine list. The gaps are predictable: servers excluded during rollout, machines that were offline for the deployment window, kit rebuilt from an older image, and devices belonging to a department that manages its own hardware. Any machine without a stored password is still carrying whatever the build gave it.
“The finding that matters is usually not coverage, it is who can read the passwords. We routinely find the helpdesk group holds read access on every computer object in the domain, including servers. That is a shared local administrator password with extra steps, because compromising one support account hands over the lot.”
William Fieldhouse, Director, Aardwolf Security Ltd
Delegating read access properly
Scope read permission by organisational unit and by group so support staff can retrieve passwords for the devices they support and nothing else. Server passwords belong to the server team, and workstations to the desktop team, with the two separated deliberately. Audit reads, because retrieval of a password is a meaningful event: a support account reading fifty machine passwords in an hour is either a scripted task you know about or an incident. Windows LAPS, now built into current versions of Windows, supports storing passwords in Entra ID as well, which suits estates without a domain.
Confirming it works under attack conditions
Test from an ordinary user account, since that is the position an attacker starts from. Try to read the password attribute, try to authenticate to a second machine with credentials taken from the first, and see whether the estate holds. Internal penetration testing services do exactly this and will find the machines your coverage report missed, because a tester goes looking for the exceptions. Pair it with a vulnerability scanning service to keep the underlying operating systems current, since a fully patched estate with a shared local password is still one machine away from a bad week.
Frequently asked questions about LAPS
These questions come up whenever local administrator access is reviewed.
Does LAPS work for servers?
Yes, and it is often omitted during rollout. Servers benefit as much as workstations, with the caveat that some applications rely on a fixed local account, which needs identifying before you rotate anything.
Should staff have local administrator rights at all?
Rarely, and the exceptions should be temporary and logged. LAPS protects the built-in account, and it does not help if every user is an administrator on their own machine.
