LAPS vs PAM Vaulting for Local Admin Passwords

Every endpoint and server has a local administrator account, and the choice between LAPS and a PAM vault decides who can get that password, for how long, and what record you keep of its use. Windows LAPS gives each device a unique, rotated password stored in the directory, at no extra licence cost. A privileged access management (PAM) vault adds check-out, approval, rotation on check-in, session brokering and recording, across Windows, macOS, Linux and network devices. Both stop the shared password that turns one compromised laptop into a fleet compromise; they differ in control depth, coverage and operating cost. This guide is for identity, endpoint and PAM teams deciding which to use where, and how to run them together without one undoing the other. For LAPS settings, permissions and event IDs see the Local Administrator Password Solution (LAPS) Guide; this page does not repeat them.

Key takeaways

Both fix the shared password problem. A unique password per device is the control that breaks the reuse chain behind ATT&CK T1078.003 Local Accounts; LAPS and a vault deliver it equally well.
The difference is what happens around retrieval. LAPS controls who can read; a vault adds why, when, with whose approval, through which path, and with what recording.
LAPS reader rights are a privilege in their own right. A group that can read LAPS passwords on an OU holds administrator on every device in it, so reader sprawl is the main LAPS threat.
Never let two systems rotate one account. Windows LAPS rejects outside password changes on the account it manages, logging event 10031; pick one owner per account.
Most estates use both. LAPS for the bulk Windows client fleet, a vault for servers, tier 0 assets, non-Windows systems and anything that needs approval or session evidence.

What each approach is

LAPS here means Windows LAPS, the feature built into Windows since the 11 April 2023 updates, plus the equivalent Intune capability for macOS. Microsoft lists support on Windows 11 23H2 and later, earlier Windows 10 and 11 builds with the April 2023 update, and Windows Server 2019, 2022 and 2025; Windows 10 reached end of support on 14 October 2025, so LAPS remains on Windows 10 only where Extended Security Updates apply. The device itself generates the password, writes it to Active Directory or Microsoft Entra ID (never both), and rotates it on schedule. Retrieval is a directory read governed by ACLs or Entra roles. The legacy MSI product is deprecated; see Legacy LAPS vs Windows LAPS.

PAM vaulting means a privileged access management platform that holds the local administrator credential in an encrypted vault, changes it itself over a management protocol (for example SMB or WinRM on Windows, SSH on Linux and macOS), and releases it to a person or process through a policy. Typical policy steps are authentication to the vault, a reason or ticket number, optional approval by a second person, a check-out window, and rotation when the credential is checked back in. Many platforms can also broker the session so the user never sees the password, and record it. The NCSC describes the model as access being requested first, with a temporary credential issued if approved and its window of use kept short.

Side-by-side comparison

Aspect	Windows LAPS (and Intune macOS LAPS)	PAM vaulting
Who changes the password	The device, on an hourly background check against policy	The vault, connecting to the device with a reconciliation or management account
Where the password lives	Computer object in AD (optionally encrypted to one principal) or Entra ID	The vault's encrypted store, with its own backup and replication
Retrieval control	AD read and decrypt rights per OU, or Entra roles scoped by administrative units	Vault policy: role, reason, ticket, approval, time window, exclusive check-out
After use	Post-authentication actions rotate after a grace period, optionally signing out or rebooting	Rotation on check-in or at window expiry; brokered sessions can avoid disclosure entirely
Evidence	Who read the password (directory audit), plus device logon events	Request, approver, reason, check-out times, and optional keystroke or video recording
Platforms	Windows clients and servers; macOS through Intune ADE enrolment	Windows, Linux, macOS, network and storage devices, hypervisors, depending on connectors
Network dependency	None for rotation beyond reaching the directory	The vault must reach every device, or run a local connector, on management ports
Cost and effort	No extra licence on supported Windows; low operating effort	Licence per target or user, connectors, high availability design, onboarding work
New attack surface	Directory permissions on password attributes	The vault, its admins, its reconciliation account and its connectors

Threat model for each option

LAPS: reader rights abuse

The LAPS password is only as protected as the right to read it. An attacker who compromises any account in a LAPS reader group, or any account with "All extended rights" on the OU, can read the password of every device in scope and then sign in as local administrator on each one. Because the read is a normal directory query, it does not look like an attack unless directory service access auditing is on. With encryption enabled, Microsoft notes the password is encrypted to a single principal, which defaults to Domain Admins if not set, and that principal cannot be changed for a password once it is encrypted. A help desk group that is made the decryptor for every OU becomes a quiet tier 0 group. See the Active Directory ACL and Delegation Hygiene Guide.

The second LAPS risk is the window after retrieval. A password read during troubleshooting stays valid until the next rotation unless post-authentication actions are on. Microsoft describes that feature as "intended to bound the amount of time that the clear-text password is usable", but it only triggers when the account actually authenticates on the device; a password read and never used, or copied into a ticket, lives until its scheduled expiry.

PAM vault: concentration risk

A vault moves the risk. Instead of many directory ACLs, there is one system that can change and reveal every local administrator password it manages, and a reconciliation account with administrator rights on every target. The NCSC states plainly that "the PAM system is itself an attack surface" and an attractive target. Vault administrators, the vault's own service accounts, API credentials used by scripts to check out passwords, and the connector hosts are all tier 0. Credentials used to reach the vault from automation are a recurring weak point: in the Uber Breach 2022 the attacker claimed to have found a PowerShell script with hard-coded admin credentials on an internal share, a claim Uber did not confirm. See Securing the PAM Vault Itself.

Shared threat: lateral movement

Both options target the same attacker path: take a credential or hash from one device (T1003.001 LSASS Memory), reuse it on others through T1550.002 Pass the Hash or T1021.002 SMB/Windows Admin Shares, and spread. Unique passwords end reuse across devices, but neither option stops an attacker who already holds administrator on a device from using that device. Limit network logon by local accounts and keep administrators on clean workstations; see the Lateral Movement Guide and Tiered Administration and Enterprise Access Model Guide.

Failure modes

Failure mode	LAPS form	Vault form	Control
Over-broad read	Support group with read on the domain root OU; leftover extended rights	Safe or policy that lets all IT staff check out any workstation or server	Per-tier reader groups; per-tier safes; quarterly access review
Unrotated after use	Post-authentication actions disabled; password read and pasted into tickets	Check-in rotation off; long check-out windows renewed indefinitely	Rotate after use; short windows; alert on reads with no matching rotation
Coverage gaps	Servers or macOS left on a build password; BackupDirectory left at 0	Devices never onboarded; rotation failing silently on unreachable hosts	Reconcile against the asset inventory weekly
Two owners	LAPS blocks the vault's change (event 10031) and the vault marks the account failed	Vault keeps an old password that no longer works	One owner per account; integrate rather than duplicate
Recovery lock-out	Entra device object deleted with the password; restored VM snapshot out of sync	Vault unavailable during an outage or ransomware event	Break-glass path and offline recovery tested; see the Break-Glass Account Guide

Coverage: where each stops

Windows clients: LAPS covers them natively and scales to any fleet size with no per-device connector. A vault can manage them too, but needs network reach to every laptop, which is hard for remote devices that are rarely on the corporate network.
Windows servers and domain controllers: LAPS covers servers and can back up the DSRM password to AD. Many organisations still put server and tier 0 local accounts in a vault because they want approval and session recording for those logons.
macOS: Intune provisions a LAPS-managed local admin account only for devices enrolled through automated device enrolment after a factory reset, on macOS 12 and later. It generates 15-character passwords and rotates them every six months by default, with an optional schedule of 1 to 180 days. Viewing and rotating need custom Intune RBAC permissions that no built-in role includes. Devices outside that path need another approach.
Linux, network devices, appliances and hypervisors: there is no LAPS equivalent built into the platform. A vault with the right connectors, or a configuration management tool that sets unique passwords and stores them in a secrets manager, is required. Many teams also move Linux administration away from shared root passwords to named accounts with sudo; see Root, sudo and superuser accounts on Linux and Unix.
Isolated and OT networks: LAPS works where there is a domain controller in the zone. A vault needs a connector inside the zone or a jump path into it, which must itself be governed.

Choosing: decision guidance

Decision criterion	Points to LAPS	Points to PAM vaulting
Fleet size and type	Thousands of Windows clients, many remote or roaming	Hundreds of servers in data centres or cloud networks the vault can reach
Session recording need	Not required; directory audit of reads is enough	Regulators, auditors or contracts require evidence of what was done in the session
Approval need	Help desk access within a ticketed process is acceptable	Dual control or manager approval required for tier 0 and production servers
Non-Windows endpoints	Estate is Windows plus Intune-enrolled Macs	Linux, network, storage and hypervisor local accounts in scope
Audit questions	"Who could read this password, and who did?"	"Who used it, why, who approved, and what did they do?"
Budget and team	Small team, no PAM platform yet	PAM platform already licensed and operated

For a small organisation without a PAM platform, LAPS on every Windows device is the right first step: it closes the largest risk at almost no cost. Large and regulated organisations usually end up with a split model. The deciding question per asset class is whether the evidence and gating a vault adds is worth its connector and onboarding cost for that class. For the broader question of standing vaulted credentials against temporary elevation see Credential Vaulting vs Just-in-Time Elevation, and for removing the need for local admin logons on endpoints see the Endpoint Privilege Management Guide.

Running both without conflict

The two can coexist in three patterns. Pick one per asset class and write it down.

Split by scope. LAPS manages Windows clients; the vault manages servers, tier 0 and non-Windows. Each account has exactly one owner. This is the simplest and most common pattern.
Vault as front door to LAPS. LAPS keeps rotating; the vault, or a request workflow, holds the only LAPS read right and retrieves the password on approved request, adding reason, approval and logging. Post-authentication actions still rotate after use. Remove direct reader rights from people so the workflow cannot be bypassed.
Vault owns rotation, LAPS off for that account. Where the vault must rotate and record, take the account out of LAPS scope. Do not leave a LAPS policy on the same account: Microsoft documents that Windows LAPS rejects unexpected attempts to modify the managed account's password, logs event 10031, and directs interoperability questions about third-party tools to their developers.

Worked scenario: hybrid estate of 9,000 devices

A firm has 8,000 Windows laptops (most remote), 700 Windows servers, 250 Linux servers, 50 network devices and a PAM platform licensed for 1,000 targets. An audit finding says the server build image uses one local administrator password and the help desk shares a spreadsheet of exceptions.

Laptops: Windows LAPS backing up to Entra ID, read through a custom role scoped by administrative unit for the service desk, post-authentication action set to reset and sign out. No vault connector is needed for roaming devices.
Windows servers: LAPS to AD with encryption to a dedicated decryptor group for member servers; domain controllers back up DSRM passwords. The vault is the only member of the decryptor group, so administrators request server passwords through it with a ticket reference.
Tier 0 servers and Linux: vault-owned, rotated on check-in, session brokered and recorded, dual approval outside change windows. LAPS policy is not applied to these accounts.
Network devices: vault-owned local accounts held for break-glass only; normal access through central authentication.
Result: about 950 targets in the vault, inside licence; the spreadsheet is deleted and its passwords rotated; every local admin retrieval has a named requester.

How to implement: phased approach

Inventory local administrator accounts. Count devices per OS and tier, and find shared build passwords. The Privileged Account Discovery and Onboarding Guide covers discovery sources.
Assign an owner per asset class. Record whether LAPS, the vault or the vault in front of LAPS owns each class. This table is the artefact auditors will ask for.
Clean read rights before go-live. Remove broad extended rights in AD and narrow vault safes or policies to per-tier groups.
Pilot ring. Apply the chosen control to a test OU or device group. Confirm the password backs up (LAPS events 10018 or 10029) or that the vault verifies and rotates, and test retrieval by an authorised and an unauthorised account.
Turn on rotation after use. Post-authentication actions for LAPS, rotation on check-in for the vault. Check that a retrieved password stops working after the window.
Expand by ring, clients first for LAPS, tier 0 first for the vault, watching failure rates.
Rotate anything ever shared. Old image passwords, spreadsheet entries and passwords pasted into tickets are changed once coverage is confirmed.
Roll back safely. Keep the previous control in place on the pilot scope until the new one reports success, and never point both at the same account during cut-over. If the vault takes over from LAPS, remove the LAPS policy first, then let the vault reconcile.

Detection and measurement

Log both the retrieval and the use. For LAPS that is the directory read (event 4662 on the LAPS attributes after Set-LapsADAuditing, or the Entra audit activity "Recover device local administrator password") and the device logon (4624 for the local account). For the vault it is the check-out, approval and session record. Correlate a retrieval with a logon and a rotation; a retrieval with no logon, or a logon with no retrieval, needs a question. Alert on bulk reads across many devices, reads by accounts outside reader groups, and network logons with local administrator accounts from hosts that are not support jump hosts. Intune records macOS password views as "Get AdminAccountDto". See the Privileged Session Management Guide for what to keep from recorded sessions.

Coverage: share of devices per asset class whose local admin password is managed by its designated owner and rotated within policy; target above 98 percent.
Reader population: number of people and service accounts able to read or check out local admin passwords, per tier; trend down.
Retrieval to rotation time: median hours between a retrieval and the next rotation of that password.
Unmatched retrievals: retrievals without a ticket or approval reference; target zero for vaulted tiers.
Ownership conflicts: devices logging LAPS event 10031 or vault rotation failures; target zero.

Common failure patterns

Vault bypass by leftover rights: the vault is put in front of LAPS but the help desk keeps its old read right, so nobody uses the workflow.
Help desk made tier 0: support staff added to Domain Admins or made the LAPS decryptor for domain controllers so they can read passwords.
Two managers on one account: the vault and LAPS fight over the password, rotations fail, and staff fall back to a known password.
Vault reach assumed: laptops onboarded to the vault rotate only when on the corporate network, so many never rotate.
Vault credentials in scripts: automation checks out local admin passwords using an API key stored in clear text beside the script, so the vault becomes reachable to anyone who reads the share.
No break-glass when the vault is down: during an outage or ransomware recovery the only copy of server passwords is in an unavailable vault. See Recovering IAM and PAM After Ransomware or Domain Compromise.

Where identity fits

Local administrator accounts are shared, non-personal credentials: closer to non-human identities than to user accounts. Whichever tool holds them, give each class a named owner, a rotation policy and a review cycle, and treat the vault's reconciliation account and any automation that checks out passwords as privileged non-human identities in their own right. The CISA and NSA advisory AA23-278A lists improper separation of privilege and poor credential hygiene among the most common misconfigurations and advises defenders to "reduce, restrict, audit, and monitor administrative accounts and privileges".

Framework mapping

Framework	Reference	How LAPS and vaulting meet it
MITRE ATT&CK	T1078.003 Local Accounts; T1550.002 Pass the Hash; T1021.002 SMB/Windows Admin Shares	Unique per-device passwords end reuse; rotation after use shortens exposure
NIST SP 800-53 Rev. 5	AC-2, AC-6(5), IA-5(1)	Account management, restricted privileged accounts, password-based authenticator management
NIST SP 800-53 Rev. 5	AU-6, AU-14, AC-2(12)	Review of retrievals, session audit through recording, monitoring for atypical use
NIST CSF 2.0	PR.AA-01, PR.AA-05, DE.CM-03	Credential management, least privilege, monitoring of personnel activity
CIS Controls v8.1	5.2, 5.4, 6.5	Unique passwords, dedicated administrator accounts, MFA for administrative access (including to the vault)
ISO/IEC 27001:2022	A.5.17, A.8.2	Authentication information, privileged access rights

Practitioner checklist

Every local administrator account has exactly one rotation owner: LAPS or the vault.
No two devices share a local administrator password, including servers, Macs and Linux hosts.
LAPS reader and decryptor groups are per tier, small, and reviewed quarterly.
Rotation after use is on: post-authentication actions or check-in rotation.
Tier 0 and production server local accounts require approval and, where needed, recorded sessions.
The vault, its administrators, its reconciliation account and its API clients are managed as tier 0, with phishing-resistant MFA.
Retrievals are correlated with logons and rotations, and unmatched retrievals are investigated.
A tested break-glass path exists for when the vault or directory is unavailable.

LAPS vs PAM Vaulting: Which Fits Your Local Admin Accounts