This commit is contained in:
MokumaPM 2024-10-08 23:20:16 -07:00 committed by GitHub
parent 0a5156fa48
commit 33b3a7cd9b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -13,9 +13,9 @@ In addition to adopting passwordless sign-in, organizations can strengthen secur
## Local Security Authority (LSA) protection
Windows has several critical processes to verify a user's identity. Verification processes include Local Security Authority (LSA), which is responsible for authenticating users and verifying Windows sign-ins. LSA handles tokens and credentials that are used for single sign-on to a Microsoft account and Azure services.
Windows has several critical processes to verify a user's identity. Verification processes include Local Security Authority (LSA), which is responsible for authenticating users and verifying Windows sign-ins. LSA handles tokens and credentials that are used for single sign-on to a Microsoft account and Entra.
To help keep these credentials safe, more LSA protection is enabled by default on new, enterprise-joined Windows 11 devices. By loading only trusted, signed code, LSA provides significant protection against credential theft. LSA protection also now supports configuration using Group Policy and cloud management solutions.
To help keep these credentials safe, With 24H2, LSA protection is enabled by default on all devices (MSA, Entra joined, hybrid, and local) after an evaluation period. By loading only trusted, signed code, LSA provides significant protection against credential theft. LSA protection also now supports configuration using Group Policy and cloud management solutions.
End users have the ability to manage their LSA protection state in the Windows Security Application under Device Security -> Core Isolation -> Local Security Authority protection. It's important to note that the enterprise policy for LSA protection will take precedence over enablement on upgrade. This ensures a seamless transition and enhanced security for all users.