🧱🪟💻ES - LSA Protection
LSASS is the process that holds live credentials in memory. This puts it behind protected-process glass so nothing else can reach in and copy them out.
What this policy is about 🧱
The Local Security Authority Subsystem, LSASS, is where Windows keeps live credentials while you are signed in: password hashes, Kerberos tickets, session tokens. It is also the single most popular target on a compromised machine, because reading its memory hands an attacker everything they need to move sideways across the network. The classic credential-dumping tools exist for exactly this one process.
This policy runs LSASS as a protected process (RunAsPPL), enforced with a UEFI lock. Once it is protected, only correctly-signed code may touch it, so an attacker who lands code on the box still cannot read secrets out of LSASS.
Most controls try to keep malware off the machine. This one accepts that something might get on, and makes sure that even then it cannot walk out with the credentials. It is the Gringotts vault door behind the front door.
Why this matters 🕵️
A single foothold on one laptop is not the disaster; the disaster is when that foothold yields a domain admin token scraped from LSASS and the attacker is suddenly everywhere. Protecting LSASS breaks that chain at its most common link. It is one of the highest-leverage hardening settings on Windows: cheap, built in, and it neutralises a technique that shows up in a huge share of real intrusions.
🛠️ Configuration
Where: Intune admin center → Devices → Configuration → Create → Windows → Settings catalog → Local Security Authority.
| Setting | Value |
|---|---|
| Configure LSASS to run as a protected process | Enabled with UEFI lock |
| Assignment, include | All devices |
| Assignment, exclude | None (standard exclusions only) |
The UEFI lock is what stops the protection being quietly turned off again by malware or a rogue local change; it persists the setting in firmware.
Caveats ⚠️
Old LSASS plugins can break. Some smartcard drivers, third-party authentication providers, and older security agents inject into LSASS and will fail once it is protected. Anything modern is signed correctly and works fine, but validate on a pilot ring before a broad roll-out, and check the Windows audit events for blocked LSASS plugins first.
The UEFI lock is deliberately sticky. Because it is locked in firmware, turning LSA Protection back off is not a simple unassign: it needs an explicit disable step (and on some hardware a physical presence action). That stickiness is the point; just know it before you enable it fleet-wide.
It is enabled by default on new installs, but not always on upgrades. Devices that upgraded from an older Windows build may not have it on, so pushing it explicitly closes that gap.
License and reversibility. Included in Business Premium. Tattoo by design (UEFI lock): plan a deliberate disable rather than an unassign if you ever need to reverse it.
🔗 Related
- 🧱🪟💻ES - Attack Surface Reduction Rules: includes the ASR rule that blocks credential theft from LSASS, a behavioural layer on top of this structural one.
- 🧱🪟💻ES - DMA Guard: stops the other route to in-memory secrets, a plugged-in device reading RAM directly.
Assume something gets in. Make sure it still cannot read the credentials on its way out. 🧱