# Audit LSA plug-in compatibility before enforcing protected-process mode > Added LSA protection blocks plug-ins and drivers that do not meet protected-process requirements; Microsoft provides audit events that should be reviewed before broad enforcement. - Canonical URL: https://update.dsesecurity.com/updates/windows-lsa-protection-audit-first/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:13+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Added LSA protection blocks plug-ins and drivers that do not meet protected-process requirements; Microsoft provides audit events that should be reviewed before broad enforcement. ## Potentially affected Windows and Windows Server systems with smart-card, cryptographic, password-filter, authentication, or other software that loads into LSA. ## DSE recommendation Inventory LSA extensions, collect audit events on representative systems, remediate incompatible components, and verify protected-process state after staged enforcement. ## Article Bottom line: Added Local Security Authority protection runs LSASS as a protected process to reduce memory reading and code injection by nonprotected processes. Microsoft warns that LSA plug-ins and drivers must satisfy signing and protected-process requirements. Audit compatibility first or an authentication dependency can fail at enforcement. ## Source fact: what Microsoft documents Microsoft’s [added LSA protection guide](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection) says protected mode requires qualifying signatures for plug-ins loaded into LSA. Examples include smart-card drivers, cryptographic plug-ins, and password filters. Microsoft recommends identifying all LSA plug-ins, ensuring that they meet requirements, testing their function, and using audit logs before broad deployment. The guide documents audit-mode Code Integrity events for components that would fail protected-process requirements and enforcement events for components that are blocked. It also explains configuration with and without a UEFI lock, Secure Boot dependencies, automatic enablement criteria for specified Windows 11 installations, restart requirements, verification, and the relationship between LSA protection and Credential Guard. A UEFI-locked configuration has a different removal process from an ordinary registry or policy setting. ## What the source does not establish The presence of a policy value does not prove LSASS is running in the intended protected mode. An empty audit log does not prove compatibility if audit collection is misconfigured or a component was not exercised. LSA protection does not replace Credential Guard, patching, privileged-access controls, or protection against an attacker already operating with sufficient kernel-level capability. It also does not make custom plug-ins supportable. ## Applicability questions - Which Windows editions, versions, installation histories, UEFI, Secure Boot, and HVCI states are present? - Which password filters, smart-card middleware, credential providers, cryptographic modules, or security agents interact with LSA? - Is audit mode active and are relevant Code Integrity logs centrally collected? - Does the organization require UEFI lock, and can it perform the documented recovery or removal process? - Which authentication and recovery functions must be tested after reboot? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory LSA extensions and the business functions that depend on them. Obtain vendor support statements for the deployed build. - Collect the documented audit events on representative hardware while exercising normal, smart-card, password-change, remote, and service authentication. - Remediate, update, replace, or formally except incompatible components before enforcement. - Deploy through rings with tested recovery media and administrator access. Decide explicitly whether UEFI lock is required. - After each ring, verify protected-process state and repeat critical authentication tests before expansion. ## Verification and evidence - Preserve device inventory, component versions, audit-event review, compatibility decisions, and change approval. - Capture relevant Code Integrity audit and enforcement events with device and timestamp context. - Verify configuration and runtime state using Microsoft’s documented methods after reboot. - Record successful smart-card, password, service, local, remote, and recovery authentication tests as applicable. ## Official references - [Configure added LSA protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection) — Microsoft ## Primary reference - Name: Configure added LSA protection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit LSA plug-in compatibility before enforcing protected-process mode,” DSE Security, https://update.dsesecurity.com/updates/windows-lsa-protection-audit-first/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.