Freshness update - part 3 (#12568)

* Freshness update - part 3

* Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Author: sdwheeler

reference/docs-conceptual/security/app-control/application-control.md

@@ -1,6 +1,6 @@
 ---
 description: This article explains the features of Application Control that can be used to secure your PowerShell environment.
-ms.date: 09/25/2025
+ms.date: 12/09/2025
 title: Use App Control to secure PowerShell
 ---
 # Use App Control to secure PowerShell
@@ -19,9 +19,9 @@ Control (WDAC), allows you to control which drivers and applications are allowed
 ## Lockdown policy detection
 
 PowerShell detects both AppLocker and App Control for Business system wide policies. AppLocker
-doesn't have way to query the policy enforcement status. To detect if a system wide application
-control policy is being enforced by AppLocker, PowerShell creates two temporary files and tests if
-they can be executed. The filenames use the following name format:
+doesn't have way to query the policy enforcement status. To detect that AppLocker is enforcing a
+policy, PowerShell creates two temporary files and tries to run them. The filenames use the
+following name format:
 
 - `$Env:TEMP/__PSScriptPolicyTest_<random-8dot3-name>.ps1`
 - `$Env:TEMP/__PSScriptPolicyTest_<random-8dot3-name>.psm1`
@@ -35,8 +35,7 @@ security feature under the servicing criteria defined by the Microsoft Security
 > [!NOTE]
 > When [choosing between App Control or AppLocker][03], we recommend that you implement application
 > control using App Control for Business rather than AppLocker. Microsoft is no longer investing in
-> AppLocker. Although AppLocker may continue to receive security fixes, it won't receive feature
-> enhancements.
+> AppLocker. AppLocker will only receive security fixes.
 
 ## App Control policy enforcement
 
@@ -59,7 +58,7 @@ policy were in **Enforce** mode.
 Windows PowerShell 5.1 was the first version of PowerShell to support App Control. The security
 features of App Control and AppLocker improve with each new release of PowerShell. The following
 sections describe how this support changed in each version of PowerShell. The changes are
-cumulative, so the features described in the later versions include those from earlier versions.
+cumulative, so the features described in the later versions include changes from earlier versions.
 
 ### Changes in PowerShell 7.4
 

reference/docs-conceptual/security/app-control/how-app-control-works.md

@@ -1,6 +1,6 @@
 ---
 description: This article explains how App Control for Business works to secure PowerShell and the restrictions it imposes.
-ms.date: 09/19/2024
+ms.date: 12/09/2025
 title: How App Control for Business works with PowerShell
 ---
 # How App Control works with PowerShell
@@ -25,11 +25,11 @@ All versions of PowerShell (v5.1 - v7.x) support this App Control policy detecti
 
 ### Latest App Control policy enforcement detection
 
-App Control introduced new APIs in recent versions of Windows. Beginning with version 7.3, PowerShell uses
-the new `WldpCanExecuteFile` API to decide how a file should be handled. Windows PowerShell 5.1
-doesn't support this new API. The new API takes precedence over the legacy API for individual files.
-However, PowerShell continues to use the legacy API to get the system wide policy configuration. If
-the new API isn't available, PowerShell falls back to the old API behavior.
+App Control introduced new APIs in recent versions of Windows. Beginning with version 7.3,
+PowerShell uses the new `WldpCanExecuteFile` API to decide how a file should be handled. Windows
+PowerShell 5.1 doesn't support this new API. The new API takes precedence over the legacy API for
+individual files. However, PowerShell continues to use the legacy API to get the system wide policy
+configuration. If the new API isn't available, PowerShell falls back to the old API behavior.
 
 The new API provides the following information for each file:
 
@@ -54,18 +54,18 @@ this mode, see the [PowerShell restrictions under lockdown policy][02] section o
 
 ### Noninteractive mode running under policy enforcement
 
-When PowerShell runs a script or loads a module, it uses the App Control API to get the policy enforcement
-for the file.
+When PowerShell runs a script or loads a module, it uses the App Control API to get the policy
+enforcement for the file.
 
-PowerShell version 7.3 or higher uses the `WldpCanExecuteFile` API if available. This API returns one
-of the following results:
+PowerShell version 7.3 or higher uses the `WldpCanExecuteFile` API if available. This API returns
+one of the following results:
 
-- `WLDP_CAN_EXECUTE_ALLOWED`: The file is approved by policy and is used in `FullLanguage` mode with
-  a few restrictions.
-- `WLDP_CAN_EXECUTE_BLOCKED`: The file isn't approved by policy. PowerShell throws an error when the
+- `WLDP_CAN_EXECUTE_ALLOWED`: The policy allows the file for use in `FullLanguage` mode with a few
+  restrictions.
+- `WLDP_CAN_EXECUTE_BLOCKED`: The policy disallows the file. PowerShell throws an error when the
   file is run or loaded.
-- `WLDP_CAN_EXECUTE_REQUIRE_SANDBOX`: The file isn't approved by the policy but it can still be run
-  or loaded in `ConstrainedLanguage` mode.
+- `WLDP_CAN_EXECUTE_REQUIRE_SANDBOX`: The policy doesn't approve the file, but it can be run or
+  loaded in `ConstrainedLanguage` mode.
 
 In Windows PowerShell 5.1 or if `WldpCanExecuteFile` API isn't available, PowerShell's per file
 behavior is:
@@ -77,7 +77,7 @@ behavior is:
 
 ## PowerShell restrictions under lockdown policy
 
-When PowerShell detects the system is under a App Control lockdown policy, it applies restrictions even if
+When PowerShell detects the system is under an App Control lockdown policy, it applies restrictions even if
 the script is trusted and running in `FullLanguage` mode. These restrictions prevent known behaviors
 of PowerShell that could result in arbitrary code execution on a locked-down system. The lockdown
 policy enforces the following restrictions:
@@ -128,7 +128,7 @@ policy enforces the following restrictions:
 
 ## PowerShell restrictions under constrained language mode
 
-Script or function that isn't approved by the App Control policy is untrusted. When you run an untrusted
+A script or function not approved by the App Control policy is untrusted. When you run an untrusted
 command, PowerShell either blocks the command from running (new behavior) or runs the command in
 `ConstrainedLanguage` mode. The following restrictions apply to `ConstrainedLanguage` mode:
 

reference/docs-conceptual/security/app-control/how-to-use-app-control.md

@@ -1,6 +1,6 @@
 ---
 description: This article explains how to configure and use App Control to secure PowerShell.
-ms.date: 10/21/2024
+ms.date: 12/09/2025
 title: How to use App Control to secure PowerShell
 ---
 # How to use App Control to secure PowerShell
@@ -157,8 +157,8 @@ information helps you understand where you need to change your script so that it
 policy.
 
 > [!IMPORTANT]
-> Once you have reviewed the audit events, you should disable the Analytic log. Analytic logs grow
-> quickly and consume large amounts of disk space.
+> After you review the audit events, you should disable the Analytic log. Analytic logs grow quickly
+> and consume large amounts of disk space.
 
 ### Viewing audit events in the PowerShell debugger
 

reference/docs-conceptual/security/preventing-script-injection.md

@@ -1,6 +1,6 @@
 ---
 description: This article explains how to prevent script injection attacks using single quote escaping.
-ms.date: 02/10/2023
+ms.date: 12/09/2025
 title: Preventing script injection attacks
 ---
 # Preventing script injection attacks
@@ -12,12 +12,12 @@ vulnerability. For example, a malicious user could abuse the vulnerable function
 code on a remote computer, possibly compromising that computer and gaining access to other machines
 on the network.
 
-Once you are aware of the issue, there are several ways to protect against injection attacks.
+Once you're aware of the issue, there are several ways to protect against injection attacks.
 
 ## Example of vulnerable code
 
 PowerShell code injection vulnerabilities involve user input that contains script code. The user
-input is added to vulnerable script where it's parsed and run by PowerShell.
+input is added to vulnerable script where PowerShell parses and runs it.
 
 ```powershell
 function Get-ProcessById
@@ -30,8 +30,8 @@ function Get-ProcessById
 
 The `Get-ProcessById` function looks up a local process by its Id value. It takes a `$ProcId`
 parameter argument of any type. The `$ProcId` is then converted to a string and inserted into
-another script that's parsed and run using the `Invoke-Expression` cmdlet. This function works fine
-when a valid process Id integer is passed in.
+another script. `Invoke-Expression` cmdlet parses and runs the provided string. This function works
+fine when a valid process Id integer is passed in.
 
 ```powershell
 Get-ProcessById $PID
@@ -141,8 +141,8 @@ Get-Process: Cannot bind parameter 'Id'. Cannot convert value "8064; Write-Host
 "System.Int32". Error: "The input string '8064; Write-Host' was not in a correct format."
 ```
 
-However, this version of the function isn't yet completely safe from injection attacks. A malicious
-user can still use single quotes in their input to inject code.
+However, this version of the function isn't safe from injection attacks. A malicious user can still
+use single quotes in their input to inject code.
 
 ```powershell
 Get-ProcessById "$PID'; Write-Host 'pwnd!';'"
@@ -160,10 +160,11 @@ pwnd!
 
 #### Use the `EscapeSingleQuotedStringContent()` method
 
-To protect against the user inserting their own single quote characters to exploit the function you
-must use the `EscapeSingleQuotedStringContent()` API. This is a static public method of the PowerShell
-**System.Management.Automation.Language.CodeGeneration** class. This method makes the user input safe
-by escaping any single quotes included in the user input.
+To protect against the user inserting their own single quote characters to exploit the function, you
+must use the `EscapeSingleQuotedStringContent()` API. `EscapeSingleQuotedStringContent()` is a
+public static method of the PowerShell **System.Management.Automation.Language.CodeGeneration**
+class. This method makes the user-provided input safe by escaping any single quotes included in the
+user input.
 
 ```powershell
 function Get-ProcessById
@@ -198,8 +199,8 @@ Install-Module InjectionHunter
 Install-PSResource InjectionHunter
 ```
 
-You can use this to automate security analysis during builds, continuous integration processes,
-deployments, and other scenarios.
+You can use this module to automate security analysis during builds, continuous integration
+processes, deployments, and other scenarios.
 
 ```powershell
 $RulePath = (Get-Module -List InjectionHunter).Path
@@ -223,15 +224,13 @@ InjectionRisk.InvokeExpression      Warning      Invoke-Dan 3     Possible scrip
 
 For more information, see [PSScriptAnalyzer][02].
 
-<!-- TODO: Add instructions for VS Code once it gets fixed -->
-
 ## Related links
 
 - [Lee Holmes' blog post about Injection Hunter][03]
 - [Injection Hunter][04]
 
 <!-- link references -->
-[01]: /dotnet/api/system.management.automation.language.codegeneration.escapesinglequotedstringcontent
+[01]: xref:System.Management.Automation.Language.CodeGeneration.EscapeSingleQuotedStringContent%2A
 [02]: /powershell/utility-modules/psscriptanalyzer/overview
 [03]: https://devblogs.microsoft.com/powershell/powershell-injection-hunter-security-auditing-for-powershell-scripts/
 [04]: https://www.powershellgallery.com/packages/InjectionHunter

reference/docs-conceptual/security/remoting/PS-remoting-second-hop.md

@@ -1,14 +1,14 @@
 ---
 description: This article explains the various methods for configuring second-hop authentication for PowerShell remoting, including the security implications and recommendations.
-ms.date: 10/23/2023
+ms.date: 12/09/2025
 title: Making the second hop in PowerShell Remoting
 ---
 
 # Making the second hop in PowerShell Remoting
 
-The "second hop problem" refers to a situation like the following:
+The following scenario outlines the _second hop problem_:
 
-1. You are logged in to _ServerA_.
+1. You're logged in to _ServerA_.
 1. From _ServerA_, you start a remote PowerShell session to connect to _ServerB_.
 1. A command you run on _ServerB_ via your PowerShell Remoting session attempts to access a resource
    on _ServerC_.
@@ -86,9 +86,9 @@ transition.
 
 ## Resource-based Kerberos constrained delegation
 
-Using resource-based Kerberos constrained delegation (introduced in Windows Server 2012), you
-configure credential delegation on the server object where resources reside. In the second hop
-scenario described above, you configure _ServerC_ to specify from where it accepts delegated
+Windows Server 2012 introduced resource-based Kerberos constrained delegation. You configure
+credential delegation on the server object where resources reside. In the second hop scenario
+described previously, you configure _ServerC_ to specify from where it accepts delegated
 credentials.
 
 ### Pros
@@ -113,8 +113,8 @@ credentials.
 ### Example
 
 Let's look at a PowerShell example that configures resource-based constrained delegation on
-_ServerC_ to allow delegated credentials from a _ServerB_. This example assumes that all servers are
-running supported versions of Windows Server, and that there is at least one Windows domain
+_ServerC_ that allow delegated credentials from a _ServerB_. This example assumes that all servers
+are running supported versions of Windows Server, and that there is at least one Windows domain
 controller for each trusted domain.
 
 Before you can configure constrained delegation, you must add the `RSAT-AD-PowerShell` feature to
@@ -140,11 +140,11 @@ Cmdlet      Set-ADUser           ActiveDirectory
 ```
 
 The **PrincipalsAllowedToDelegateToAccount** parameter sets the Active Directory object attribute
-**msDS-AllowedToActOnBehalfOfOtherIdentity**, which contains an access control list (ACL) that
-specifies which accounts have permission to delegate credentials to the associated account (in our
-example, it will be the machine account for _ServerA_).
+**msDS-AllowedToActOnBehalfOfOtherIdentity**. This attribute contains an access control list (ACL)
+that specifies the accounts that have permission to delegate credentials to the associated account.
+For this example, it's the machine account for _ServerA_.
 
-Now let's set up the variables we'll use to represent the servers:
+Now let's create the variables that represent the servers:
 
 ```powershell
 # Set up variables for reuse
@@ -182,8 +182,8 @@ Get-ADComputer -Identity $ServerC -Properties PrincipalsAllowedToDelegateToAccou
 ```
 
 The Kerberos [Key Distribution Center (KDC)][13] caches denied-access attempts (negative cache) for
-15 minutes. If _ServerB_ has previously attempted to access _ServerC_, you need to clear the
-cache on _ServerB_ by invoking the following command:
+15 minutes. If _ServerB_ previously attempted to access _ServerC_, you need to clear the cache on
+_ServerB_ by invoking the following command:
 
 ```powershell
 Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
@@ -232,7 +232,7 @@ Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $servers
 ```
 
 If you want to make the second hop across domains, use the **Server** parameter to specify
-fully-qualified domain name (FQDN) of the domain controller of the domain to which _ServerB_
+fully qualified domain name (FQDN) of the domain controller of the domain to which _ServerB_
 belongs:
 
 ```powershell

reference/docs-conceptual/security/remoting/Running-Remote-Commands.md

@@ -1,6 +1,6 @@
 ---
 description: Explains the methods for running commands on remote systems using PowerShell.
-ms.date: 07/03/2023
+ms.date: 12/09/2025
 title: Running Remote Commands
 ---
 # Running Remote Commands
@@ -48,15 +48,15 @@ Get-Command | Where-Object {
 
 ## Windows PowerShell remoting
 
-Using the WS-Management protocol, Windows PowerShell remoting lets you run any Windows PowerShell
+By using the WS-Management protocol, Windows PowerShell remoting lets you run any Windows PowerShell
 command on one or more remote computers. You can establish persistent connections, start interactive
 sessions, and run scripts on remote computers.
 
 To use Windows PowerShell remoting, the remote computer must be configured for remote management.
 For more information, including instructions, see [About Remote Requirements][04].
 
-Once you have configured Windows PowerShell remoting, many remoting strategies are available to you.
-This article lists just a few of them. For more information, see [About Remote][02].
+Once you configure Windows PowerShell remoting, many remoting strategies are available to you. This
+article lists just a few of them. For more information, see [About Remote][02].
 
 ### Start an interactive session
 

reference/docs-conceptual/security/remoting/WSMan-Remoting-in-PowerShell.md

@@ -1,15 +1,15 @@
 ---
 description: Remoting in PowerShell using WSMan
-ms.date: 01/27/2025
+ms.date: 12/09/2025
 title: Using WS-Management (WSMan) Remoting in PowerShell
 ---
 # Using WS-Management (WSMan) Remoting in PowerShell
 
 ## Enabling PowerShell remoting
 
-To enable PowerShell remoting run the `Enable-PSRemoting` cmdlet in an elevated PowerShell session.
+To enable PowerShell remoting, run the `Enable-PSRemoting` cmdlet in an elevated PowerShell session.
 Running `Enable-PSRemoting` configures a remoting endpoint for the specific installation version
-that you are running the cmdlet in. For example, when you run `Enable-PSRemoting` while running
+that you're running the cmdlet in. For example, when you run `Enable-PSRemoting` while running
 PowerShell 7.4, PowerShell creates a remoting endpoint runs PowerShell 7.4. If you run
 `Enable-PSRemoting` while running PowerShell 7-preview, PowerShell creates a remoting endpoint that
 runs PowerShell 7-preview. You can create multiple remoting endpoints for different versions of that
@@ -41,22 +41,13 @@ of Windows.
 ## WSMan remoting isn't supported on non-Windows platforms
 
 Since the release of PowerShell 6, support for remoting over WS-Management (WSMan) on non-Windows
-platforms has only been available to a limited set of Linux distributions. All versions of those
-distributions that supported WSMan are no longer supported by the Linux vendors that created them.
+platforms is only available to a limited set of Linux distributions. On non-Windows, WSMan relied on
+the [Open Management Infrastructure (OMI)][02] project. The OMI WSMan client depends on **OpenSSL
+1.0**. All Linux distributions use **OpenSSL 2.0**, which isn't backward-compatible. There are no
+supported distributions that have the dependencies needed for the OMI WSMan client to work.
 
-On non-Windows, WSMan relied on the [Open Management Infrastructure (OMI)][02] project, which no
-longer supports PowerShell remoting. The OMI WSMan client is dependent on **OpenSSL 1.0**. Most
-Linux distributions have moved to **OpenSSL 2.0**, which isn't backward-compatible. At this time,
-there is no supported distribution that has the dependencies needed for the OMI WSMan client to
-work.
-
-The outdated libraries and supporting code have been removed for non-Windows platforms. WSMan-based
-remoting is still supported between Windows systems. Remoting over SSH is supported for all
-platforms. For more information, see [PowerShell remoting over SSH][05].
-
-> [!NOTE]
-> Users may be able to get WSMan remoting to work using the [PSWSMan][04] module. This module isn't
-> supported or maintained by Microsoft.
+WSMan-based remoting is still supported between Windows systems. Remoting over SSH is supported for
+all platforms. For more information, see [PowerShell remoting over SSH][05].
 
 ## Further reading
 

reference/docs-conceptual/security/remoting/WinRM-Security.md

@@ -1,6 +1,6 @@
 ---
 description: This document covers security concerns, recommendations, and best practices when using PowerShell Remoting.
-ms.date: 03/24/2025
+ms.date: 12/09/2025
 title: Security considerations for PowerShell Remoting using WinRM
 ---
 
@@ -113,8 +113,8 @@ authentication protocol.
 
 - Basic authentication provides no encryption.
 - NTLM authentication uses an RC4 cipher with a 128-bit key.
-- The `etype` in the TGS ticket determines Kerberos authentication encryption. This is AES-256
-  on modern systems.
+- The `etype` in the TGS ticket determines Kerberos authentication encryption. Modern systems use
+  the AES-256 algorithm.
 - CredSSP encryption uses the TLS cipher suite negotiated in the handshake.
 
 ## Making the second hop