Microsoft LAPS solves password reuse across local admin accounts by automatically rotating passwords and storing them in Active Directory (or Entra ID with Windows LAPS). Organizations running hundreds of endpoints with identical passwords needed this, and LAPS delivers.
But LAPS was built for a specific environment: domain-joined Windows devices with consistent network connectivity and administrators working from desks with AD access. Remote workers, offline devices, and hybrid cloud infrastructure weren’t part of the design.
These limitations show up quickly in practice.
LAPS Requires Domain Connectivity
Legacy LAPS and Windows LAPS backing up to Active Directory rely on Group Policy to update passwords, which means devices need domain connectivity. Windows LAPS with Entra ID backup uses Intune or MDM policies instead, but still requires network connectivity to Azure.
This works fine for office workstations that stay plugged into your network, but creates gaps elsewhere.
Remote workers without always-on VPN miss password rotations when they’re not connected. The password stored in AD becomes stale, and the local password on the device doesn’t match what’s in your directory.
Traveling devices face the same issue. A laptop taken on a business trip might go weeks without connecting to the domain, missing multiple password rotation cycles.
Offline scenarios create retrieval problems. If AD or Entra ID is unavailable when you need emergency admin access, you can’t retrieve the current password from the directory. The local password still works if you already have it, but if you need to look it up and the directory is unreachable, you’re stuck.
Legacy LAPS stores passwords in on-premises Active Directory only. Windows LAPS added Entra ID support, but you still need connectivity to whichever directory you chose. There’s no offline fallback mechanism.
IT teams supporting distributed workforces deal with this constantly. The device that needs emergency access is often the one that can’t reach your directory.
LAPS Logs Password Retrieval, Not What Happens During the Session
LAPS tells you when someone retrieved a password from AD, but it doesn’t tell you what they did with it.
When you enable auditing for Legacy LAPS (which isn’t on by default), Event ID 4662 gets logged on your domain controllers whenever someone accesses the password attribute. Windows LAPS uses similar audit mechanisms, whether storing passwords in Active Directory or Entra ID. You can see who grabbed the password and when.
What you can’t see:
- What applications they ran with admin rights
- What system changes they made
- What files they accessed or modified
- How long the session actually lasted
- Whether multiple techs shared the same password
LAPS tracks password access, not password usage. That’s a significant gap for compliance requirements that demand detailed session auditing.
Multiple techs might use the same LAPS password before it rotates. If something goes wrong during an admin session, you know someone accessed the password, but not necessarily who was actually logged in when the incident occurred.
Cloud and Hybrid Environments Create LAPS Complications
Legacy LAPS only works with on-premises Active Directory. If you’re cloud-first or Azure AD-only, Legacy LAPS isn’t an option.
Windows LAPS, introduced in April 2023, added Entra ID support, which helps cloud-native organizations. But it comes with a constraint: each device can only back up passwords to either Active Directory or Entra ID, not both. You can have different devices in your organization use different backends, but each individual device must choose one directory.
For hybrid environments where some devices are AD-joined and others are Entra ID-joined, this creates complexity. You need to manage two separate LAPS configurations or force all devices to use a single directory backend.
The April 2023 rollout of Windows LAPS also created interoperability problems. Organizations running both Windows LAPS and Legacy LAPS on the same devices experienced failures where both implementations broke. Microsoft provided workarounds, but the migration path wasn’t smooth.
Cloud-native organizations using only Entra ID can make Windows LAPS work, but they’re still constrained by the same connectivity requirements and audit limitations.
The Workflow Friction Adds Up
LAPS creates workflow friction that scales poorly:
- Admin needs emergency access to a device
- Admin or helpdesk finds device in Active Directory or Azure portal (for Windows LAPS with Entra ID)
- Admin retrieves password through LAPS GUI, PowerShell, Azure portal, or RSAT
- Admin somehow delivers password to the tech who needs it
- Tech logs in using shared credential
- Tech logs out when done
- Password eventually rotates based on policy
This process works for occasional use but multiply it across dozens of daily requests in a large organization and it’ll add up.
Mobile access compounds this. Retrieving LAPS passwords typically requires RSAT tools or PowerShell. There’s no mobile-friendly option for on-call administrators who need to grant access outside business hours.
A Different Approach: Break Glass Accounts
Admin By Request’s Break Glass feature takes a different approach to emergency admin access.
Instead of managing passwords, it manages temporary admin accounts. When you need emergency access, you generate a one-time local admin account directly from the portal or mobile app. The account is created on the endpoint, time-limited, and automatically terminated after use.
For offline scenarios: Break Glass accounts are local to the device and don’t depend on AD or Entra ID connectivity. They work when your directory is unavailable.
For usage tracking: All processes elevated during a Break Glass session are audit logged, not just account creation. You get session-level visibility into what actually happened.
For cloud environments: Break Glass works across standalone, AD-joined, and Entra ID-joined devices simultaneously. No need to choose a single directory backend.
For workflow: One-click account creation from the portal or mobile app. No password retrieval, no manual delivery to techs, automatic cleanup when the session ends.
When LAPS Still Works
LAPS works well for specific environments:
- Traditional on-premises infrastructure
- Devices that maintain consistent domain connectivity
- Organizations comfortable with password-based emergency access
- Simple requirements where audit logs showing password retrieval are sufficient
If your environment includes remote workers, frequent offline scenarios, hybrid AD/Entra setups, or compliance requirements for detailed session auditing, LAPS limitations become operational problems.
Want to see how Break Glass handles these scenarios? Try Admin By Request EPM free for up to 25 endpoints with no time limit and full feature access.
