Encoding Guidance for Signed PowerShell Scripts

Original publish date: November 10, 2026
KB ID: 5135999

Overview

Starting with the November 2026 Windows security update, a stricter encoding validation for PowerShell script signing and signature verification is introduced. This intentional security-hardening change may cause affected scripts containing malformed UTF-8 to fail signature validation after the update, even if they previously validated successfully.

This guide explains the encoding scenarios that can affect signing or signature validation and provides steps to identify affected files, attempt temporary repair where supported, or convert and re-sign them. Not every signature failure is caused by encoding.

How Windows determines encoding

For file-based PowerShell script signing and signature verification, Windows selects an encoding before decoding the entire file:

1. A recognized byte order mark (BOM) identifies UTF-8 or UTF-16.
2. Without a BOM, Windows checks the first 32 bytes for encoding patterns, including UTF-16 and UTF-8. If no pattern matches, it uses the machine’s system code page.
3. Windows decodes the entire file using the selected encoding.

This hardening change strengthens validation during decoding; it does not change the encoding-selection process described above. Additionally, this hardening change causes Windows to reject malformed UTF-8 files that could previously be decoded using replacement characters. For affected files, signing might fail or an existing signature might be reported as NotSigned.

A UTF-8 file with an ASCII-only header can be read using a system code page, while a code-page file can be mistaken for UTF-8. A header that looks like UTF-8 does not establish that the rest of the file is valid UTF-8.

Adding a BOM alone does not correct invalid bytes. The long-term repair is to review the text, save it as valid UTF-8 with BOM, and sign the file again.

What symptoms might occur by this hardening change?

After installing the Windows security update released on and after November 10, 2026, files affected by this stricter encoding validation might exhibit the following symptoms:

Where	Observed symptom
Get-AuthenticodeSignature	Status : NotSigned for an affected, previously signed script.
Set-AuthenticodeSignature	Status : UnknownError, with the message “No mapping for the Unicode character exists in the target multi-byte code page.”
App Control for Business (WDAC)	On devices enforcing App Control, affected malformed-UTF-8 scripts may run in ConstrainedLanguage mode.

Affected scripts

This hardening change introduces stricter validation that may affect scripts containing invalid bytes in the encoding Windows selects. The scenarios below help identify potential encoding issues; not every script in these categories is affected.

Case	Which scripts may be affected
Case 1: Invalid UTF-8	Scripts that Windows reads as UTF-8 but that contain invalid UTF-8 data. Stricter validation may cause previously signed scripts to fail signature validation.
Case 2: UTF-8 without BOM	Some UTF-8 scripts without a BOM may be read using the machine’s system code page—for example, Japanese code page 932. Signing or verification can fail if the file contains bytes that are invalid in the selected encoding.
Case 3: Language-specific text encodings	Some scripts saved in an encoding such as Shift-JIS may be mistaken for UTF-8. Signing or verification can fail if the file contains data that is not valid UTF-8.

The hardening change enforces stricter validation, not encoding selection. Use the steps below before choosing a repair option.

Repair script

The Repair-SignedPowerShellUtf8.ps1 script helps identify encoding issues and create copies for repair or conversion. It never overwrites the source file or an existing output file.

Options

Mode	What it does
Scan (default)	Checks files or folders and reports a potential encoding issue, current signature status, and suggested action. Does not change files.
Repair	Attempts a temporary repair for cases 1 and 2, keeping the existing signature. Creates a separate copy and checks its signature. Does not create a new signature or require the signing key.
ConvertToUtf8Bom	Creates a UTF-8-with-BOM copy and removes the old signature. Review the text and sign the copy again; this mode does not sign it for you. This is the offered path for case 3.

Use -Path to select the input, -Recurse to scan subfolders, and -OutputPath to choose a repair or conversion destination. For conversion, -SourceCodePage specifies the file’s original encoding when needed. Commands are in the steps below; detailed parameter help is in the script’s opening comments.

Limits and cases the Repair script cannot handle

Situation	What to do
Case 3: Language-specific text read as UTF-8	Repair is not offered for this case. Convert using the correct source encoding, review the text, and sign again.
Some case-2 files	Repair refuses when it cannot produce valid text in the required encoding while preserving the signed text. Convert to UTF-8 with BOM, review, and sign again.
Case 2: The repair machine uses a different system code page from the signer	Run Repair on a machine with the signer’s system code page, or convert and sign again.
The source encoding does not support strict decoding in this tool	Use an editor that supports the original encoding to save a UTF-8-with-BOM copy, review it, and sign again.
Missing or incorrect text, or script logic errors	Encoding repair cannot reconstruct the author’s intended text or fix script logic. Correct the content from a trusted source before signing again.

Before you start

• Save the full script from the appendix as Repair-SignedPowerShellUtf8.ps1. Open Windows PowerShell 5.1 and run the commands from the folder containing it.
• Use an approved copy of the script under your organization’s execution and App Control policies. The tool requires FullLanguage. If execution is blocked, follow your organization’s approval process rather than changing policy as a general setup step.
• To sign a converted file, you need an approved code-signing certificate or access to your publisher’s signing process. Temporary Repair does not require the signing key.

Step 1: Find affected scripts

Run the tool in read-only Scan mode:

.\Repair-SignedPowerShellUtf8.ps1 -Mode Scan -Path C:\Scripts -Recurse |
      Format-Table Path, Issue, SignatureStatus, Action -Wrap

For a single file, set -Path to that file instead. Scan reports the potential encoding issue, current signature status, and suggested action without changing files. The following table helps you to understand the reported issue.

Issue	What it indicates	Next step
MalformedUtf8	Potential case 1: The file is read as UTF-8 but contains invalid UTF-8 data.	Try Repair for an existing signed file, or convert to UTF-8 with BOM, review, and sign again.
Utf8WithoutBom	Potential case 2: The file is valid UTF-8 without a BOM but is not valid in the system text encoding Windows selected.	For an existing signed file, try Repair using the signer’s system code page. Otherwise convert, review, and sign.
CodePageTextReadAsUtf8	Potential case 3: A language-specific encoding may have been mistaken for UTF-8.	Confirm the source encoding, convert, review, and sign again. Repair is not offered for this label.
NotValidInCodePage	The file is not valid in the selected system code page and is not valid UTF-8.	Confirm the source encoding before choosing repair or conversion.
None	No encoding issue detected by this scan.	Do not run encoding repair solely because the signature status is NotSigned.

Unsigned files: Scan checks both signed and unsigned files. NotSigned alone does not mean a file is affected, and Scan cannot establish whether it was previously signed. An unsigned file with an encoding issue may need conversion before signing, but it has no existing signature to preserve.

Step 2: Repair or convert affected scripts

Choose one of the following options for a file flagged by Scan. Conversion and re-signing are recommended. Temporary Repair may help with previously signed files in cases 1 and 2, but is not offered for case 3.

Recommended: Convert to UTF-8 with BOM and sign again

Create a UTF-8-with-BOM copy. The source remains unchanged, and the old signature is removed from the copy:

.\Repair-SignedPowerShellUtf8.ps1 -Mode ConvertToUtf8Bom -Path C:\Scripts\Deploy.ps1

The default output is C:\Scripts\Deploy.utf8bom.ps1 . For case 3, specify the file’s known original encoding with -SourceCodePage; for example, add -SourceCodePage 932 for a Shift-JIS file.

Review the converted text and correct any errors before signing. Use your organization’s approved signing process; the commands below assume $cert already contains your approved code-signing certificate:

Set-AuthenticodeSignature -FilePath C:\Scripts\Deploy.utf8bom.ps1 -Certificate $cert
    Get-AuthenticodeSignature -FilePath C:\Scripts\Deploy.utf8bom.ps1 |
        Format-List Status, StatusMessage

Confirm Status : Valid and test the reviewed copy before deployment.

Temporary: Attempt a repair without re-signing

Repair attempts to create a copy whose existing signature validates. It does not reconstruct missing text or fix script errors, and some files cannot be repaired:

.\Repair-SignedPowerShellUtf8.ps1 -Mode Repair -Path C:\Scripts\Deploy.ps1

A successful repair reports:

    SignatureStatus : Valid

For case 2, use a machine with the same system code page as the original signer.

Deploy the copy only after its SignatureStatus reports Valid and you have reviewed and tested it.