Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter

What Is Windows LAPS Not Deployed?

Windows LAPS not deployed means the environment still lacks a managed process for setting, rotating, backing up, and recovering the local administrator password on Windows endpoints and servers. Microsoft’s Windows Local Administrator Password Solution exists to solve a specific problem: the local admin account is often still present for break-glass, build, or support workflows, but if its password is static or reused, one compromised endpoint can give an attacker the same reusable credential across many more systems.

Microsoft’s current guidance is to use Windows LAPS, not leave the control to manual rotation. Windows LAPS can back up the password either to Windows Server Active Directory or to Microsoft Entra ID, and it includes native policy settings, PowerShell cmdlets, and auditing support. If the feature is absent, mis-scoped, or never rolled out through GPO, Intune, or another supported management path, the gap stays operationally real even if the organization believes local admin access is “rarely used.”

That is why Windows LAPS not deployed often surfaces next to GPO Misconfigurations: How Group Policy Becomes an Attack Vector and Stale Privileged Accounts: Hidden Risk in Active Directory. In all three cases, the control problem is not only who has admin rights. It is whether the credential lifecycle is predictable and defensible under compromise.

How It Works

Windows LAPS is built into current Windows releases and can manage one configured local administrator account on a device. Microsoft documents two supported backup targets:

• Windows Server Active Directory
• Microsoft Entra ID

On the client, you configure policy settings such as the account to manage, password complexity, password age, post-authentication actions, and backup directory. On the management side, you delegate who can read passwords, who can reset them, and how recovery is audited.

For Microsoft Entra ID, Microsoft is explicit about scope and prerequisites:

• supported devices must be Microsoft Entra joined or hybrid joined
• Microsoft Entra registered devices are not supported
• tenant-side LAPS must be enabled, and a client-side policy must set BackupDirectory to Microsoft Entra ID

For Active Directory, Windows LAPS relies on schema extensions and delegated rights so the directory can store and protect the password material. Microsoft also provides dedicated cmdlets to update schema, query passwords, identify who can read them, and reset expiration or rotation behavior.

Microsoft also publishes a migration path from legacy Microsoft LAPS. That matters because many environments think “LAPS is deployed” when they actually mean an older implementation was once installed on some systems and never consistently migrated, monitored, or cleaned up.

The Attack Chain

Step 1 - Compromise one machine with a reusable local admin credential

Attackers do not need a domain admin to benefit from poor local admin hygiene. They need one host where the local admin account is reachable and its password is either guessed, recovered, or captured during another intrusion step. If that password is effectively the same across many devices, compromise does not stay local for long.

That is why the issue often appears during the same review as Active Directory Password Security: Misconfigurations That Matter. The core mistake is identical: a credential that should be unique and controlled is actually easy to reuse.

Step 2 - Reuse the credential for lateral movement

Once the attacker has a local admin password or NT hash that works across several endpoints, remote administration channels become much more valuable. The exact path varies by environment, but the logic stays the same: the password was never randomized per device and never rotated quickly enough after exposure.

# Defender-side example: validate whether a device is covered by Windows LAPS
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

If the operational log is empty on devices that should be managed, or password retrieval and rotation never appear in the expected management path, the deployment is incomplete.

Step 3 - Expand access faster than defenders can rotate manually

Manual password changes do not scale well during an incident. An environment without Windows LAPS usually falls back to emergency rotation scripts, endpoint tickets, or ad hoc password resets. That slows containment and leaves a larger window where the attacker can continue reusing the same local admin path on more systems.

This is also why the issue fits naturally with Active Directory Attack Paths to Domain Admin. LAPS alone does not solve privilege escalation, but not having it gives attackers a reliable lateral movement primitive that often connects into broader AD abuse.

Detection

The most useful detection approach combines policy coverage, backup validation, and delegated access review.

# Query who can read LAPS-backed passwords in AD
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'

# Query a password from AD for validation during rollout
Get-LapsADPassword -Identity WS-001 -AsPlainText

For Entra-backed deployments, Microsoft documents Get-LapsAADPassword and role-based authorization for password recovery. That means a good deployment review should verify both sides: the password is actually there, and only the intended administrators can read it.

It is also worth correlating LAPS rollout with Active Directory Monitoring: Security Event IDs That Matter. If the local admin password control is missing, the monitoring team usually also lacks clean visibility into which systems are still outside the intended baseline.

Remediation

💡 Quick Win: Pick one supported backup model first. A half-migrated environment that mixes manual local admin management, legacy Microsoft LAPS, and Windows LAPS usually creates more confusion than protection.

A practical remediation sequence looks like this:

1. Decide the backup authority. Use Windows Server AD or Microsoft Entra ID, based on how the device is joined and managed.
2. Prepare directory and rights. For AD-backed deployments, update the schema and review read/reset permissions. For Entra-backed deployments, enable tenant-side LAPS and confirm password recovery roles.
3. Configure client policy. Set the managed account, password complexity, password age, backup directory, and post-authentication actions.
4. Validate successful processing. Use the Windows LAPS operational log and retrieval cmdlets to verify that passwords are rotating and being stored in the expected backend.
5. Remove drift. Clean up older scripts, shared local admin passwords, or partial legacy Microsoft LAPS configurations that leave some systems unmanaged.
6. Audit recovery rights. Make sure the people who can read LAPS passwords are the ones who truly need that privilege.

# Common deployment and validation flow for AD-backed Windows LAPS
Update-LapsADSchema
Get-LapsADPassword -Identity WS-001
Reset-LapsPassword

For Microsoft Entra-backed deployments, Microsoft also recommends protecting password recovery with Conditional Access on the roles that can retrieve local admin credentials. That is a useful reminder that LAPS deployment is not just an endpoint hygiene task. It is also an access control problem.

Validate the Rollout Before Closing the Gap

A LAPS rollout is not complete because the policy object exists. It is complete when representative devices are rotating passwords, the backup target contains current secrets, and the delegated recovery path has been tested end to end. The safest validation set is small but concrete: one workstation, one privileged admin workstation if applicable, one server class where local admin access still exists, and one recovery test performed by the exact role that should be authorized.

That validation should also document who can read passwords and who can trigger resets. If the deployment leaves broad read access behind, the environment simply trades one weakness for another. That is why Windows LAPS not deployed and weak delegation often need to be reviewed together during the same audit.

How EtcSec Detects This

EtcSec maps this gap to LAPS_NOT_DEPLOYED and GPO_LAPS_NOT_DEPLOYED. The useful distinction is whether Windows LAPS is missing entirely, or whether the organization believes it is deployed but never pushed a durable policy to the right endpoints.

ℹ️ Note: EtcSec automatically checks whether LAPS coverage is missing or inconsistently deployed during Active Directory audits. That makes it easier to separate “feature available” from “feature actually protecting endpoints.”

Official References

• Microsoft Learn: What is Windows LAPS?
• Microsoft Learn: Windows LAPS PowerShell Cmdlets Overview
• Microsoft Learn: Use Windows Local Administrator Password Solution with Microsoft Entra ID
• Microsoft Learn: Prepare for Windows LAPS deployment and migration

Related Reading

To prioritize this issue properly, review it alongside GPO Misconfigurations: How Group Policy Becomes an Attack Vector, Stale Privileged Accounts: Hidden Risk in Active Directory, Active Directory Password Security: Misconfigurations That Matter, How to Audit Active Directory Security: Practical Checklist for Internal Teams, and Active Directory Monitoring: Security Event IDs That Matter. Those adjacent topics explain why local admin password rotation only works when policy scope, ownership, and auditability are all aligned.