What happens when one shared local admin password lives on every Windows device? One stolen credential can act like a master key. That’s why I treat CMMC Level 2 LAPS as a practical control, not a nice-to-have.
Windows LAPS, pushed through Intune and backed by Entra ID, lets me rotate local administrator passwords, lock down who can read them, and keep retrieval activity auditable. For CMMC Level 2, that supports least privilege, credential protection, and stronger access control. Still, it supports compliance, it doesn’t promise certification on its own.
Start with the right device, license, and role model
Before I build policy, I verify the basics. If the join state, licensing, or admin scope is off, the rollout will wobble from day one. I also map the design back to Microsoft’s Entra guidance for CMMC Level 2, because the control story matters as much as the setting itself.
Here’s the baseline I use:
| Area | What I confirm first | Why it matters |
|---|---|---|
| Licensing | Intune plus Entra ID P1 or P2, often through Microsoft 365 or EMS E3/E5 | Needed for policy deployment, role scoping, and cloud identity controls |
| Device OS | Windows 10 or 11 Pro, Enterprise, or Education | These are the common supported client scenarios for Windows LAPS |
| Join model | Entra-joined devices for Entra backup, or a hybrid design that matches the backup target | A mismatch here is a common failure point |
| Roles | Intune rights to create profiles, plus a tightly scoped password-reader role such as CloudLapsReader | Supports least privilege and auditability |
The takeaway is simple: match the device identity model to the password backup location.
If I’m protecting CUI, I also confirm the tenant boundary before rollout. In some contracts, that means GCC High or another government-aligned cloud. I don’t guess on that point.
I also separate duties early. The team that deploys policy should not be the same broad group that can read local admin passwords. Instead, I create a small Entra security group for retrieval, keep membership tight, and document the approval path. That single step helps CMMC evidence later and reduces casual access.
How I configure Microsoft LAPS in Intune for Entra ID-backed devices
Once the prerequisites are clean, I pilot first. I never start with every workstation.
- Create two Entra groups. I build one pilot device group and one password-reader group. If Privileged Identity Management is available, I prefer eligible access for readers.
- Create the Intune policy. In the Intune admin center, I go to Devices, Configuration, Create, then choose Windows 10 and later with the Settings catalog. I search for Local Administrator Password Solution.
- Set the core LAPS options. I enable LAPS, select Microsoft Entra ID as the backup directory, and set a rotation period that fits risk, often 30 days or less. I also set password complexity and length to strong values, and if my support process allows it, I use a post-authentication reset so a revealed password doesn’t live long.
- Scope the policy to the pilot group. I assign only Entra ID-backed test devices first. Then I sync those devices from Intune or from the Company Portal.
5. Validate backup and retrieval. After policy applies, I open the device record in Entra ID and check the Local administrator password recovery area. Only approved readers should see the password and rotation metadata.
6. Watch the logs. I review Intune device status, Entra audit activity, and the local LAPS operational log on the endpoint. That gives me both deployment proof and retrieval proof.
If the join state and the backup target don’t match, LAPS won’t save you. It will just fail quietly and burn pilot time.
When I want a quick screen-by-screen cross-check, I compare my setup against this recent Intune LAPS walkthrough. I also like this Intune and Entra setup guide because it calls out the join-state constraint clearly.
How I validate, audit, and troubleshoot the rollout
After deployment, I validate like an auditor would. First, I run dsregcmd /status on a test device and confirm the join state. Next, I confirm the Intune profile landed. Then I check that the device object in Entra shows password recovery data for authorized staff only.

If something breaks, I start with the boring stuff because that’s usually the real issue. Wrong group assignment, stale device sync, policy conflict with old LAPS or GPO, or missing reader role, those cause most failures. If the password doesn’t rotate, I check the local LAPS event log and confirm the managed local admin account exists and isn’t blocked by another policy.
For CMMC Level 2 evidence, I save screenshots of the Intune policy, group membership approvals, Entra retrieval logs, and a sample device result. I also write down who can retrieve passwords, how access gets approved, and how often the team reviews membership. That gives me auditability, not just a working tool.
This work also fits a bigger service picture. In my Small Business IT projects, LAPS supports Cloud Infrastructure, Cloud Management, Office 365 Migration, and Data Center Technology planning. The same discipline strengthens Cybersecurity Services, Endpoint Security, Device Hardening, and even Restaurant POS Support or Kitchen Technology Solutions, where shared local admin accounts still show up. As a Business Technology Partner, I tie LAPS to Technology Consulting, Infrastructure Optimization, Digital Transformation, IT Strategy for SMBs, Secure Cloud Architecture, Managed IT for Small Business, Business Continuity & Security, and other Tailored Technology Services. Those are the kind of Innovative IT Solutions that hold up under review.
CMMC Level 2 LAPS works best when I keep it small, controlled, and provable. I start with a pilot, lock down retrieval rights, validate the logs, and only then expand scope. That approach gives me stronger least privilege, better audit evidence, and fewer surprises when assessment time arrives.
Discover more from Guide to Technology
Subscribe to get the latest posts sent to your email.
