Credential Guard and VBS: Isolating Windows Credentials From Admin Level Malware

An attacker with local administrator rights on a Windows device can normally read LSASS memory and walk away with NTLM hashes and Kerberos tickets for every account that has signed in there. Credential Guard moves those secrets into a process protected by virtualisation-based security (VBS), so even code running as SYSTEM cannot read them. It is now on by default on many Windows 11 and Windows Server 2025 devices, which means some estates have it without having planned for it, and others think they have it when it is not running. This guide goes deeper than the Windows Endpoint Hardening Guide: how the isolation works, which accounts and protocols it changes, how to deploy, verify and roll it back, and what it does not protect. It is for endpoint engineers, Active Directory administrators and detection engineers.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• It protects derived credentials, not every secret. Credential Guard isolates NTLM password hashes, Kerberos ticket granting tickets (TGTs) and credentials applications store as domain credentials; it does not protect the SAM, the Active Directory database or generic saved passwords.
• Default enablement is not the same as hardened enablement. Windows 11 22H2 and Windows Server 2025 turn it on by default on eligible devices, but without UEFI lock, so an attacker with admin rights or a stray policy can switch it off.
• Legacy authentication breaks on purpose. NTLMv1, Kerberos DES, unconstrained delegation and MS-CHAPv2 single sign-on stop working; inventory them first and treat each break as a finding to fix, not a reason to disable.
• Verify the running state. Use Win32_DeviceGuard SecurityServicesRunning and WinInit events 13 to 17, not the presence of LsaIso.exe in Task Manager or an assigned policy.
• Pair it with LSA protection and memory integrity. Credential Guard, LSASS as a protected process and hypervisor-protected code integrity close different gaps; together with passwordless sign-in they cut off most LSASS based credential theft (T1003.001).

How identity and access work in Credential Guard and VBS

VBS uses the Windows hypervisor to create an isolated memory region that the normal operating system kernel cannot read or modify. Credential Guard runs an isolated LSA process, LsaIso.exe, inside that region. The normal LSASS process still handles authentication requests, but it talks to LsaIso over a remote procedure call channel and never holds the long-term secrets itself. Microsoft states that malware running in the operating system with administrative privileges cannot extract secrets protected by VBS, which is what defeats pass-the-hash (T1550.002) and pass-the-ticket (T1550.003) built on LSASS dumping.

The practical consequence: Credential Guard raises the cost of lateral movement from a compromised workstation, but an attacker who already has a password, or who reaches a domain controller, is unaffected. Microsoft recommends deploying it alongside a move to Windows Hello for Business, FIDO2 security keys or smart cards. See the Pass-the-Hash and Pass-the-Ticket Guide.

Requirements and default enablement

• Hardware and firmware: VBS and Secure Boot are listed as required; a TPM (1.2 or 2.0, discrete or firmware) is recommended because it binds secrets to hardware, and UEFI lock is recommended so the setting cannot be removed by a registry change.
• Licensing: Windows Enterprise and Education editions, with Windows Enterprise E3/E5 or Education A3/A5 entitlement. Pro, Pro Education and SE are not supported, although Microsoft notes Pro devices previously licensed for Enterprise may still have it running; check for the IsolatedCredentialsRootSecret value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0.
• Default on: Windows 11 22H2 and later, and Windows Server 2025 and later on domain-joined servers that are not domain controllers, when licence and hardware requirements are met and it has not been explicitly disabled. An explicit disable set before the upgrade is kept.
• Virtual machines: Hyper-V generation 2 VMs on a host with an IOMMU. It protects against attacks inside the VM only, not from the host; generation 1 Hyper-V and Azure VMs are not supported.

Admin roles and privileged access

Credential Guard matters most on the devices where privileged accounts sign in, because those are the credentials an attacker wants to harvest. Plan coverage by tier rather than by device count.

• Remote administration: saved RDP credentials stop working, and CredSSP can no longer delegate SSO credentials. Use Remote Credential Guard or Restricted Admin mode for RDP to servers so admin credentials are not sent to the target, and use Kerberos constrained delegation or resource-based constrained delegation where a service must act on behalf of a user. See the Kerberos Delegation Security Guide.
• Local administrator accounts: because SAM hashes are outside its scope, a shared local admin password still allows lateral movement. See the LAPS Guide.
• Who can turn it off: without UEFI lock any local administrator or Group Policy editor can disable it with a reboot. Restrict who can edit the Device Guard GPO or Intune profile and alert on changes, since disabling a protection maps to Disable or Modify Tools (T1685).

Integrations, API tokens and service accounts

Credential Guard does not protect API tokens or application secrets, but it changes how several integrations authenticate. Most outages after enablement trace back to one of these.

• Wi-Fi and VPN on MS-CHAPv2: PEAP-MSCHAPv2 and EAP-MSCHAPv2 lose SSO, so users must type credentials and cannot save them. Microsoft also notes Cisco ISE configurations that use MSCHAPv2 do not work. The fix is certificate based PEAP-TLS or EAP-TLS. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
• Third-party security support providers and authentication packages: non-Microsoft SSPs and APs can no longer request password hashes from LSA, and undocumented APIs such as KerbQuerySupplementalCredentialsMessage are unsupported. They still receive password notifications. Inventory registered packages, because the same registration point is abused for persistence (T1547.005).
• Service accounts: services that use Kerberos, such as file shares and remote desktop, keep working. Applications that need unconstrained delegation, DES or NTLMv1 fail. Treat these as service account findings: move to group managed service accounts or constrained delegation. See the NTLM Deprecation and Elimination Guide.
• Kerberos PKINIT with RSA key exchange: Microsoft lists PKINIT using RSA rather than Diffie-Hellman among the protocols blocked for SSO and supplied credentials. Check smart card and certificate sign-in configurations. See the Kerberos PKINIT and Certificate Mapping Guide.
• Vendor software: Microsoft names products that do not support it (some endpoint clients, VMware Workstation on Windows 10 hosts, some ThinkPad models) and says the list is not complete. Ask vendors for a statement and test, including software that tries to hook LsaIso.exe.
• TPM clearing and DPAPI: clearing the TPM destroys the key VBS uses, so saved Windows credentials are lost and user DPAPI recovery depends on domain controller connectivity. Clear TPMs only while connected to the domain network, and note that deallocating an Azure VM has the same effect on TPM bound data.

Deploying Credential Guard and VBS

Enable Credential Guard before domain join or the first domain user sign-in where possible: Microsoft notes that secrets present before enablement may already be compromised. The controls are configured through Intune (Settings catalog, category Device Guard) or Group Policy under Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security.

1. Inventory blockers: collect NTLM Operational events and authentication logs for NTLMv1, MS-CHAPv2 Wi-Fi and VPN profiles, unconstrained delegation on computer and service accounts, DES enabled accounts and third-party SSPs. Fix the high volume items before rollout.
2. Check hardware readiness: query Win32_DeviceGuard for VirtualizationBasedSecurityStatus and AvailableSecurityProperties, and check Secure Boot and TPM state, so you know which devices cannot run VBS.
3. Pilot without lock: deploy LsaCfgFlags = 2 and LSA protection in audit to an IT ring that includes admins, VPN and Wi-Fi users and remote workers. Watch NTLM events 4013 and 4014 and help desk tickets for two to four weeks.
4. Broaden in rings: expand by business unit, holding back groups with known legacy dependencies until their fixes land.
5. Lock high value devices: move privileged access workstations and admin jump hosts to Enabled with UEFI lock once stable, then the general fleet if your support model allows physical presence for removal.
6. Roll back safely: for unlocked devices set the policy to Disabled (or LsaCfgFlags = 0) and restart. For locked devices, also run the documented SecConfig.efi boot procedure with the DISABLE-LSA-ISO option, which needs someone at the console to confirm the firmware prompt. For LSA protection with lock, use Microsoft's LsaPplConfig.efi opt-out tool. For a VM, opt out from the host with Set-VMSecurity -VirtualizationBasedSecurityOptOut $true.

Decision guidance: small organisations on Intune with Enterprise E3 licensing can usually accept the default enablement on new devices, then add UEFI lock to admin devices only. Large estates with Hyper-V clusters, third-party VPN clients and legacy RADIUS should explicitly disable Credential Guard on affected servers before upgrading to Windows Server 2025, fix the dependency, then re-enable, rather than discovering the break during an upgrade weekend. If you must choose between UEFI lock everywhere and a reliable remote rollback, choose lock for tier 0 and tier 1 devices and unlocked for the rest.

Logging and detection

• Detect switch-off: alert when a device that previously reported Credential Guard running reports event 15 or 16, or SecurityServicesRunning no longer includes 1, and when LsaCfgFlags, RunAsPPL or the Device Guard keys change. Correlate with recent admin logons.
• Detect attempted theft: Credential Guard does not stop the attempt to open LSASS. Keep endpoint detection for handle access to LSASS and memory dump creation, because a blocked dump is still an indicator that someone has admin rights. See the Active Directory Security Monitoring and Event IDs Guide.

Metrics:

• Percentage of eligible devices where SecurityServicesRunning includes Credential Guard, split by tier.
• Percentage of tier 0 and tier 1 devices running with UEFI lock.
• Count of NTLM 4013 and 4014 events per week, trending to zero.
• Number of accounts trusted for unconstrained delegation and DES enabled accounts.
• Devices that cannot run VBS (hardware or firmware), with a replacement date.

Hardening baseline

• Credential Guard: enabled on all eligible workstations and member servers; UEFI lock on privileged access workstations and jump hosts; explicitly disabled only on domain controllers, Exchange and documented exceptions with an owner and expiry date.
• VBS platform: Secure Boot on, TPM 2.0 present, IOMMU enabled in firmware; firmware settings password protected so VBS prerequisites cannot be turned off at the console.
• LSA protection: RunAsPPL enforced after a clean audit period, including on domain controllers where Credential Guard is not used.
• Memory integrity: enabled after driver compatibility testing, piloted without UEFI lock because locked recovery requires disabling Secure Boot.
• Legacy protocols removed: NTLMv1, WDigest credential caching, DES, unconstrained delegation and MS-CHAPv2 replaced, not tolerated.
• Passwordless sign-in: Windows Hello for Business or FIDO2 for interactive logons so there is less to steal in the first place. See the Windows Hello for Business Guide.

Common misconfigurations

• Trusting the default: assuming Windows 11 enabled it everywhere. Devices on Pro licences, without Secure Boot, or with a pre-upgrade explicit disable do not run it, and default enablement has no UEFI lock.
• Checking the wrong signal: seeing LsaIso.exe or an assigned policy and reporting compliance. Microsoft says not to rely on Task Manager; report SecurityServicesRunning and WinInit 13.
• Disabling it to fix Wi-Fi: turning Credential Guard off fleet wide when MS-CHAPv2 SSO breaks, instead of moving to EAP-TLS. Microsoft calls this the faster but less secure option because stored domain credentials become exposed again.
• Enabling it on domain controllers: it gives no added protection there and can break applications, while the real DC risks (NTDS extraction, DCSync) are untouched. See the Active Directory and Entra ID Hardening Guide.
• Locking before piloting: deploying UEFI lock to the whole fleet on day one, then needing physical presence on thousands of devices to roll back an incompatible VPN client.
• Ignoring what remains exposed: leaving shared local admin passwords, generic saved credentials and plaintext secrets on disk, so attackers simply switch from LSASS dumping to other credential sources.

Practitioner checklist

• Report Credential Guard running state per device from Win32_DeviceGuard, not policy assignment.
• Inventory NTLMv1, MS-CHAPv2, DES, unconstrained delegation and third-party SSPs before broad rollout.
• Explicitly decide, per server role, whether Windows Server 2025 default enablement is acceptable before upgrading.
• Pilot with LsaCfgFlags = 2, then apply UEFI lock to privileged access workstations and jump hosts.
• Enforce LSA protection after reviewing CodeIntegrity 3065 and 3066 audit events.
• Keep Credential Guard off domain controllers and Exchange; protect them with tiering and LSA protection.
• Alert on WinInit 15 and 16 and on changes to Device Guard and LSA registry keys.
• Document the UEFI lock removal procedure and who can perform it with physical presence.
• Pair the rollout with Windows LAPS and passwordless sign-in for admin accounts.

Standards and references

• Microsoft Learn: Credential Guard overview
• Microsoft Learn: Configure Credential Guard
• Microsoft Learn: Credential Guard considerations and known issues
• Microsoft Learn: Configure added LSA protection
• Microsoft Learn: Enable memory integrity
• MITRE ATT&CK: OS Credential Dumping: LSASS Memory
• MITRE ATT&CK: Use Alternate Authentication Material: Pass the Hash
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · Pass-the-Hash and Pass-the-Ticket Guide · LAPS Guide · NTLM Deprecation and Elimination Guide · Kerberos Delegation Security Guide