Audit LSA plug-in compatibility before enforcing protected-process mode

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 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.

1. Inventory LSA extensions and the business functions that depend on them. Obtain vendor support statements for the deployed build.
2. Collect the documented audit events on representative hardware while exercising normal, smart-card, password-change, remote, and service authentication.
3. Remediate, update, replace, or formally except incompatible components before enforcement.
4. Deploy through rings with tested recovery media and administrator access. Decide explicitly whether UEFI lock is required.
5. 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 — Microsoft