{
	"id": "9162b33c-3660-4edf-8429-367c212eea6f",
	"created_at": "2026-04-06T00:12:55.055078Z",
	"updated_at": "2026-04-10T03:21:26.700451Z",
	"deleted_at": null,
	"sha1_hash": "6fc92d692cad18093e0d912294cacb9ebc558326",
	"title": "Configuring Additional LSA Protection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 59069,
	"plain_text": "Configuring Additional LSA Protection\r\nBy Archiveddocs\r\nArchived: 2026-04-05 16:24:51 UTC\r\nApplies To: Windows 8.1, Windows Server 2012 R2\r\nThis topic for the IT professional explains how to configure additional protection for the Local Security Authority\r\n(LSA) process to prevent code injection that could compromise credentials.\r\nThe LSA, which includes the Local Security Authority Server Service (LSASS) process, validates users for local\r\nand remote sign-ins and enforces local security policies. The Windows 8.1 operating system provides additional\r\nprotection for the LSA to prevent reading memory and code injection by non-protected processes. This provides\r\nadded security for the credentials that the LSA stores and manages. The protected process setting for LSA can be\r\nconfigured in Windows 8.1, but it cannot be configured in Windows RT 8.1. When this setting is used in\r\nconjunction with Secure Boot, additional protection is achieved because disabling the\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa registry key has no effect.\r\nProtected process requirements for plug-ins or drivers\r\nFor an LSA plug-in or driver to successfully load as a protected process, it must meet the following criteria:\r\n1. Signature verification\r\nProtected mode requires that any plug-in that is loaded into the LSA is digitally signed with a Microsoft\r\nsignature. Therefore, any plug-ins that are unsigned or are not signed with a Microsoft signature will fail to\r\nload in LSA. Examples of these plug-ins are smart card drivers, cryptographic plug-ins, and password\r\nfilters.\r\nLSA plug-ins that are drivers, such as smart card drivers, need to be signed by using the WHQL\r\nCertification. For more information, see WHQL Release Signature (Windows Drivers).\r\nLSA plug-ins that do not have a WHQL Certification process, must be signed by using the file signing\r\nservice for LSA.\r\n2. Adherence to the Microsoft Security Development Lifecycle (SDL) process guidance\r\nAll of the plug-ins must conform to the applicable SDL process guidance. For more information, see the\r\nMicrosoft Security Development Lifecycle (SDL) Appendix.\r\nEven if the plug-ins are properly signed with a Microsoft signature, non-compliance with the SDL process\r\ncan result in failure to load a plug-in.\r\nRecommended practices\r\nhttps://technet.microsoft.com/en-us/library/dn408187.aspx\r\nPage 1 of 6\n\nUse the following list to thoroughly test that LSA protection is enabled before you broadly deploy the feature:\r\nIdentify all of the LSA plug-ins and drivers that are in use within your organization. This includes non-Microsoft drivers or plug-ins such as smart card drivers and cryptographic plug-ins, and any internally\r\ndeveloped software that is used to enforce password filters or password change notifications.\r\nEnsure that all of the LSA plug-ins are digitally signed with a Microsoft certificate so that the plug-in will\r\nnot fail to load.\r\nEnsure that all of the correctly signed plug-ins can successfully load into LSA and that they perform as\r\nexpected.\r\nUse the audit logs to identify LSA plug-ins and drivers that fail to run as a protected process.\r\nHow to identify LSA plug-ins and drivers that fail to run as a protected process\r\nThe events described in this section are located in the Operational log under Applications and Services\r\nLogs\\Microsoft\\Windows\\CodeIntegrity. They can help you identify LSA plug-ins and drivers that are failing to\r\nload due to signing reasons. To manage these events, you can use the wevtutil command-line tool. For\r\ninformation about this tool, see Wevtutil [Vista].\r\nBefore opting in: How to identify plug-ins and drivers loaded by the lsass.exe\r\nYou can use the audit mode to identify LSA plug-ins and drivers that will fail to load in LSA Protection mode.\r\nWhile in the audit mode, the system will generate event logs, identifying all of the plug-ins and drivers that will\r\nfail to load under LSA if LSA Protection is enabled. The messages are logged without blocking the plug-ins or\r\ndrivers.\r\nTo enable the audit mode for Lsass.exe on a single computer by editing the Registry\r\n1. Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at:\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution\r\nOptions\\LSASS.exe.\r\n2. Set the value of the registry key to AuditLevel=dword:00000008.\r\n3. Restart the computer.\r\nAnalyze the results of event 3065 and event 3066.\r\nEvent 3065: This event records that a code integrity check determined that a process (usually lsass.exe)\r\nattempted to load a particular driver that did not meet the security requirements for Shared Sections.\r\nHowever, due to the system policy that is set, the image was allowed to load.\r\nEvent 3066: This event records that a code integrity check determined that a process (usually lsass.exe)\r\nattempted to load a particular driver that did not meet the Microsoft signing level requirements. However,\r\ndue to the system policy that is set, the image was allowed to load.\r\nhttps://technet.microsoft.com/en-us/library/dn408187.aspx\r\nPage 2 of 6\n\nImportant\r\nThese operational events are not generated when a kernel debugger is attached and enabled on a system. If a plug-in or driver contains Shared Sections, Event 3066 is logged with Event 3065. Removing the Shared Sections\r\nshould prevent both the events from occurring unless the plug-in does not meet the Microsoft signing level\r\nrequirements.\r\nTo enable audit mode for multiple computers in a domain, you can use the Registry Client-Side Extension for\r\nGroup Policy to deploy the Lsass.exe audit-level registry value. You need to modify\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution\r\nOptions\\LSASS.exe registry key.\r\nTo create the AuditLevel value setting in a GPO\r\n1. Open the Group Policy Management Console (GPMC).\r\n2. Create a new Group Policy Object (GPO) that is linked at the domain level or that is linked to the\r\norganizational unit that contains your computer accounts. Or you can select a GPO that is already\r\ndeployed.\r\n3. Right-click the GPO, and then click Edit to open the Group Policy Management Editor.\r\n4. Expand Computer Configuration, expand Preferences, and then expand Windows Settings.\r\n5. Right-click Registry, point to New, and then click Registry Item. The New Registry Properties dialog\r\nbox appears.\r\n6. In the Hive list, click HKEY_LOCAL_MACHINE.\r\n7. In the Key Path list, browse to SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File\r\nExecution Options\\LSASS.exe.\r\n8. In the Value name box, type AuditLevel.\r\n9. In the Value type box, click to select the REG_DWORD.\r\n10. In the Value data box, type 00000008.\r\n11. Click OK.\r\nNote\r\nFor the GPO take effect, the GPO change must be replicated to all domain controllers in the domain.\r\nTo opt-in for additional LSA protection on multiple computers, you can use the Registry Client-Side Extension for\r\nGroup Policy by modifying HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa. For steps\r\nabout how to do this, see How to configure additional LSA protection of credentials in this topic.\r\nhttps://technet.microsoft.com/en-us/library/dn408187.aspx\r\nPage 3 of 6\n\nAfter opting in: How to identify plug-ins and drivers loaded by the lsass.exe\r\nYou can use the event log to identify LSA plug-ins and drivers that failed to load in LSA Protection mode. When\r\nthe LSA protected process is enabled, the system generates event logs that identify all of the plug-ins and drivers\r\nthat failed to load under LSA.\r\nAnalyze the results of Event 3033 and Event 3063.\r\nEvent 3033: This event records that a code integrity check determined that a process (usually lsass.exe)\r\nattempted to load a driver that did not meet the Microsoft signing level requirements.\r\nEvent 3063: This event records that a code integrity check determined that a process (usually lsass.exe)\r\nattempted to load a driver that did not meet the security requirements for Shared Sections.\r\nShared Sections are typically the result of programming techniques that allow instance data to interact with other\r\nprocesses that use the same security context. This can create security vulnerabilities.\r\nHow to configure additional LSA protection of credentials\r\nOn devices running Windows 8.1 (with or without Secure Boot or UEFI), configuration is possible by performing\r\nthe procedures described in this section. For devices running Windows RT 8.1, lsass.exe protection is always\r\nenabled, and it cannot be turned off.\r\nFor information about changes in Secure Boot in Windows 8 and Windows 8.1, see Secure Boot.\r\nFor information about UEFI in Windows 8 and Windows 8.1, see What's Changed in Security Technologies\r\nin Windows 8.1 [Win 8.1].\r\nOn x86-based or x64-based devices using Secure Boot and UEFI or not\r\nOn x86-based or x64-based devices that use Secure Boot and UEFI, a UEFI variable is set in the UEFI firmware\r\nwhen LSA protection is enabled by using the registry key. When the setting is stored in the firmware, the UEFI\r\nvariable cannot be deleted or changed in the registry key. The UEFI variable must be reset.\r\nx86-based or x64-based devices that do not support UEFI or Secure Boot are disabled, cannot store the\r\nconfiguration for LSA protection in the firmware, and rely solely on the presence of the registry key. In this\r\nscenario, it is possible to disable LSA protection by using remote access to the device.\r\nYou can use the following procedures to enable or disable LSA protection:\r\nTo enable LSA protection on a single computer\r\n1. Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at:\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa.\r\n2. Set the value of the registry key to: \"RunAsPPL\"=dword:00000001.\r\nhttps://technet.microsoft.com/en-us/library/dn408187.aspx\r\nPage 4 of 6\n\n3. Restart the computer.\r\nTo enable LSA protection using Group Policy\r\n1. Open the Group Policy Management Console (GPMC).\r\n2. Create a new GPO that is linked at the domain level or that is linked to the organizational unit that contains\r\nyour computer accounts. Or you can select a GPO that is already deployed.\r\n3. Right-click the GPO, and then click Edit to open the Group Policy Management Editor.\r\n4. Expand Computer Configuration, expand Preferences, and then expand Windows Settings.\r\n5. Right-click Registry, point to New, and then click Registry Item. The New Registry Properties dialog\r\nbox appears.\r\n6. In the Hive list, click HKEY_LOCAL_MACHINE.\r\n7. In the Key Path list, browse to SYSTEM\\CurrentControlSet\\Control\\Lsa.\r\n8. In the Value name box, type RunAsPPL.\r\n9. In the Value type box, click the REG_DWORD.\r\n10. In the Value data box, type 00000001.\r\n11. Click OK.\r\nTo disable LSA protection\r\n1. Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at:\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa.\r\n2. Delete the following value from the registry key: \"RunAsPPL\"=dword:00000001.\r\n3. Use the Local Security Authority (LSA) Protected Process Opt-out tool to delete the UEFI variable if the\r\ndevice is using Secure Boot.\r\nFor more information about the opt-out tool, see Download Local Security Authority (LSA) Protected\r\nProcess Opt-out from Official Microsoft Download Center.\r\nFor more information about managing Secure Boot, see UEFI Firmware.\r\nWarning\r\nWhen Secure Boot is turned off, all the Secure Boot and UEFI-related configurations are reset. You should\r\nturn off Secure Boot only when all other means to disable LSA protection have failed.\r\nVerifying LSA protection\r\nhttps://technet.microsoft.com/en-us/library/dn408187.aspx\r\nPage 5 of 6\n\nTo discover if LSA was started in protected mode when Windows started, search for the following WinInit event\r\nin the System log under Windows Logs:\r\n12: LSASS.exe was started as a protected process with level: 4\r\nAdditional resources\r\nCredentials Protection and Management\r\nFile signing service for LSA\r\nSource: https://technet.microsoft.com/en-us/library/dn408187.aspx\r\nhttps://technet.microsoft.com/en-us/library/dn408187.aspx\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://technet.microsoft.com/en-us/library/dn408187.aspx"
	],
	"report_names": [
		"dn408187.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775434375,
	"ts_updated_at": 1775791286,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6fc92d692cad18093e0d912294cacb9ebc558326.pdf",
		"text": "https://archive.orkl.eu/6fc92d692cad18093e0d912294cacb9ebc558326.txt",
		"img": "https://archive.orkl.eu/6fc92d692cad18093e0d912294cacb9ebc558326.jpg"
	}
}