Evaluator's Guide — Module 01
LAPS or
Privilege Manager?
Privilege Manager?
Microsoft LAPS is a useful free tool for one specific problem. Delinea Privilege Manager solves that problem and six more. This guide gives evaluators the framework to assess which tool — or combination — their organization actually needs.
74%
of breaches involve privilege misuse
Verizon DBIR 2024
1
core capability LAPS provides
Password randomization only
14+
capabilities Privilege Manager delivers
Across all three platforms
0
app control features in LAPS
By design — out of scope
The Core Distinction
⊞ Microsoft LAPS
LAPS manages the local administrator account password — it randomizes it, stores it in Active Directory or Entra ID, and rotates it. That's it. It doesn't control what applications run, who can elevate, or what happens on non-Windows machines.
■ Delinea Privilege Manager
Privilege Manager controls what applications can do on every endpoint — including removing local admin rights entirely, elevating specific apps by policy, blocking untrusted executables, enforcing MFA at the endpoint, and managing all three major OS platforms.
Common Evaluator Mistake: Treating LAPS and Privilege Manager as alternatives to the same problem. LAPS solves "are local admin passwords unique and rotated?" Privilege Manager solves "can we remove local admin rights entirely and control all privilege escalation?" These are adjacent but different problems. Many mature organizations need both.
How to Use This Guide
Work through each module in order. Each gap module covers one area where LAPS has a limitation, shows you exactly what LAPS does (and doesn't do), and explains the specific Privilege Manager capability that addresses it. The Feature Matrix (Module 07) gives you a printable summary for stakeholder conversations.
Module 02 — Know Your Baseline
What LAPS
Does Well
Does Well
Before evaluating gaps, it's important to be precise and fair about what LAPS actually does. It solves a real, critical problem — and it solves it well within its defined scope.
⊞ LAPS: The Problem It Solves
Before LAPS, most organizations had the same local administrator password on every Windows workstation — set during imaging and never changed. One compromised machine meant an attacker had admin credentials that worked across the entire fleet. LAPS breaks this "pass-the-hash" attack vector by giving each machine a unique, randomly generated password stored securely in AD/Entra.
LAPS Core Capabilities
✓ Password Randomization
Generates a unique, complex random password for the local administrator account on each managed Windows machine. Eliminates password reuse across endpoints entirely.
✓ Secure AD/Entra Storage
Stores the local admin password as a protected attribute in Active Directory or Entra ID. Access to retrieve the password is controlled by AD permissions/delegated roles.
✓ Automatic Rotation
Rotates the local admin password on a configurable schedule (e.g., every 30 days) or immediately after it's been retrieved and used — ensuring stale credentials don't persist.
✓ Windows LAPS (2023+): Enhanced Capabilities
The modern Windows LAPS (built into Windows 11 22H2+ and Server 2022/2019) expanded on the legacy version with: Entra ID support (cloud-joined machines), account management for any local account (not just Administrator), post-authentication rotation on demand, and encrypted password storage in the AD attribute. These are genuine improvements — but they don't expand LAPS beyond the credential management domain.
Where LAPS Fits in a Security Architecture
LAPS is a credential management control, not an endpoint privilege control. It answers: "Are local admin passwords unique and rotated?" It does not answer: "Can users escalate privilege? What applications can run? Is the endpoint compliant with least-privilege policy?" Both questions matter — they require different tools.
| Security Question | LAPS Answer |
|---|---|
| Are local admin passwords unique per machine? | YES — Core capability |
| Are local admin passwords rotated? | YES — Configurable schedule |
| Are local admin passwords stored securely? | YES — AD/Entra protected attribute |
| Can users run arbitrary applications with admin rights? | N/A — Not in scope for LAPS |
| Can specific apps be elevated without admin account? | NO — Out of scope |
| Can untrusted applications be blocked from running? | NO — Out of scope |
| Does protection extend to macOS/Linux? | NO — Windows/AD only |
Gap Analysis — Module 03
Gap: Application
Control
Control
LAPS manages the password of the local admin account. It cannot control which applications run, which are blocked, or which are allowed to elevate. Application control is where the majority of endpoint threat surface lives.
CAP 01
Blocking Malicious / Unauthorized Applications
PM Covers This
MS LAPS
Gap
LAPS has no mechanism to prevent any application from running. Even with LAPS deployed, a phishing payload can still execute, install persistence, and run with whatever rights the user has. The randomized admin password doesn't help if the user is still a local admin.
› Why This Gap Is Critical
Without application control, every endpoint is one phishing email away from executing arbitrary code. LAPS protects the credential; it does nothing to prevent the binary from running in the first place. Ransomware doesn't need the local admin password if the user is running as local admin.
Privilege Manager
Covered
PM's blocking policies evaluate every application launch against a rule set. Block by: file hash, publisher certificate, path pattern, command-line arguments, parent process, or execution context (e.g., launched from %TEMP%). Silent blocks, notification blocks, and SOC alert triggers are all available.
› How PM Handles This
PM intercepts every CreateProcess/execve call on the endpoint and evaluates it against ordered policies: block-list first, then allow-list, then elevation rules, then default. This happens in milliseconds before the OS grants any execution rights. The block event is logged to the PM console and can be forwarded to SIEM in real time.
CAP 02
Allow-Listing: Only Approved Apps Can Execute
PM Covers This
MS LAPS
Gap
LAPS has no application inventory or allow-list concept. It cannot restrict execution to only approved software. Any binary in any location can run regardless of LAPS being deployed.
Privilege Manager
Covered
PM supports both deny-listing (block known-bad) and allow-listing (only approved apps run). Allow-list mode is particularly suited to high-security or fixed-function environments: kiosks, POS terminals, industrial workstations. Applications are verified by publisher cert and/or SHA256 hash.
CAP 03
Application Execution Audit Trail
PM Covers This
MS LAPS
Partial
LAPS logs when the local admin password is retrieved (who, when, from which machine). It does not log application launches, privilege escalations, or execution events. The audit trail is narrow by design.
Privilege Manager
Covered
Every policy decision — elevation granted, elevation denied, application blocked, application allowed — is logged with: username, machine name, process name, hash, parent process, timestamp, justification provided (if prompted). Logs forward to PM console, SIEM, and ServiceNow natively.
The critical gap in plain terms: LAPS ensures an attacker who compromises one machine can't reuse that machine's local admin credentials on other machines. But if that machine's user is still a local admin, the attacker doesn't need the password — they're already privileged. Application control is what removes that ambient privilege entirely.
Gap Analysis — Module 04
Gap: Policy-Based
Elevation
Elevation
LAPS manages the local admin account but doesn't provide a mechanism for users to get elevated rights for specific, approved applications without being given full local admin. This is one of the most operationally impactful gaps in LAPS-only deployments.
The Elevation Problem LAPS Doesn't Solve
⚠ The LAPS-Only Dilemma
With LAPS and no elevation tooling, organizations face a binary choice for every application that needs elevated rights: either (a) give the user local admin — which creates exactly the attack surface LAPS was deployed to reduce — or (b) deny elevation and force a helpdesk ticket for every install or privileged task. Neither is acceptable at scale.
✓ PM's Resolution
Privilege Manager breaks the binary. Specific approved applications can be elevated without the user holding a local admin account. The elevation is policy-driven: verified by publisher certificate, file hash, path, or command-line. Users get their legitimate work done; the attack surface stays removed.
CAP 04
Silent Application Elevation (No User Interaction)
PM Only
MS LAPSNot Available
LAPS has no concept of selective application elevation. If an app needs admin rights and the user isn't a local admin, it simply fails — or the IT team must manually intervene.
Privilege ManagerCovered
PM can elevate a specific verified application silently — no UAC prompt, no dialog, no user action. The process token is elevated transparently. Used for well-known, trusted line-of-business apps where no justification is needed.
CAP 05
Prompted Elevation with Business Justification
PM Only
MS LAPSNot Available
No justification capture, no workflow, no audit. Users either have local admin or they don't.
Privilege ManagerCovered
For applications that should be elevated only when there's a documented reason, PM shows a justification dialog. User selects from a curated reason list. Selection is logged alongside the process metadata. App then elevates. No admin password entered, no helpdesk call made.
CAP 06
Approval-Workflow Elevation (Manager/IT Gate)
PM Only
MS LAPSNot Available
No workflow engine. Elevation decisions are binary and not gated on approval from a second party.
Privilege ManagerCovered
For sensitive applications, PM can require an approver (manager, help desk) to review and approve before elevation is granted. Time-boxed: the grant expires automatically. Full approval chain is recorded with timestamps. Integrates with ServiceNow and email for the approval workflow.
Elevation Security: Filter Strength Comparison
When elevation is granted by policy, the quality of the application filter determines how resistant the policy is to spoofing or abuse. Here's how LAPS compares to PM on filter capabilities:
| Filter Type | LAPS | Privilege Manager |
|---|---|---|
| File path only | N/A | AVAILABLE — weak, not recommended alone |
| Publisher certificate verification | NO | YES — validates full signing chain |
| SHA256 file hash | NO | YES — exact binary matching |
| Parent process context | NO | YES — e.g., "only if launched by Outlook" |
| Combined multi-filter policies | NO | YES — AND/OR logic across all filters |
Gap Analysis — Module 05
Gap: Cross-Platform
Coverage
Coverage
LAPS is a Windows-and-Active-Directory solution. Organizations with macOS endpoints, Linux servers, or Azure AD-only (no on-prem AD) environments have a fundamental coverage gap. This is increasingly critical as macOS adoption in enterprise grows and Linux endpoints multiply.
Platform Coverage Head-to-Head
| Platform / Environment | MS LAPS | Privilege Manager |
|---|---|---|
| Windows 10 / 11 (AD-joined) | YES — Core LAPS use case | YES — Full policy enforcement + UAC intercept |
| Windows (Entra ID / Azure AD joined) | PARTIAL — Windows LAPS 2023+ only | YES — Full support, no AD requirement |
| Windows (workgroup / non-domain) | NO — Requires AD or Entra | YES — Agent registers to cloud tenant |
| macOS (Sequoia / Sonoma / Ventura) | NO — Not supported | YES — Full policy enforcement, Jamf/Intune deploy |
| Linux (RHEL, Ubuntu, Debian, SUSE) | NO — Not supported | YES — PAM integration, sudo policy management |
| Azure Virtual Desktop sessions | PARTIAL — Password mgmt only | YES — Application control within AVD session |
| Citrix / RDS published apps | NO | YES — Process isolation per published app |
Coverage Visualization
Fleet Coverage by Platform
LAPS
Windows AD only
PM
All platforms
LAPS covers only Windows endpoints that are joined to Active Directory or Entra ID — approximately 28% of a typical mixed enterprise fleet when macOS, Linux, and non-joined machines are included. Privilege Manager covers the full fleet from a single policy console.
macOS: What PM Adds
- Authorization Services intercept — all privilege escalation requests
- sudo policy management — PM-controlled, centrally audited
- PKG/DMG installer control — evaluate before installation
- Code signing identity verification for app bundles
- Jamf Pro / Mosyle / Intune deployment support
Linux: What PM Adds
- PAM module integration — hooks into the auth stack
- Centralized sudoers management via PM console
- setuid/setgid binary monitoring and control
- auditd integration for SIEM forwarding
- Supports RHEL, Ubuntu, Debian, SUSE, Amazon Linux
macOS Blind Spot: In organizations where developers use macOS, this is typically the highest-risk segment of the fleet — powerful machines with local admin rights because "developers need it." LAPS provides zero coverage here. PM closes this gap with the same policy framework used on Windows.
Gap Analysis — Module 06
Gap: Endpoint MFA
& Session Recording
& Session Recording
Two additional capabilities frequently required by compliance frameworks and high-security environments: enforcing multi-factor authentication at the point of privilege elevation, and recording privileged sessions at the endpoint for forensic review.
CAP 07
Endpoint MFA at Point of Elevation
PM Only
MS LAPSNot Available
LAPS does not trigger MFA at any point. The local admin password retrieval from AD can be MFA-protected at the AD portal level, but there is no MFA enforcement at the moment a user attempts to elevate an application or run a privileged process on the endpoint itself.
› Why This Gap Matters for Compliance
NIST 800-53 IA-3, PCI DSS Requirement 8, and SOC 2 controls increasingly require MFA for privileged access. Without endpoint MFA, a stolen session or unlocked workstation gives an attacker direct access to privileged elevation without any second factor challenge.
Privilege ManagerCovered
PM can require MFA as part of the elevation dialog — before any elevation is granted. Integrates with: Duo Security, Microsoft Authenticator / Entra MFA, TOTP-based authenticators. The MFA challenge is embedded in the PM elevation prompt, so the user is authenticated at the exact moment privilege is requested — not just at login.
› MFA Integration Details
The MFA policy is configurable per application policy. You can require MFA for high-risk elevation events (e.g., running installers, debugging tools, network capture utilities) while allowing silent elevation for low-risk approved apps. MFA completion is logged alongside the elevation event, creating a strong non-repudiation audit trail.
CAP 08
Privileged Application Session Recording
PM Only
MS LAPSNot Available
LAPS records password retrieval events in the AD audit log but has no capability to record what a user does during an elevated session. Once the local admin account is used, all activity is outside LAPS's visibility entirely.
Privilege ManagerCovered
PM can record the screen activity during an elevated application session. Recording is policy-triggered — e.g., any time a user runs an elevated process that matches a "sensitive tool" policy. Recordings are stored in the PM vault and are searchable and playable. Integrates with Delinea Session Manager for full PAM-grade recording.
› Recording & Compliance Use Cases
Session recording satisfies requirements in: PCI DSS Requirement 10 (audit trails for privileged access), HIPAA technical safeguard requirements, financial services regulations requiring evidence of what privileged users did. Recordings can be retained per configurable policy and are tamper-evident. They are also invaluable for incident investigation — you can replay exactly what happened during an elevated session that preceded a security incident.
CAP 09
Behavioral Analytics & Anomaly Detection
PM Only
MS LAPSNot Available
LAPS does not analyze patterns of privilege use. It cannot alert on unusual elevation requests, abnormal application launch patterns, or deviation from established user behavior baselines.
Privilege ManagerCovered
PM's reporting engine surfaces patterns: which users are requesting the most elevations, which applications generate the most blocks, which machines show anomalous privilege request spikes. Integrates with SIEM for UBA (User Behavior Analytics) enrichment. Delinea Platform adds ML-assisted anomaly scoring on top of PM event streams.
Compliance Coverage Summary
| Compliance Requirement | LAPS Addresses | PM Addresses |
|---|---|---|
| Unique credentials per system (PCI DSS 8.6.1) | YES | YES |
| MFA for privileged access (NIST IA-3, PCI DSS 8.4) | NO | YES — At elevation point |
| Least privilege enforcement (CIS Control 5) | NO | YES — Local admin removal + elevation policies |
| Application control (NIST AC-3, CIS Control 2) | NO | YES |
| Privileged session audit trail (SOX, HIPAA, PCI) | PARTIAL — Password retrieval only | YES — Full session recording |
| Cross-platform privilege management | NO — Windows/AD only | YES — Win/Mac/Linux |
Module 07 — Complete Reference
Full Feature
Matrix
Matrix
A complete side-by-side reference of every capability area. Use this as a printable summary for stakeholder conversations, procurement decisions, and compliance documentation.
Credential Management
| Capability | MS LAPS | Privilege Manager |
|---|---|---|
| Randomized local admin passwords | YES — Core capability | COMPLEMENTARY — Use LAPS alongside PM for this |
| Automatic password rotation schedule | YES | VIA SECRET SERVER — Pair with PM for full coverage |
| AD / Entra ID credential storage | YES | N/A — Not PM's domain |
| Post-authentication password rotation | YES — Windows LAPS 2023+ | N/A |
Application Control
| Capability | MS LAPS | Privilege Manager |
|---|---|---|
| Block specific applications from running | NO | YES — By hash, cert, path, behavior |
| Allow-list enforcement | NO | YES |
| Silent application elevation by policy | NO | YES |
| Prompted elevation with justification capture | NO | YES |
| Approval workflow for elevation requests | NO | YES — With ServiceNow integration |
| Child process inheritance control | NO | YES |
| DLL injection blocking | NO | YES |
Platform Coverage
| Platform | MS LAPS | Privilege Manager |
|---|---|---|
| Windows (AD-joined) | YES | YES |
| Windows (Entra / Azure AD) | PARTIAL — New LAPS only | YES |
| macOS | NO | YES |
| Linux | NO | YES |
| Azure Virtual Desktop | PARTIAL | YES |
| Citrix / RDS | NO | YES |
Security Controls
| Control | MS LAPS | Privilege Manager |
|---|---|---|
| Local admin removal enforcement | NO | YES |
| MFA at point of elevation | NO | YES — Duo, Microsoft Authenticator, TOTP |
| Privileged session screen recording | NO | YES |
| Behavioral anomaly detection | NO | YES — Via PM reporting + Delinea Platform |
| SIEM event forwarding (every privilege decision) | PARTIAL — Password retrieval only | YES — All elevation, block, and audit events |
| Tamper-resistant audit log | PARTIAL — AD audit log | YES — PM vault + SIEM pipeline |
Recommended Architecture: LAPS and Privilege Manager are not mutually exclusive. The recommended architecture for mature organizations is both: LAPS (or Secret Server) managing the local admin account credential, and Privilege Manager enforcing application control and policy-based elevation. They operate at different layers of the privilege stack.
Module 08 — Practical Guidance
Decision
Scenarios
Scenarios
Five real-world organizational scenarios. Click each to see what LAPS alone provides versus what Privilege Manager adds. Use these with prospects to surface the right conversation about which gaps are most relevant to their environment.
SCENARIO 01
Mid-size enterprise with mixed Windows / macOS fleet and a growing developer team
›
LAPS Alone Provides
- Randomized local admin passwords on Windows machines only
- No coverage for any macOS endpoint
- Developer macOS machines remain fully unprotected at the privilege layer
- No application control prevents developer tools or npm/pip packages from running arbitrary code with admin rights
- No visibility into what elevated processes ran on any machine
Privilege Manager Adds
- Full policy enforcement on both Windows and macOS from one console
- Developer tools (Xcode, Wireshark, debuggers) elevated silently by policy — no local admin needed
- Package manager executions (npm, pip, brew) can be scoped, monitored, and controlled
- Complete audit trail of every elevated process across the entire fleet
- MFA enforcement for particularly sensitive developer tool elevations
SCENARIO 02
Healthcare organization subject to HIPAA with strict audit requirements
›
LAPS Alone Provides
- Evidence that local admin passwords are unique (HIPAA technical safeguard credit)
- No MFA enforcement at point of elevation — a gap in HIPAA access controls
- No session recording — cannot prove what a privileged user did
- Audit log shows password was retrieved but not what was done with it
- No application control — any application can run on any workstation
Privilege Manager Adds
- MFA at point of elevation closes HIPAA technical safeguard requirement
- Session recording provides evidence of what privileged users did — satisfies audit requirements
- Application control prevents unauthorized software on clinical workstations
- Full audit trail per user per device per application — directly usable in HIPAA audits
- Policy-based exception handling creates structured, documented access pathways
SCENARIO 03
Financial services firm post-ransomware incident evaluating endpoint controls
›
LAPS Alone Provides
- Prevents the same local admin hash being reused across machines (limits lateral movement)
- Does not prevent the initial ransomware payload from executing
- Does not prevent ransomware from installing persistence as the current user (who may still be local admin)
- No application control to block the dropper before it runs
- No blocking of unsigned executables from %TEMP% or download directories
Privilege Manager Adds
- Unsigned binary from %TEMP% blocked before execution — ransomware dropper fails at step 0
- Local admin removal means even if dropper runs, it cannot install service/persistence
- Application allow-listing on highest-risk segment limits execution to known-good apps
- Every blocked event generates a SOC alert — incident is surfaced immediately
- Lateral movement limited even further: no local admin account to abuse
SCENARIO 04
IT team fielding constant helpdesk tickets for application install requests
›
LAPS Alone Provides
- No self-service elevation — every application that needs admin rights requires a helpdesk call
- The only options are: grant local admin (risky) or deny everything (disruptive)
- No structured exception workflow for recurring legitimate needs
- Helpdesk volume stays high; user satisfaction low
Privilege Manager Adds
- Self-service elevation with justification capture — no helpdesk call for approved apps
- Common apps (Zoom updates, Adobe, Office plugins) silently elevated — users never notice
- Structured exception workflow routes non-standard requests to IT with full app metadata pre-populated
- Typical deployments reduce helpdesk elevation tickets by 40–60%
- IT spends time on policy optimization, not manual one-off installs
SCENARIO 05
Organization with Linux servers and workstations outside Active Directory
›
LAPS Alone Provides
- Zero coverage — LAPS does not support Linux
- Linux machines outside AD have no LAPS path at all
- sudo access on Linux endpoints is typically managed ad-hoc via local sudoers files
- No central visibility into who ran what with elevated rights on any Linux machine
Privilege Manager Adds
- PAM module integration — full privilege control on every Linux endpoint
- Centralized sudoers policy management — replace local file management entirely
- Every sudo command logged centrally with user, host, command, and timestamp
- setuid binary monitoring surfaces risky privilege escalation paths
- Same policy framework as Windows/macOS — one console for entire mixed fleet
Evaluator's Decision Checklist
- ✓Confirm whether organization has macOS or Linux endpointsIf yes, LAPS provides zero coverage on those platforms — PM required
- ✓Assess whether users currently hold local admin rightsIf yes, LAPS password rotation doesn't reduce that attack surface — PM's local admin removal does
- ✓Identify compliance frameworks in scope (HIPAA, PCI DSS, SOX)Most require MFA for privileged access and session audit trails — LAPS satisfies neither
- ✓Measure current helpdesk volume for elevation/install requestsPM self-service elevation policies typically reduce this 40–60%
- ✓Ask: "What happens when a user runs an untrusted binary?"If the answer is "it runs with their full user rights," PM's application control closes this gap
- ✓Determine whether LAPS and PM should coexist (recommended) or PM replaces LAPSFor most orgs: LAPS handles credential rotation; PM handles application control and elevation. Use both.
Module 09 — Knowledge Check
Five Questions
for Evaluators
for Evaluators
These questions test whether you can accurately communicate the LAPS/PM distinction in prospect and stakeholder conversations. Each question mirrors a common objection or misconception you'll encounter in the field.
QUESTION 01 / 05
A prospect says: "We already have LAPS deployed, so our local admin problem is solved." What is the most accurate response?
Agree — LAPS does solve local admin security
LAPS solves the password reuse problem but doesn't remove local admin rights or control what applications can run with those rights
LAPS is outdated — Privilege Manager fully replaces it
LAPS is only for non-Windows machines; PM handles Windows
CORRECT. LAPS ensures each machine has a unique, rotated local admin password — this breaks pass-the-hash lateral movement. But it doesn't remove local admin rights from users, doesn't control application execution, and doesn't prevent an attacker from using an active session's ambient privilege. Both problems exist; LAPS only solves one.
QUESTION 02 / 05
Which of the following is NOT a capability of Microsoft LAPS (including the modern Windows LAPS)?
Generating a unique random password for the local admin account
Storing the local admin password in Active Directory / Entra ID
Rotating the local admin password after it's been used
Preventing unauthorized applications from running on managed endpoints
CORRECT. Application control is explicitly outside LAPS's scope by design. LAPS is a credential management tool — it manages the local administrator account password lifecycle. It has no mechanism to evaluate, allow, or block application execution. That's Privilege Manager's domain.
QUESTION 03 / 05
An organization runs a Windows + macOS environment. They have LAPS deployed on Windows. How much of their macOS fleet does LAPS protect?
Fully — Windows LAPS 2023 supports Entra-joined macOS
Partially — LAPS works on macOS with the legacy agent
Zero — LAPS does not support macOS in any configuration
Only if the macOS machines are AD domain-joined via Jamf
CORRECT. Microsoft LAPS — legacy or modern Windows LAPS — provides zero coverage for macOS endpoints. It is a Windows-and-Active-Directory/Entra technology. macOS machines require a different solution. Privilege Manager deploys a native macOS agent that integrates with Authorization Services and supports deployment via Jamf, Mosyle, or Intune.
QUESTION 04 / 05
A compliance auditor asks for evidence that privileged sessions were recorded on endpoint workstations. Which tool can provide this?
Microsoft LAPS — it records the session when the admin password is used
Privilege Manager — it records screen activity during elevated application sessions, triggered by policy
Both LAPS and Privilege Manager record sessions equivalently
Neither — session recording requires a separate jump server solution
CORRECT. LAPS records that a password was retrieved (who, when, machine) — it has no visibility into what happened during the session that used it. Privilege Manager can record the screen activity during elevated application sessions. Recordings are policy-triggered, stored in the PM vault, and are tamper-evident. This satisfies PCI DSS Requirement 10, HIPAA audit trail requirements, and SOC 2 logging controls.
QUESTION 05 / 05
What is the recommended architectural relationship between Microsoft LAPS and Privilege Manager in a mature security deployment?
Replace LAPS with PM entirely — PM makes LAPS redundant
Use LAPS for workstations, PM for servers only
Use both: LAPS/Secret Server for credential rotation, PM for application control and policy-based elevation across all platforms
They conflict — deploying both creates policy contradictions
CORRECT. LAPS and Privilege Manager operate at different layers of the privilege stack and complement each other. LAPS (or Secret Server for more advanced credential vaulting) handles the credential rotation problem. PM handles the application control, least-privilege enforcement, cross-platform coverage, and elevation workflow layer. Using both closes the full privilege attack surface. They do not conflict — PM doesn't touch the local admin account password; LAPS doesn't touch application execution.
—
out of 5 correct