Windows LAPS in Intune keeps local admin passwords unique and rotated

In a lot of the environments I assess, people still underestimate the risk that comes with local administrator passwords. I keep running into the same local admin account with the same password on dozens, sometimes hundreds, of Windows machines. For an attacker, that makes lateral movement almost trivial. Once one endpoint falls, spreading through the network with Pass-the-Hash or credential reuse is only a matter of time. With more organizations moving to cloud-first device provisioning through Autopilot, you need something central and cloud-native to deal with this. Windows LAPS has been built into Windows since April 2023, and since the Entra ID integration became generally available in October, you can finally run the whole thing through Intune and Entra ID alone.

Identical local admin passwords make lateral movement easy

The danger of using one local admin password everywhere still gets overlooked. On-prem AD environments have had this problem for years, but Entra-only setups are just as exposed. AV and network segmentation only help once something has already happened. What actually fixes it is giving every device a strong, unique admin password that rotates regularly, that nobody knows by default and that can only be retrieved when someone really needs it. Microsoft's answer to this has always been LAPS (Local Administrator Password Solution), which started out as an MSI extension for AD environments. Now that Windows LAPS is part of the OS and fully supports Entra ID, you can store and manage these secrets without any legacy infrastructure. For the fundamentals, the official documentation is still where I'd start: Microsoft LAPS Overview and managing local admin passwords with Entra ID.

Windows LAPS in Intune needs one Entra setting and one policy

Compared to the old AD approach, setting up Windows LAPS with Intune is pleasantly simple. In Entra ID, you first enable "Windows LAPS" backup in the device settings so devices are allowed to upload the passwords they generate. Everything else (backup target, password complexity and length, rotation period and post-authentication reset) goes into an Intune Account Protection policy. The setting that matters most is the backup directory. Pick Entra ID to keep everything in the cloud; for cloud-native deployments there's no real alternative. In most cases I go with strong complexity, a length of 16+ characters and a rotation of 7–30 days, depending on how much risk you're willing to accept. The Intune policy options have covered everything I've needed so far, apart from very specialized scenarios.

Pro tip: Test with a pilot group before the broad rollout. Check that the passwords actually show up in the Entra portal and that delegated access works the way you planned.

Entra ID RBAC controls who can view and rotate passwords

The first thing customers usually ask is who can actually see these passwords. Microsoft keeps tight RBAC boundaries here. You give helpdesk staff or specific admin groups access through Entra ID RBAC roles, and that is separate from whether someone is a device admin or Intune admin. You view or rotate a password right from the device record in the Entra or Intune portal, without the detours the legacy tooling required. If necessary, you can also trigger a rotation manually, for example after an incident or once a contractor no longer needs access.

This Mermaid diagram shows the Windows LAPS password lifecycle with Entra ID and Intune:

flowchart TD
    Device["Device generates password"] --> EntraID["Backup to Entra ID"]
    EntraID --> Intune["Intune policy applies settings"]
    Helpdesk["Helpdesk admin reads password"] --> EntraID
    Intune --> Device["Rotation is triggered"]

Figure: LAPS password lifecycle with Entra ID integration.

Access to these passwords is tightly restricted. In my experience, admins often expect device admin roles to come with password read permission by default, and they don't. The exact permission mapping is in the Entra LAPS documentation.

Every password access leaves an audit trail

One thing that gets ignored far too often is the question of who accessed which local admin password and when. Windows LAPS and Entra ID give you a proper audit trail for that. The Entra ID audit logs show which user viewed or rotated a password. In regulated industries, or anywhere with strict separation of duties, you can't do without this. The device also writes local events, which is useful for SIEM integration and incident investigations.

If you send your logs to Microsoft Sentinel, this sample KQL query pulls the relevant LAPS access events:

SecurityEvent
| where EventID in (10018, 10019, 10021)
| project TimeGenerated, Computer, Account, EventID, EventData

Legacy Microsoft LAPS and Windows LAPS must never run side by side

I still see plenty of organizations running the old Microsoft LAPS (MSI) agent next to Windows LAPS. That combination causes trouble, so never run both on the same device. Windows LAPS is natively supported on Windows 10 21H2 (with the April 2023 patch) and on all versions of Windows 11. Uninstall the old MSI agent before you roll out the new solution. With Intune and Entra ID, the GPO and AD dependency disappears completely, and so do the schema extensions and GPO quirks.

Windows LAPS has finally tamed local admin passwords

In my view, the native Windows LAPS integration with Entra ID is a big step forward for cloud-first endpoint security. Local admin accounts finally have a "set and forget" solution, without shared secrets or AD baggage. Automatic rotation, granular permissions and solid auditing together give you what Zero Standing Privilege on endpoints requires. For many of my clients, this was the piece their security setup had been missing. You'll find more in the Intune documentation for Windows LAPS or in other posts like [/blog/new-microsoft-teams-client-migration].