Merge pull request #9148 from MicrosoftDocs/main

public main to live, 3:30 PM 11/22/2023

windows/security/application-security/application-control/windows-defender-application-control/design/plan-wdac-management.md

@@ -2,7 +2,7 @@
 title: Plan for WDAC policy management
 description: Learn about the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control policies.
 ms.localizationpriority: medium
-ms.date: 11/02/2022
+ms.date: 11/22/2023
 ms.topic: article
 ---
 
@@ -11,7 +11,7 @@ ms.topic: article
 >[!NOTE]
 >Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
 
-This topic describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies.
+This article describes the decisions you need to make to establish the processes for managing and maintaining Windows Defender Application Control (WDAC) policies.
 
 ## Policy XML lifecycle management
 
@@ -23,7 +23,7 @@ Most Windows Defender Application Control policies will evolve over time and pro
 2. [Deploy the audit mode policy](/windows/security/threat-protection/windows-defender-application-control/audit-windows-defender-application-control-policies) to intended devices.
 3. [Monitor audit block events](/windows/security/threat-protection/windows-defender-application-control/event-id-explanations) from the intended devices and add/edit/delete rules as needed to address unexpected/unwanted blocks.
 4. Repeat steps 2-3 until the remaining block events meet expectations.
-5. [Generate the enforced mode version](/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies) of the policy. In enforced mode, files that aren't allowed by the policy are prevented from executing and corresponding block events are generated.
+5. [Generate the enforced mode version](/windows/security/threat-protection/windows-defender-application-control/enforce-windows-defender-application-control-policies) of the policy. In enforced mode, files that the policy doesn't allow are prevented from running and corresponding block events are generated.
 6. [Deploy the enforced mode policy](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide) to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
 7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.  
 
@@ -35,7 +35,7 @@ To effectively manage Windows Defender Application Control policies, you should
 
 ### Set PolicyName, PolicyID, and Version metadata for each policy
 
-Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique ID in order to differentiate each policy when reviewing Windows Defender Application Control events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy.
+Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmdlet to give each policy a descriptive name and set a unique policy ID. These unique attributes help you differentiate each policy when reviewing Windows Defender Application Control events or when viewing the policy XML document. Although you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the -ResetPolicyId switch to let the system autogenerate a unique ID for the policy.
 
 > [!NOTE]
 > PolicyID only applies to policies using the [multiple policy format](deploy-multiple-wdac-policies.md) on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10.
@@ -45,15 +45,15 @@ In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/con
 
 ### Policy rule updates
 
-As new apps are deployed or existing apps are updated by the software publisher, you may need to make revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
+You might need to revise your policy when new apps are deployed or existing apps are updated by the software publisher to ensure that apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
 
 ## WDAC event management
 
-Each time that a process is blocked by Windows Defender Application Control, events will be written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event details which file tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
+Each time that WDAC blocks a process, events are written to either the CodeIntegrity\Operational or the AppLocker\MSI and Script Windows event logs. The event describes the file that tried to run, the attributes of that file and its signatures, and the process that attempted to run the blocked file.
 
-Collecting these events in a central location can help you maintain your Windows Defender Application Control policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc748890(v=ws.11)).
+Collecting these events in a central location can help you maintain your Windows Defender Application Control policy and troubleshoot rule configuration problems. You can [use the Azure Monitor Agent](/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent) to automatically collect your WDAC events for analysis.
 
-Additionally, Windows Defender Application Control events are collected by [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint) and can be queried using the [advanced hunting](../operations/querying-application-control-events-centrally-using-advanced-hunting.md) feature.
+Additionally, [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint) collects WDAC events which can be queried using the [advanced hunting](../operations/querying-application-control-events-centrally-using-advanced-hunting.md) feature.
 
 ## Application and user support policy
 
@@ -75,9 +75,9 @@ If your organization has an established help desk support department in place, c
 
 ### End-user support
 
-Because Windows Defender Application Control is preventing unapproved apps from running, it's important that your organization carefully plan how to provide end-user support. Considerations include:
+Because Windows Defender Application Control is preventing unapproved apps from running, it's important that your organization carefully plans how to provide end-user support. Considerations include:
 
-- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
+- Do you want to use an intranet site as a frontline of support for users who try to run a blocked app?
 - How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
 
 ## Document your plan

windows/security/application-security/application-control/windows-defender-application-control/design/select-types-of-rules-to-create.md

@@ -2,7 +2,7 @@
 title: Understand Windows Defender Application Control (WDAC) policy rules and file rules
 description: Learn how WDAC policy rules and file rules can control your Windows 10 and Windows 11 computers.
 ms.localizationpriority: medium
-ms.date: 08/11/2023
+ms.date: 11/22/2023
 ms.topic: article
 ---
 
@@ -11,7 +11,7 @@ ms.topic: article
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [WDAC feature availability](../feature-availability.md).
 
-Windows Defender Application Control (WDAC) can control what runs on Windows 10, Windows 11, and Windows Server 2016 and later, by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
+Windows Defender Application Control (WDAC) can control what runs on your Windows devices by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how to identify applications your organization trusts.
 
 ## Windows Defender Application Control policy rules
 
@@ -20,7 +20,9 @@ To modify the policy rule options of an existing WDAC policy XML, use the [WDAC
 You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether supplemental policies can set them. Some rule options are reserved for future work or not supported.
 
 > [!NOTE]
-> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked-instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode.
+> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, applications run normally but WDAC logs events whenever a file runs that isn't allowed by the policy. To allow these files, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode.
+>
+> Some apps may behave differently even when your policy is in audit mode. When an option may change behaviors in audit mode, that is noted in Table 1. You should always test your apps thoroughly when deploying significant updates to your WDAC policies.
 
 ### Table 1. Windows Defender Application Control policy - policy rule options
 
@@ -37,7 +39,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
 | **8 Required:EV Signers** | This option isn't currently supported. | No |
 | **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. | No |
 | **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a boot-critical driver fails during startup, the WDAC policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. | No |
-| **11 Disabled:Script Enforcement** | This option disables script enforcement options, covering PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), HTA files run in Microsoft HTML Application Host (mshta.exe), and MSXML. For more information on script enforcement, see [Script enforcement with WDAC](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement). <br/> NOTE: This option isn't supported on Windows Server 2016 or Windows 10 1607 LTSB and shouldn't be used on those operating systems. | No |
+| **11 Disabled:Script Enforcement** | This option disables script enforcement options, covering PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), HTA files run in Microsoft HTML Application Host (mshta.exe), and MSXML. Some script hosts may behave differently even when your policy is in audit mode. For more information on script enforcement, see [Script enforcement with WDAC](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement). <br/> NOTE: This option isn't supported on Windows Server 2016 or Windows 10 1607 LTSB and shouldn't be used on those operating systems. | No |
 | **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies also apply to Universal Windows applications. | No |
 | **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) | Yes |
 | **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft's Intelligent Security Graph (ISG). | Yes |
@@ -45,7 +47,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
 | **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot.<br/> NOTE: This option is only supported on Windows 10, version 1709 and later, or Windows Server 2019 and later.| No |
 | **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it.<br/> NOTE: This option is only supported on Windows 10, version 1903 and later, or Windows Server 2022 and later. | No |
 | **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator.<br/> NOTE: This option is only supported on Windows 10, version 1903 and later, or Windows Server 2022 and later. | Yes |
-| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries.<br/> NOTE: This option is only supported on Windows 10, version 1803 and later, or Windows Server 2019 and later. | No |
+| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries.<br/> NOTE: This option is only supported on Windows 10, version 1803 and later, or Windows Server 2019 and later.<br/> NOTE: This option is always enforced if *any* WDAC UMCI policy enables it. There's no audit mode for .NET dynamic code security hardening. | No |
 | **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with revoked certificates, or expired certificates with the Lifetime Signing EKU on the signature, as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No |
 | **Enabled:Developer Mode Dynamic Code Trust** | Use this option to trust UWP apps that are [debugged in Visual Studio](/visualstudio/debugger/run-windows-store-apps-on-a-remote-machine) or deployed through device portal when Developer Mode is enabled on the system. | No |
 
@@ -71,7 +73,7 @@ Each file rule level has advantages and disadvantages. Use Table 2 to select the
 | **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have shorter validity periods than other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
 | **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root because the scan doesn't resolve the complete certificate chain via the local root stores or with an online check. |
 | **RootCertificate** | Not supported. |
-| **WHQL** | Only trusts binaries that have been submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level is primarily for kernel binaries. |
+| **WHQL** | Only trusts binaries that were submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level is primarily for kernel binaries. |
 | **WHQLPublisher** | This level combines the WHQL level and the CN on the leaf certificate, and is primarily for kernel binaries. |
 | **WHQLFilePublisher** | This level combines the "FileName" attribute of the signed file, plus "WHQLPublisher", plus a minimum version number. This level is primarily for kernel binaries. By default, this level uses the OriginalFileName attribute of the file's resource header. Use [-SpecificFileNameLevel](#use--specificfilenamelevel-with-filename-filepublisher-or-whqlfilepublisher-level-rules) to choose an alternative attribute, such as ProductName. |
 
@@ -96,7 +98,7 @@ For example, consider an IT professional in a department that runs many servers.
 
 To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. With the help of the audit data, they update their WDAC policies to include any other software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
 
-As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they won't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
+As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they don't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
 
 ## File rule precedence order
 
@@ -107,7 +109,7 @@ WDAC has a built-in file rule conflict logic that translates to precedence order
 
 ## Use -SpecificFileNameLevel with FileName, FilePublisher, or WHQLFilePublisher level rules
 
-By default, the FileName, FilePublisher, and WHQLFilePublisher rule levels will use the OriginalFileName attribute from the file's resource header. You can use an alternative resource header attribute for your rules by setting the **-SpecificFileNameLevel**. For instance, a software developer may use the same ProductName for all binaries that are part of an app. Using -SpecificFileNameLevel, you can create a single rule to cover all of those binaries in your policy rather than individual rules for every file.
+By default, the FileName, FilePublisher, and WHQLFilePublisher rule levels use the OriginalFileName attribute from the file's resource header. You can use an alternative resource header attribute for your rules by setting the **-SpecificFileNameLevel**. For instance, a software developer might use the same ProductName for all binaries that are part of an app. Using -SpecificFileNameLevel, you can create a single rule to cover all of those binaries in your policy rather than individual rules for every file.
 
 Table 3 describes the available resource header attribute options you can set with -SpecificFileNameLevel.
 
@@ -124,7 +126,7 @@ Table 3 describes the available resource header attribute options you can set wi
 
 ## More information about filepath rules
 
-Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect to remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
+Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect to remain admin-writeable only. You might want to avoid path rules for directories where standard users can modify ACLs on the folder.
 
 ### User-writable filepaths
 
@@ -182,8 +184,8 @@ In the cmdlets, rather than try to predict which hash will be used, we precalcul
 
 ### Why does scan create eight hash rules for certain files?
 
-Separate rules are created for UMCI and KMCI. If the cmdlets can't determine that a file will only run in user-mode or in the kernel, then rules are created for both signing scenarios out of an abundance of caution. If you know that a particular file will only load in either user-mode or kernel, then you can safely remove the extra rules.
+Separate rules are created for UMCI and KMCI. If the cmdlets can't determine that a file only runs in user-mode or in the kernel, then rules are created for both signing scenarios out of an abundance of caution. If you know that a particular file only loads in either user-mode or kernel, then you can safely remove the extra rules.
 
 ### When does WDAC use the flat file hash value?
 
-There are some rare cases where a file's format doesn't conform to the Authenticode spec and so WDAC falls back to use the flat file hash. This can occur for a number of reasons, such as if changes are made to the in-memory version of the file at runtime. In such cases, you'll see that the hash shown in the correlated 3089 signature information event matches the flat file hash from the 3076/3077 block event. To create rules for files with an invalid format, you can add hash rules to the policy for the flat file hash using the WDAC Wizard or by editing the policy XML directly.
+There are some rare cases where a file's format doesn't conform to the Authenticode spec and so WDAC falls back to use the flat file hash. This behavior can occur for many reasons, such as if changes are made to the in-memory version of the file at runtime. In such cases, you'll see that the hash shown in the correlated 3089 signature information event matches the flat file hash from the 3076/3077 block event. To create rules for files with an invalid format, you can add hash rules to the policy for the flat file hash using the WDAC Wizard or by editing the policy XML directly.

windows/security/application-security/application-control/windows-defender-application-control/design/wdac-and-dotnet.md

@@ -2,7 +2,7 @@
 title: Windows Defender Application Control and .NET
 description: Understand how WDAC and .NET work together and use Dynamic Code Security to verify code loaded by .NET at runtime.
 ms.localizationpriority: medium
-ms.date: 08/10/2022
+ms.date: 11/22/2023
 ms.topic: article
 ---
 
@@ -10,9 +10,9 @@ ms.topic: article
 
 .NET apps (as written in a high-level language like C#) are compiled to an Intermediate Language (IL). IL is a compact code format that can be supported on any operating system or architecture. Most .NET apps use APIs that are supported in multiple environments, requiring only the .NET runtime to run. IL needs to be compiled to native code in order to execute on a CPU, for example Arm64 or x64. When .NET compiles IL to native image (NI) on a device with a WDAC user mode policy, it first checks whether the original IL file passes the current WDAC policies. If so, .NET sets an NTFS extended attribute (EA) on the generated NI file so that WDAC knows to trust it as well. When the .NET app runs, WDAC sees the EA on the NI file and allows it.
 
-The EA set on the NI file only applies to the currently active WDAC policies. If one of the active WDAC policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, WDAC will block the NI file. .NET handles the block gracefully and will fall back to the original IL code. If the IL still passes the latest WDAC policies, then the app runs without any functional impact. Since the IL is now being compiled at runtime, you may notice a slight impact to performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the WDAC EA for all code that passes the latest WDAC policies.
+The EA set on the NI file only applies to the currently active WDAC policies. If one of the active WDAC policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, WDAC will block the NI file. .NET handles the block gracefully and falls back to the original IL code. If the IL still passes the latest WDAC policies, then the app runs without any functional impact. Since the IL is now being compiled at runtime, you might notice a slight impact to performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the WDAC EA for all code that passes the latest WDAC policies.
 
-In some cases, if an NI file is blocked, you may see a "false positive" block event in the *CodeIntegrity - Operational* event log as described in [WDAC Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues#net-native-images-may-generate-false-positive-block-events).
+In some cases, if an NI file is blocked, you might see a "false positive" block event in the *CodeIntegrity - Operational* event log as described in [WDAC Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues#net-native-images-may-generate-false-positive-block-events).
 
 To mitigate any performance impact caused when the WDAC EA isn't valid or missing:
 
@@ -22,14 +22,17 @@ To mitigate any performance impact caused when the WDAC EA isn't valid or missin
 
 ## WDAC and .NET hardening
 
-Security researchers have found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent WDAC controls.
-Beginning with Windows 10, version 1803, WDAC includes a new option, called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
+Security researchers found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent WDAC controls.
+To address this potential vulnerability, WDAC includes an option called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
 
-When the Dynamic Code Security option is enabled, Application Control policy is applied to libraries that .NET loads from external sources. For example, any non-local sources, such as the internet or a network share.
+When the Dynamic Code Security option is enabled, Application Control policy is applied to libraries that .NET loads from external sources. For example, any remote sources, such as the internet or a network share.
 
-Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with.
+> [!IMPORTANT]
+> .Net dynamic code security hardening is *turned on and enforced* if any WDAC policy with UMCI enabled has set option **19 Enabled:Dynamic Code Security**. There is no audit mode for this feature. You should test your apps with this option set before turning it on across large numbers of devices.
 
-Dynamic Code Security isn't enabled by default because existing policies may not account for externally loaded libraries.
+Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that was tampered with.
+
+Dynamic Code Security isn't enabled by default because existing policies might not account for externally loaded libraries.
 Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled.
 Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy.
 

windows/security/application-security/application-control/windows-defender-application-control/operations/known-issues.md

@@ -2,7 +2,7 @@
 title: WDAC Admin Tips & Known Issues
 description: WDAC Known Issues
 ms.manager: jsuther
-ms.date: 05/09/2023
+ms.date: 11/22/2023
 ms.topic: article
 ms.localizationpriority: medium
 ---
@@ -23,7 +23,7 @@ This article covers tips and tricks for admins and known issues with Windows Def
 
 The *\{PolicyId GUID\}* value is unique by policy and defined in the policy XML with the <PolicyId> element.
 
-For **single policy format WDAC policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b that may be found in the following locations:
+For **single policy format WDAC policies**, in addition to the two preceding locations, also look for a file called SiPolicy.p7b in the following locations:
 
 - <EFI System Partition>\\Microsoft\\Boot\\SiPolicy.p7b
 - <OS Volume>\\Windows\\System32\\CodeIntegrity\\SiPolicy.p7b
@@ -35,7 +35,7 @@ For **single policy format WDAC policies**, in addition to the two preceding loc
 
 When the WDAC engine evaluates files against the active set of policies on the device, rules are applied in the following order. Once a file encounters a match, WDAC stops further processing.
 
-1. Explicit deny rules - if any explicit deny rule exists for the file, it's blocked even if other rules are created to try to allow it. Deny rules can use any [rule level](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
+1. Explicit deny rules - a file is blocked if any explicit deny rule exists for it, even if other rules are created to try to allow it. Deny rules can use any [rule level](/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend.
 
 2. Explicit allow rules - if any explicit allow rule exists for the file, the file runs.
 
@@ -43,17 +43,24 @@ When the WDAC engine evaluates files against the active set of policies on the d
 
 4. Lastly, WDAC makes a cloud call to the ISG to get reputation about the file, if the policy enables the ISG option.
 
-5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
+5. If no explicit rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly.
 
 ## Known issues
 
 ### Boot stop failure (blue screen) occurs if more than 32 policies are active
 
-If the maximum number of policies is exceeded, the device may bluescreen referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your WDAC policies. Any [Windows inbox policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) that are active on the device also count towards this limit.
+If the maximum number of policies is exceeded, the device will bluescreen referencing ci.dll with a bug check value of 0x0000003b. Consider this maximum policy count limit when planning your WDAC policies. Any [Windows inbox policies](/windows/security/threat-protection/windows-defender-application-control/operations/inbox-wdac-policies) that are active on the device also count towards this limit.
+
+### Audit mode policies can change the behavior for some apps or cause app crashes
+
+Although WDAC audit mode is designed to avoid impact to apps, some features are always on/always enforced with any WDAC policy that includes the option **0 Enabled:UMCI**. Here's a list of known system changes in audit mode:
+
+- Some script hosts might block code or run code with fewer privileges even in audit mode. See [Script enforcement with WDAC](/windows/security/application-security/application-control/windows-defender-application-control/design/script-enforcement) for information about individual script host behaviors.
+- Option **19 Enabled:Dynamic Code Security** is always enforced if any UMCI policy includes that option. See [WDAC and .NET](/windows/security/application-security/application-control/windows-defender-application-control/design/wdac-and-dotnet#wdac-and-net-hardening).
 
 ### Managed Installer and ISG may cause excessive events
 
-When Managed Installer and ISG are enabled, 3091 and 3092 events are logged when a file didn't have Managed Installer or ISG authorization, regardless of whether the file was allowed. These events have been moved to the verbose channel beginning with the September 2022 Update Preview since the events don't indicate an issue with the policy.
+When Managed Installer and ISG are enabled, 3091 and 3092 events are logged when a file didn't have Managed Installer or ISG authorization, regardless of whether the file was allowed. These events were moved to the verbose channel beginning with the September 2022 Update Preview since the events don't indicate an issue with the policy.
 
 ### .NET native images may generate false positive block events
 
@@ -83,13 +90,13 @@ msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi
 ```
 ### Slow boot and performance with custom policies
 
-WDAC will evaluate all running processes, including inbox Windows processes. If policies don't build off the WDAC templates or don't trust the Windows signers, you'll see slower boot times, degraded performance and possibly boot issues. For these reasons, it's strongly recommended to build off the [WDAC base templates](../design/example-wdac-base-policies.md). 
+WDAC evaluates all processes that run, including inbox Windows processes. If policies don't build off the WDAC templates or don't trust the Windows signers, you'll see slower boot times, degraded performance and possibly boot issues. For these reasons, you should use the [WDAC base templates](../design/example-wdac-base-policies.md) whenever possible to create your policies.
 
 #### AppId Tagging policy considerations
 
 If the AppId Tagging Policy wasn't built off the WDAC base templates or doesn't allow the Windows in-box signers, you'll notice a significant increase in boot times (~2 minutes). 
 
-If you can't allowlist the Windows signers, or build off the WDAC base templates, it is strongly recommended to add the following rule to your policies to improve the performance:
+If you can't allowlist the Windows signers, or build off the WDAC base templates, it's recommended to add the following rule to your policies to improve the performance:
 
 :::image type="content" source="../images/known-issue-appid-dll-rule.png" alt-text="Allow all dlls in the policy.":::