Palanikumar AnnamalaiMicrosoft Cloud & Security Architect

    Type to search 66 articles.

    Practical engineering guidance

    Protecting LSASS: LSA protection, Credential Guard and what each stops

    Two distinct protections with overlapping names, both now on by default in recent Windows. Knowing which one blocks which attack tells you what remains exposed.

    Series: Security hardening

    • Windows
    • Credential protection
    • Security

    The Local Security Authority Subsystem Service holds the credential material that makes a Windows session work: password hashes, Kerberos tickets, and credentials applications have stored. An attacker with administrative rights on a machine has historically been able to read that memory and walk away with credentials that work elsewhere.

    That is the mechanism behind lateral movement, and it is the reason for the account separation in administrative tiering. Two Windows features reduce it, they are frequently confused, and they protect against different things.

    The threat

    An attacker gains administrative rights on a workstation — through a phishing payload, an unpatched application, or a local privilege escalation. They then read LSASS memory and extract:

    • NTLM password hashes, usable directly in pass-the-hash attacks.
    • Kerberos ticket-granting tickets, usable in pass-the-ticket attacks.
    • Cached domain credentials, which can be cracked offline.
    • Credentials stored by applications as domain credentials.

    The value of the haul depends entirely on who has signed in to that machine. A workstation where only its own user has ever signed in yields one user’s credentials. A server where a domain administrator once signed in to fix something yields the directory.

    Exposure: what protects what

    LSA protection

    LSA protection — historically configured through the RunAsPPL registry value — runs LSASS as a protected process. Other processes cannot inject code into it or read its memory, even with administrative rights, unless they are signed appropriately.

    What it stops: ordinary memory-dumping tools reading LSASS. This is a large proportion of the commodity tooling.

    What it does not stop: an attacker who can load a signed kernel driver, or who can disable the protection and reboot. It raises the bar considerably; it does not make the credentials unreadable in principle.

    It is configured at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa, with RunAsPPL as a REG_DWORD. The value matters: 1 enables it with a UEFI variable, which makes it harder for an attacker to turn off by editing the registry; 2 enables it without the UEFI variable, which is easier to reverse remotely if it causes a problem.

    LSA protection is enabled by default in Windows 11.

    Credential Guard

    Credential Guard uses virtualisation-based security. Rather than protecting the LSASS process, it moves the secrets out of it entirely, into an isolated process — LSAIso.exe — running in a VBS-protected environment that the rest of the operating system, including the kernel, cannot read.

    What it stops: extraction of NTLM hashes, Kerberos ticket-granting tickets and application-stored domain credentials, even from an attacker with kernel-level access on the running system. This is a genuinely different security property from LSA protection.

    What it does not stop:

    • Keylogging. A credential typed on a compromised machine is captured before it reaches any protected store.
    • Abuse of a live session. The attacker cannot extract the ticket, but they can use the session while the user is signed in.
    • Credentials that are not domain credentials. Local accounts and some stored credential types are outside its scope.
    • Attacks against the directory itself, or against a compromised domain controller.

    Starting in Windows 11 version 22H2 and Windows Server 2025, Credential Guard is enabled by default on domain-joined, non-domain-controller systems that meet the hardware requirements.

    One detail matters for estates that have been managed for a while: if Credential Guard was explicitly disabled before the device was updated, the default enablement does not overwrite that setting. The device continues with Credential Guard off after the upgrade. So an organisation that disabled it years ago for a compatibility reason may be running current Windows with the protection still off, and nothing will say so.

    Assessment: find out what is actually running

    Do not assume the default applies. Check.

    # Credential Guard and VBS runtime state.
Get-CimInstance -ClassName Win32_DeviceGuard `
    -Namespace 'root\Microsoft\Windows\DeviceGuard' |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

# LSA protection configuration.
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'RunAsPPL' `
    -ErrorAction SilentlyContinue |
    Select-Object RunAsPPL

    In the Win32_DeviceGuard output, the distinction between SecurityServicesConfigured and SecurityServicesRunning is the important one. Configured but not running means something — hardware, firmware, or a conflicting component — is preventing it, and the device is not protected despite the policy saying it is. A value of 1 in the running list corresponds to Credential Guard.

    msinfo32 reports the same information in a readable form, which is useful when checking a single machine by hand.

    Run this across the estate rather than on a sample. The interesting finding is always the group of machines where the configuration and the runtime state disagree.

    Hardening: deployment considerations

    Credential Guard has real compatibility consequences, and they are the reason it was historically disabled:

    • Unconstrained Kerberos delegation does not work with Credential Guard. This is a feature, not a defect — unconstrained delegation should be removed anyway, for the reasons in Kerberos delegation — but it will break a working application if you have not migrated it first.
    • DES and RC4 Kerberos encryption are not supported for the protected credentials.
    • Some third-party credential providers and authentication packages are incompatible. This is the category that produces surprises, because it includes VPN clients and smart card middleware.
    • Certain virtualisation scenarios need attention, since VBS itself requires virtualisation extensions.

    The sequence I would follow:

    1. Audit current state across the estate with the commands above.
    2. Identify dependencies on unconstrained delegation, DES and RC4, and remove them. This is the longest step and it is worth doing on its own merits.
    3. Inventory third-party authentication components — VPN, smart card, biometric — and check compatibility with the vendor.
    4. Pilot on a representative group, including someone who uses the VPN and someone with a smart card.
    5. Enable LSA protection with the UEFI variable where you are confident, and without it where you may need to reverse it remotely.
    6. Widen in stages, watching the runtime state rather than the policy state.

    Do not enable these and stop there. They reduce the value of compromising a machine; they do not prevent the compromise. The credential hygiene that matters most is still not signing in with privileged accounts on lower-tier machines.

    Detection

    • Alert on configuration changes to RunAsPPL and to the Device Guard settings. An attacker who wants LSASS memory will try to disable the protection and reboot, and that sequence is detectable.
    • Watch for LSASS access attempts. Defender for Endpoint surfaces these, and they are a high-quality signal because legitimate software rarely reads LSASS memory.
    • Monitor the runtime state estate-wide and alert on devices where Credential Guard is configured but not running. That gap is where the actual exposure sits.

    Validation

    • Confirm SecurityServicesRunning includes Credential Guard on pilot devices, not merely that it is configured.
    • Confirm LSA protection is active, and that the machine boots and authenticates normally.
    • Test the compatibility cases deliberately: VPN connection, smart card sign-in, any application using delegation.
    • Attempt a credential dump with an approved tool, in a controlled test, and confirm it fails. This is the only validation that tests the actual property you care about, and it needs explicit authorisation and a test machine.

    Rollback

    LSA protection without the UEFI variable is removed by deleting the registry value and rebooting. With the UEFI variable, removal requires the documented procedure, which is deliberately more involved — that is the protection working as intended, and it is why the choice of value 1 versus 2 matters at deployment time.

    Credential Guard is disabled through policy and a reboot, with the documented steps for clearing the VBS configuration where required. Plan this before enabling it, because the scenario in which you need it is a compatibility failure affecting people’s ability to work.

    Verification and limits

    LSA protection’s mechanism and RunAsPPL values, LSA protection being enabled by default in Windows 11, Credential Guard’s use of VBS and the isolated LSA process, its default enablement from Windows 11 22H2 and Windows Server 2025 on qualifying domain-joined systems, and the behaviour where a prior explicit disable is preserved through an upgrade were checked against current Microsoft documentation on 20 September 2026.

    Nothing here was deployed or tested for this article. The assessment commands are read-only. Enabling these protections can break authentication for applications relying on delegation, DES, RC4 or third-party credential providers — audit those dependencies first, pilot, and know your rollback path before you enable the UEFI-locked variant. Default enablement depends on version, edition, licensing and hardware, so verify the runtime state rather than assuming.

    References