Local Security Policy (secpol.msc): The Settings That Matter, Plus LSA Protection

A greyed-out setting, a locked-out user and a pentest finding that says "LSASS memory dumped" all point at the same place. Every one of them is answered somewhere in a console most technicians open twice a year and never fully read. This guide walks the Local Security Policy console (secpol.msc) node by node, names the settings worth setting on every machine, and then covers LSA protection, the switch that decides whether a dumped lsass.exe hands over your passwords.

TL;DR

• What it is. secpol.msc is the local half of Group Policy's Security Settings: password and lockout rules, audit policy, user rights and the Security Options list, for one machine.
• Who wins. A domain GPO or an Intune policy overrides it at the next refresh, and a greyed-out setting means one already has.
• What to set. Lockout at 10, machine inactivity limit at 900 seconds, NTLMv2 only, UAC auto-deny for standard users, and audit logon plus lockout. The table below carries the Microsoft baseline values.
• LSA protection. Makes lsass.exe a protected process so nothing unsigned can read its memory. Run audit mode first, because unsigned smart card drivers and password filters stop loading.
• Credential Guard. Moves the secrets out of lsass.exe entirely. Enterprise and Education only, on by default since Windows 11 22H2.

What secpol.msc Is, and What It Is Not

Open Run, type secpol.msc, and the console that appears is a filtered view of something you already know. Every node in it exists inside the Local Group Policy Editor under Computer Configuration, Windows Settings, Security Settings. Microsoft built the separate console so a technician can reach the security half without scrolling past Administrative Templates, and that is the whole difference. If you have used the Group Policy Editor, you have already used this.

Five nodes do the work. Account Policies holds the password and lockout rules. Local Policies holds three children: Audit Policy, User Rights Assignment and Security Options. Advanced Audit Policy Configuration is the newer, finer-grained audit tree that overrides the legacy one when both are set. Windows Defender Firewall with Advanced Security and the application control nodes round it out, and the firewall half has its own console anyway.

The word "local" is the part that matters. These settings live in the machine's own security database, and they are the lowest rung on the precedence ladder. Microsoft lists the order, from highest to lowest, as organizational unit policy, domain policy, site policy, then local computer policy. On a domain-joined machine, anything a GPO sets wins at the next Group Policy refresh, and the console tells you so by greying the setting out and swapping its icon for a pair of servers with a scroll. On an Intune-managed machine, the MDM policy plays the same role. Editing a greyed-out value is not blocked, it is pointless: the next refresh puts it back.

That makes secpol.msc the right tool for exactly two jobs. Workgroup machines, where there is no GPO above it, and the one-off test where you want to see what a setting does before it goes into policy for two hundred machines.

Why It Is Missing on Windows Home

Windows 11 Home does not ship the console, and neither does Windows 10 Home. Run secpol.msc on one and Windows reports that it cannot find the file. The same is true of gpedit.msc. Microsoft lists Local Security Policy and Group Policy as Pro, Enterprise and Education features, and that is the supported answer.

The unsupported answer is all over the search results, and a technician will meet it on a client's machine sooner or later. A pair of DISM loops installs the Group Policy client tools and extensions packages that already sit in the Windows servicing folder on Home, and after a restart both consoles open. The walkthrough below shows the steps, and the view count tells you how many people have done it.

Treat it as a lab trick, not a fix. The console appears, but Home still lacks the Group Policy client service, so a good share of the settings display without applying, and nothing about the edition changes for support or licensing purposes. If a business machine needs these settings, it needs a Pro licence, and if the only thing it needs is a lockout rule, Home can do that from an elevated prompt without any console:

code
net accounts /lockoutthreshold:10 /lockoutduration:15 /lockoutwindow:15 /minpwlen:14

That command writes the same values the console would, and net accounts on its own reads them back.

The Settings a Technician Touches Most

Of the few hundred entries in the console, perhaps fifteen come up in tickets. They cluster in four places, and for each one there is a value that Microsoft's own security baseline ships, which is the value to reach for unless you have a reason not to. The baseline column comes from the Intune security baseline for Windows, version 26H2, as published on Microsoft Learn in September 2026. The lockout threshold row comes from Microsoft's account lockout guidance, because the MDM baseline does not set it.

A few of those rows deserve a sentence each.

Password length. The console caps the slider at 14. Microsoft's own password length page still says a longer value "isn't supported at this time", and the way past it is the separate Relax minimum password length limits setting, added in Windows 10 version 2004. Set that first, then the length. On the wider question of what people pick when you let them, the most common passwords post has the lists attackers try first.

Lockout. Ten attempts is the number Microsoft's baseline suggests as "an acceptable starting point", and since the Windows 11 Insider build 22528 it is the default on a fresh install. Zero means never lock, which stops an attacker from locking every account on purpose but also means a brute-force attempt runs until it succeeds. The duration and the reset window have to be set together, and the duration cannot be shorter than the reset window.

Machine inactivity limit. This is the setting behind the screen lock, measured in seconds. Nine hundred is fifteen minutes. It locks the session when the user stops typing, when the screen saver starts, or when the display turns off, which is why it interacts with the power plan in the way the screen timeout post describes.

LAN Manager authentication level. The registry value is LmCompatibilityLevel under the Lsa key, from 0 (send LM and NTLM) to 5 (NTLMv2 only, refuse LM and NTLM). Workstations ship with the value absent, which behaves as level 3, and the baseline wants 5. The r/sysadmin thread below is the exact confusion: a GPO set on the domain, no registry value on the Windows 10 clients, and a reply answering that the default is 3 for compatibility and the ideal is 5.

User Rights Assignment. No baseline value fits in a table because the right values are group names. The two that cause tickets are Allow log on locally and Deny log on locally, and the deny wins when an account is in both. Put Everyone in the deny list and nobody signs in, which Microsoft's own page warns about in one line. The useful entries are Deny log on through Remote Desktop Services for the local Administrators group on workstations, and Deny log on as a service and as a batch job for ordinary user accounts. Scope them by group, never by user, which is the same discipline the RBAC explainer applies to everything else.

Interactive logon message. The title and text settings put a banner on the sign-in screen. It does nothing technical, and legal or compliance teams ask for it often enough that it is worth knowing where it lives.

Four of these settings go wrong in the field more than the rest combined, and they go wrong in the same way each time.

Seeing the Effective Result

The console shows what is set locally. It does not show what is winning. Four commands do, and they belong on every technician's list.

gpresult /h report.html writes the Resultant Set of Policy for the machine and the signed-in user to a page you can read, including which GPO set each security setting. secedit /export /cfg C:\temp\secpol.inf dumps the machine's effective security database to a text file, with every password, lockout, audit and user rights value in it, and that file is also what you diff against last month's. auditpol /get /category:* prints the audit policy that is in force, which matters because the Advanced Audit tree silently overrides the legacy one. And Get-LocalUser plus Get-LocalGroupMember Administrators tells you who the user rights are being assigned to.

On a domain machine, the answer to "why does this setting keep changing back" is in the gpresult output, and the fix lives in the GPO, which is a change on the domain controller side rather than on the workstation. On an Intune device, mdmdiagnosticstool -area DeviceEnrollment;DeviceProvisioning -cab C:\temp\mdm.cab produces the equivalent report.

One warning before any secedit work. The command that appears in every "reset local security policy" guide, secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose, rewrites every setting in the database to the install defaults, not just the one you broke. Export first, then reset, then re-import the pieces you want.

What LSASS Holds and Why Attackers Want It

Open Task Manager on any Windows machine and the row called Local Security Authority Process is lsass.exe. It validates every sign-in, local or remote, enforces the policies you set in the console above, and, as a side effect of doing that job, holds credential material in memory for every user who has signed in since the last boot. NTLM hashes, Kerberos tickets, and in older configurations plaintext passwords, all sit in that process.

MITRE catalogues the attack as OS Credential Dumping: LSASS Memory, technique T1003.001, last updated in May 2026. The procedure examples read like a tool list. HAFNIUM used procdump to dump the process. Sandworm and the Bad Rabbit ransomware used Mimikatz. The built-in version needs nothing downloaded at all: rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <pid> lsass.dmp full writes the memory to disk, and Mimikatz reads the dump offline later with sekurlsa::logonPasswords.

The requirement for every one of those is a process with administrative or SYSTEM rights opening a handle to lsass.exe. That is the step the next two features exist to stop, and they stop it in different places. LSA protection stops the handle. Credential Guard moves the secrets somewhere a handle cannot reach. The same stolen material also feeds the phishing and token-replay chains described in the credential harvesting explainer, which is why a single workstation dump so often ends as a domain-wide incident.

LSA Protection: Turning It On Without Breaking Sign-In

LSA protection runs lsass.exe as a Protected Process Light. Microsoft's LSA protection page, updated March 2025, describes the effect in one sentence: it prevents "nonprotected processes from reading memory and injecting code". Procdump gets access denied. The comsvcs trick gets access denied. An attacker then needs a signed kernel driver or a bring-your-own-vulnerable-driver chain to get past it, which is a much higher bar than running one command as admin.

The catch is the same rule applied to everything else. Any plug-in that loads into LSA has to carry a Microsoft signature, and Microsoft names the usual suspects: "smart card drivers, cryptographic plug-ins, and password filters". A smart card driver without WHQL certification, a password filter DLL from a third-party password tool, or an older VMware Tools LSA plug-in (Broadcom documents that versions before 10.3.5 fail to load) stops working the moment protection is on. The r/sysadmin thread below is the version a help desk sees: French healthcare smart cards, a driver that is not Microsoft-signed, and interactive sign-in that works only with LSA protection turned off.

There is no exception list. The only ways through are a signed driver from the vendor or protection off on those machines, which is why the order of operations below matters.

Step 1: Audit Mode

Windows 11 version 22H2 and later run LSA audit mode by default, so on current machines there is nothing to switch on. On older builds, set AuditLevel to 8 as a DWORD under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe and restart. Then read Applications and Services Logs, Microsoft, Windows, CodeIntegrity, Operational. Event 3066 names a plug-in that would fail the signing requirement; event 3065 names one with shared sections that would fail for that reason. Both say the image was allowed to load because of the current policy, which is the audit mode talking. A fleet with zero 3065 and 3066 events after a week of normal sign-ins is a fleet that can enforce.

Two things hide the events. Smart App Control, when it is on, suppresses audit logging for LSA, so turn it off on the test machines. And a kernel debugger attached to the system suppresses them too, which only matters in a lab.

Step 2: Enable, With or Without the UEFI Lock

The switch is one registry value, RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. A value of 2 enables protection and keeps the setting in the registry, where a later policy or a technician can turn it off again. A value of 1 enables it and also writes a UEFI variable, after which the registry no longer matters: on a Secure Boot machine, deleting the key does nothing, and the only way off is Microsoft's LSA Protected Process Opt-out tool run from the firmware, or turning Secure Boot off, which resets every Secure Boot setting with it.

The same two options appear everywhere else the setting is exposed. In the Local Group Policy Editor it is Computer Configuration, Administrative Templates, System, Local Security Authority, "Configures LSASS to run as a protected process", with Enabled with UEFI Lock and Enabled without UEFI Lock in the dropdown. In Intune the OMA-URI is ./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/ConfigureLsaProtectedProcess, integer 1 or 2. In the Windows Security app it is Device security, Core isolation details, Local Security Authority protection, and the toggle sets the no-lock value. Microsoft's baseline chooses the lock. For a managed fleet where the plug-in audit came back clean, so should you; for a fleet with one unsigned driver you are still chasing, the no-lock value buys the option of backing out.

Step 3: Verify

After the restart, the System log carries a WinInit event with ID 12 that reads "LSASS.exe was started as a protected process with level: 4". That line is the receipt. Once protection is enforced, the CodeIntegrity log switches from the audit events to 3033 and 3063, which are the same two conditions reported as blocks instead of allowed loads. A 3033 after enforcement is a plug-in you missed.

One false alarm is worth knowing. Through 2023 the Windows Security app showed "Local Security Authority protection is off. Your device may be vulnerable" on machines where it was on, and Microsoft's own guidance at the time was to confirm the registry value and restart. The event 12 line is the thing to trust, not the banner.

Defaults, So You Know What You Already Have

A new installation of Windows 11 22H2 or later that is Active Directory joined, Microsoft Entra joined or hybrid joined, on hardware capable of memory integrity, enables LSA protection on its own, without the UEFI lock. A machine upgraded from an earlier release does not. A workgroup machine does not. Microsoft also notes that setting the policy back to Not Configured after it was Enabled does not clear the setting; it has to be set to Disabled explicitly. Run the event 12 check across the fleet before you assume either way.

Credential Guard, the Other Half

LSA protection guards the door. Credential Guard moves the valuables out of the room. It uses virtualization-based security to run a second process, LSAIso.exe, inside a container the rest of Windows cannot read, and the NTLM hashes and Kerberos ticket-granting tickets live there. Microsoft's Credential Guard overview, updated April 2026, puts the payoff plainly: malware running with administrative privileges "can't extract secrets that are protected by VBS".

Two limits shape where it fits. It is an Enterprise and Education feature; Windows Pro does not license it, so a small office on Pro gets LSA protection and not this. And it is on by default on domain-joined devices running Windows 11 22H2 or later that meet the hardware bar, 64-bit with Secure Boot and VBS, so on an Enterprise fleet the question is usually whether it is already running rather than whether to turn it on. Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard lists the running services; a 1 in SecurityServicesRunning is Credential Guard.

What it does not cover is a common pentest surprise. The SAM database for local accounts and the Active Directory database on a domain controller sit outside it, and so do the LSA secrets stored in the registry's SECURITY hive. An attacker who already has SYSTEM on the box can still read those. The r/sysadmin thread below is a team working through exactly that finding, with the replies explaining why it is a consequence of admin access rather than a bug.

Compatibility is the other reason to read before enabling. Microsoft's list of what breaks is short and specific: Kerberos DES encryption, Kerberos unconstrained delegation, TGT extraction and NTLMv1 stop working outright, while Digest, CredSSP, MS-CHAPv2 and credential delegation keep working but expose the credential. An old Wi-Fi setup on MS-CHAPv2 against a RADIUS server is the one that shows up on small networks. Microsoft also says not to enable it on domain controllers, where it adds nothing and breaks things, and that Exchange Server is unsupported with it on.

Pushing It Across a Fleet

Setting any of this by hand on one machine is a test. Setting it on a fleet is a baseline job, and the baseline already exists. Microsoft's Security Compliance Toolkit ships the Group Policy backups for each Windows release plus two tools: LGPO, which applies a baseline to a stand-alone machine from the command line, and Policy Analyzer, which diffs a machine's effective settings against the baseline and against another machine. Microsoft's security baselines page points out why nobody should write their own: Windows 10 alone had more than 3,000 Group Policy settings, and the baseline is the subset a security engineering team already argued over.

The Intune version is a profile under Endpoint security, Security baselines, and the MDM comparison covers which other management tools can push the same settings.

The order that works is the one below. Each step is a gate, and the two that get skipped are the audit week and the restart receipt.

1. Export the current state from a sample of machines with secedit /export and auditpol /get, so you can see what the baseline is about to change.
2. Apply the baseline to a pilot group through a GPO or an Intune assignment, with LSA protection set to Enabled without UEFI lock for now.
3. Run the pilot for a week. Read the CodeIntegrity log for 3065 and 3066, the Security log for 4740 lockouts after the threshold drops to 10, and the help desk queue for sign-in tickets.
4. Fix what surfaced: a vendor driver update, a password filter replacement, an exception GPO for the two machines that run the old scanner software.
5. Switch LSA protection to the UEFI lock, add Credential Guard where the licence allows, and roll to everyone.
6. Collect the receipts: WinInit event 12 on every device, Credential Guard running where expected, and the secedit export matching the baseline.
7. Put the export on a monthly schedule and diff it. Settings drift when someone fixes a ticket at 5pm.

Step 6 is where a script earns its keep. One that reads the RunAsPPL value, pulls the last WinInit event 12, queries Win32_DeviceGuard and exports the security database, then writes one line per machine, turns "is it on everywhere" into a list of the machines where it is not. If you run OpenFrame, that is one script run across a client's devices with the output collected in one place. The same export is the evidence an auditor asks for, which is why it belongs in the security audit checklist rather than in a technician's notes.

Application control is the layer above all of this. LSA protection stops unsigned code reading LSASS; WDAC stops unsigned code running in the first place, and the two baselines are designed to ship together.

The ticket log every team has written at least once, in the order it happened:

The Short Version

secpol.msc is the local security half of Group Policy, it loses to any domain or Intune policy above it, and the dozen settings worth touching already have baseline values you can copy. LSA protection turns lsass.exe into a process that procdump and Mimikatz cannot open, at the cost of every unsigned smart card driver and password filter on the machine, so run the audit week before you throw the switch and keep the opt-out tool to hand if you choose the UEFI lock. Credential Guard moves the secrets out of reach entirely, on Enterprise and Education, and is probably already on.

Two reads follow on from here. The Group Policy Editor guide covers getting these settings into a GPO and testing them with gpupdate.

The WDAC guide covers the allowlisting layer that keeps the dumping tools from running at all.