LAPS for Azure Arc: Local Admin Password Security Across Hybrid—at Scale

Ask most security teams where their biggest unmanaged risk hides, and the answer often isn’t a zero-day—it’s the local administrator account on every Windows machine. Same password, rarely rotated, quietly waiting to be the first domino in a lateral movement attack. I recently sat down with Amir Bredy from the Azure Edge Security team to talk about LAPS for Azure Arc—a capability that extends a control many teams already know and makes it enforceable, auditable, and provable across an entire hybrid estate.

The Problem

Local admin credentials remain one of the most reliable paths for attackers: one shared password reused across hundreds of machines, rotated manually (or never), with no central way to enforce a standard. Compromise one box, and an attacker effectively holds the rest.

Windows LAPS breaks that pattern by generating a unique, random password per machine, rotating it on a schedule, storing it securely in Microsoft Entra ID or Active Directory, and taking post-authentication actions like resetting the password after use. The challenge has always been doing this consistently and provably at scale.

What Azure Arc Adds

Classic Windows LAPS is configured machine by machine—via Intune, Group Policy, or local CSP. LAPS for Azure Arc lifts that up to the control plane. Using Azure Policy and Machine Configuration, you audit and enforce the same settings through a single policy assignment across Azure VMs and Arc-enabled servers anywhere—on-prem, edge, or other clouds.

The payoff:

• Declarative, central configuration instead of per-box drift
• One consistent model wherever the machine lives
• Compliance reporting with an audit-ready evidence trail

LAPS for Azure Arc Works

1. Azure Policy defines the desired LAPS config and scope (subscription or resource group)
2. Machine Configuration audits—and optionally configures—each machine to match
3. The Arc agent extends the same model to non-Azure machines

It’s a standard Azure Policy assignment doing the orchestration. Nothing exotic.

Audit First, Enforce When Ready

Recommended path: start in audit-only, review, then promote to configure in rings—dev, staging, production.

Secure by Default

The defaults are opinionated—aligned to NIST and CIS guidance:

• 15-character complex passwords
• 30-day rotation
• Password expiration protection enabled
• Post-auth actions that reset and sign users out 8 hours after use

Accept the defaults, and you’re already in a strong place.

Tuning It

Every key behavior is a policy parameter:

• Password length: 8–64 (default 15)
• Rotation: 1–365 days (7-day minimum for Entra ID)
• Post-auth actions: reset only → reset + sign-out + terminate → reset + reboot
• Backup directory: Entra ID or Active Directory

Watch out for: pointing backup to AD on non-domain-joined machines, misconfiguring the encryption principal so admins can’t retrieve passwords, and overly aggressive post-auth actions in production. Validate your setup, keep the defaults to start, and get more aggressive only when confident.

Why It Matters for Hybrid and Sovereign Estates

In sovereign cloud, hybrid, and regulated environments, consistency is everything—controls that work in the cloud but break at the edge create exactly the gaps attackers exploit. LAPS for Azure Arc closes one of those gaps with a single policy story spanning cloud, on-prem, and edge, while producing the compliance evidence regulated customers must show.

It’s also not a rip-and-replace—it configures the same Windows LAPS already on the box, so it composes with your existing deployment.

Try It Today

It’s in public preview; import the policy as a custom definition from the OSConfig GitHub release.

👉 Explore LAPS for Azure Arc

👉 Overview · Quickstart

Learn more about Azure Arc

🎬 Watch the full interview and demo with Amir Bredy for the deeper walkthrough.