Windows LAPS rotates and escrows the local administrator password of a managed device. The feature solves a real problem: a shared local administrator password used to be identical across a fleet, and a single leak handed over every machine.
Whether the replacement is safer depends on who can read the escrowed password, and that is an Active Directory permission question rather than an endpoint setting.
What the feature stores and where
Windows LAPS stores the managed password in an Active Directory attribute on the computer object, alongside metadata such as the password's expiry time. It can also store an encrypted password using Windows Hello for Business in newer configurations.
Access to the attribute is governed by an extended right in Active Directory, delegated separately from the ability to read a general object attribute. Granting a group that right lets its members retrieve the current password for any covered device, after which they can authenticate as the local administrator.
This is intended. It is also a path to every managed workstation and server that LAPS covers, and it deserves the same review as any other fleet-wide credential access.
The delegation question
In practice, the group that holds the read right grows. A help-desk group receives it so that technicians can support users. A backup team receives it so that agents can access files. An automation account receives it so that a script can remediate a condition.
Each addition is individually reasonable and the sum is a group whose members hold administrative access to the entire covered fleet.
Two related permissions are easy to overlook. Read access to the password history exposes previous passwords for the rotation window, which matters when a device is offline and the escrow has not refreshed. The ability to write the attribute matters just as much, because a password written by an unauthorised identity would be one that identity already knows.
What to check
Enumerate the principals with the extended right on each LAPS-enabled organisational unit. Compare that list against the documented support model, and remove entries whose justification has expired.
Check the read scope. A group with the right across the domain root is a different exposure from one scoped to a single departmental unit.
Review the write side, including any automation account permitted to set the password.
Check the rotation and expiry settings. A password that never expires defeats most of the benefit, and an escrow that is not refreshed leaves a stale value the user may still know.
Review devices excluded from the policy. A legacy device with a shared local administrator password is the original problem, still present.
Reducing the blast radius
Scope the delegation to the smallest unit that supports the workflow.
Separate read from write, and require that no single group holds both.
Prefer a just-in-time access path over a standing group membership, where the tooling supports it.
Log retrievals. The retrieval event is the moment a credential is used, and it is more useful than the rotation event.
Track retired devices. A computer object that remains in the directory with an escrowed password is a credential for hardware nobody watches.
Limits
Windows LAPS performs the escrow as documented, and a well-scoped delegation is a genuine improvement over a shared password. The residual risk described here is administrative access by design, not a product defect.
References
Microsoft documentation, Windows LAPS overview: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview
Microsoft documentation, Windows LAPS and Active Directory permissions: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts