Credential Guard in Intune for CMMC Level 2

A stolen cached credential can turn one Windows 11 laptop into a pivot point. That’s why I treat Credential Guard as a serious hardening step when I build a CMMC-minded Intune baseline.

If you manage endpoints for a small contractor or an MSP client, the policy itself is only half the job. The harder part is checking prerequisites, avoiding conflicts, and proving the feature is truly active after rollout. That work starts before I create the policy.

Where Credential Guard fits in a CMMC Level 2 program

Credential Guard protects secrets that Windows would otherwise keep within reach of common credential theft techniques. In plain terms, it uses virtualization-based security, often shortened to VBS, to isolate credential material from the rest of the OS. As a result, attacks such as pass-the-hash and token theft get much harder.

For CMMC Level 2, that matters because the framework cares about protecting CUI and reducing preventable risk on endpoints. Still, I don’t treat Credential Guard as a magic box for compliance. CMMC Level 2 does not require this one Microsoft feature by name. The program is built around the 110 NIST SP 800-171 practices, and Microsoft’s CMMC Level 2 reference guide makes the same bigger point: the goal is protected systems, supported by evidence.

Credential Guard strengthens credential protection, but it does not by itself make a Windows 11 device CMMC Level 2 compliant.

I use it as one technical safeguard inside a broader security stack. That stack still needs MFA, controlled admin rights, patching, audit logging, incident response, secure configuration, and solid user lifecycle controls. In audits and readiness reviews, Credential Guard is helpful because it shows that the endpoint baseline is intentional, not casual.

My Small Business IT clients often meet this feature during Cloud Infrastructure work, Office 365 Migration planning, or Data Center Technology cleanup. The same discipline applies in Restaurant POS Support and Kitchen Technology Solutions, where shared Windows devices can hold valuable tokens. As part of Cybersecurity Services, I pair it with Endpoint Security, Device Hardening, Cloud Management, and Business Continuity & Security. That combination supports Innovative IT Solutions, Tailored Technology Services, Technology Consulting, Infrastructure Optimization, Digital Transformation, IT Strategy for SMBs, Secure Cloud Architecture, and Managed IT for Small Business. Over time, that’s how I act as a real Business Technology Partner.

Prerequisites I verify before touching Intune

Most failed deployments trace back to hardware or policy gaps, not the Intune setting itself. Before I roll out Credential Guard in Intune, I verify the Windows 11 device can run VBS cleanly and restart without drama.

This quick check keeps me honest:

Check	Why I care	How I verify it
UEFI and Secure Boot	Credential Guard works best with a trusted boot path	msinfo32 shows BIOS Mode and Secure Boot State
TPM 2.0	Strengthens platform trust and aligns with modern Windows 11 security baselines	tpm.msc or Intune hardware inventory
CPU virtualization support	VBS depends on hardware-assisted virtualization	BIOS or UEFI settings, Task Manager, vendor specs
No conflicting policy source	GPO, security baselines, and duplicate Intune profiles can clash	Intune per-setting status, gpresult, and policy review

I also check device edition, firmware age, and third-party drivers. Old kernel drivers, outdated BIOS versions, and legacy endpoint tools can block VBS. A pilot group catches this faster than a broad push.

The Windows 11 STIG guidance expects Credential Guard to be running on domain-joined Windows 11 systems. In cloud-first fleets, I apply the same standard to Entra-joined devices because the risk is the same. Also, some newer Windows 11 devices may already have Credential Guard active by default. I still deploy a policy, because I want a clear source of truth, reporting, and repeatable evidence.

How I configure Credential Guard in Intune for Windows 11

For most tenants, I use the Settings catalog because it exposes the exact Device Guard entries I want. In the Intune admin center, I go to Devices > Windows > Configuration > Create > New policy. Then I choose Windows 10 and later as the platform, because many Windows 11 controls still live under that label, and I select Settings catalog for the profile type.

I keep the setup simple and avoid mixing unrelated hardening controls into the same profile during the pilot.

1. I create a profile name that tells the story, such as “Win11 – Credential Guard – Pilot”.
2. In the Settings catalog, I search for Device Guard.
3. I add Turn On Virtualization Based Security and set it to Enabled.
4. I add Credential Guard Configuration and choose either Enabled with UEFI lock or Enabled without lock.
5. I review assignments and target a pilot device group first, not all Windows 11 endpoints.
6. I deploy the profile, then I plan for a restart because the device usually needs one before protection is active.

That choice between the two Credential Guard modes matters. I use Enabled without UEFI lock in pilots and early rollout rings because it is easier to reverse remotely if a device has a surprise issue. Once the hardware baseline is proven, I often move compliance-sensitive groups to Enabled with UEFI lock. That setting makes local or remote tampering harder, but it also makes rollback more involved.

I also keep other VBS controls in view. If I want memory integrity, Secure Launch, or a fuller hardening stack, I usually place them in separate profiles unless the hardware fleet is already validated. That keeps troubleshooting clean. When one profile changes five kernel-level settings at once, the conflict report gets muddy fast.

If your tenant also exposes template-based security profiles, you may see similar settings in other areas of the admin center. I still prefer the Settings catalog because the search is direct and the setting names stay familiar even when Microsoft shifts menu labels.

How I validate that Credential Guard is really on

A successful assignment in Intune is not the finish line. I want proof on the device.

First, I check the profile status in Intune. Under the policy, I review Device status and Per setting status. If the setting shows Conflict, Error, or Not applicable, I stop there and fix the cause before I tell anyone the control is in place.

Next, I verify the endpoint itself. On the Windows 11 device, msinfo32 is the fastest check. In System Information, I look for Virtualization-based security and then confirm that Credential Guard appears under Security Services Running. If it shows as configured but not running, the machine usually needs a reboot, a firmware fix, or a prerequisite review.

For script-based validation, I use Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard. If SecurityServicesRunning includes 1, Credential Guard is active. I also review the Microsoft-Windows-DeviceGuard/Operational log when I need more detail.

For audit prep, I save the Intune report, the device result, and a short note on the assigned policy. That extra record helps when I map technical evidence back to Microsoft’s CMMC 2.0 technical reference and a broader system security plan.

Troubleshooting conflicts, hardware gaps, and false positives

When policy sources collide

The most common issue I see is a conflict between Intune, Group Policy, and security baselines. Co-managed devices are famous for this. If one source enables VBS and another disables or leaves a related setting undefined, Intune may report a conflict even though the device looks healthy.

I pick one source of truth for Device Guard settings. Then I remove duplicates. If a client still has old GPOs for VBS, I phase those out before I call the Intune rollout stable.

When VBS prerequisites are missing

Sometimes the profile applies, but the feature never starts. In that case, I check BIOS or UEFI for virtualization support, Secure Boot, and TPM health. I also look at firmware age and driver health.

Older endpoint agents can interfere here. The same goes for legacy VPN, disk, or security drivers that hook deeply into the kernel. A clean pilot ring usually exposes that within days.

When the setting says enabled but protection isn’t running

This is where validation matters. A device can show the policy as applied while Credential Guard still isn’t active. Usually the fix is simple, restart the machine, verify the hypervisor started, and check msinfo32 again.

If I used UEFI lock and need to back out quickly, I remember that rollback is more restrictive. That’s another reason I start pilots without the lock. Once the fleet is stable, I tighten the setting for high-trust groups and document the change.

Conclusion

Credential Guard is one of the cleanest Windows 11 hardening wins I can deploy through Intune. It protects credentials where attackers often look first, and it gives me stronger evidence for a broader CMMC Level 2 security program.

The real value comes from doing the whole job, prerequisites first, policy next, validation last. When those three parts line up, Credential Guard stops being a box on a checklist and becomes a dependable control in the endpoint baseline.